SJSAS 8.2 EJB class loader

Hello,
I did not found how to set the class loader to parent last for EJBs.
I have an EAR with a WAR and 2 EJBs, for the WAR I've added :
<class-loader delegate="false"/>in the sun-web.xml descriptor, but I don't know how to do it in my JARs.
I think I have a conflict between the Xerces version used by Sun AS and the one embbeded in my EAR.
Any advice ?

The servlet specs recommends that the web class loader looks locally before delegating it to the parent. Thus there is a provision of a paramenter which can be configured.
Did u try putting it ib by editing the classpath-suffix attribute of the java-config element in the domain.xml file. But now this will be available to all the applicatuons across the domain.

Similar Messages

MBean calling ejb class loading issue

Hi,
I would like to have an mbean call an ejb. I have come against a (predictable!!)
class loading problem. The EJB Home cant be bundled with the mbean because the
mbean class loader would load the interface, preventing ejb reload( Thats what
the error msg indicates) and the ejb doesnt get deployed.
I have moved to an mlet based scheme (beacuse an mlet is a class loader) to
load the mbeans, but now I have the problem that when the mbean looks up the
home in jndi the cast fails ie the jndi object has an interface class loaded by
the ejb class loader but the mlet has its own loaded home interface. These class
loaders appear to be sibblings - but I havnt printed out the trees.
This is WLS 702 which seems to be JMX 1.1. Has anyone got a way around this?
Have I invented a problem that doesnt exist? I cant go to WLS8.
My current way forward is to have the mbean find the class loader that loaded
the interface class (jndi object) and then have the mbean use that class loader
to load its copy of the interface class. Seems a bit complex. Im sure I missed
something obvious.
Thanks
Pete Marshall

Pete,
could you explain better your thoughts...
I'm interested to hear them.
regards,
Pedro Salazar.
Pete Marshall wrote:
Must think before typing..
If I have the ejb register a listener on the mbean and have the mbean emit an
event the detyped notification from the mbean will break the link between the
mbean class loader and the ejb loader. I think ;-) Ill try it.
Pete
"Pete Marshall" <[email protected]> wrote:
Hi,
I would like to have an mbean call an ejb. I have come against a (predictable!!)
class loading problem. The EJB Home cant be bundled with the mbean because
the
mbean class loader would load the interface, preventing ejb reload( Thats
what
the error msg indicates) and the ejb doesnt get deployed.
I have moved to an mlet based scheme (beacuse an mlet is a class loader)
to
load the mbeans, but now I have the problem that when the mbean looks
up the
home in jndi the cast fails ie the jndi object has an interface class
loaded by
the ejb class loader but the mlet has its own loaded home interface.
These class
loaders appear to be sibblings - but I havnt printed out the trees.
This is WLS 702 which seems to be JMX 1.1. Has anyone got a way around
this?
Have I invented a problem that doesnt exist? I cant go to WLS8.
My current way forward is to have the mbean find the class loader that
loaded
the interface class (jndi object) and then have the mbean use that class
loader
to load its copy of the interface class. Seems a bit complex. Im sure
I missed
something obvious.
Thanks
Pete Marshall

Re: MBean calling ejb class loading issue

Must think before typing..
If I have the ejb register a listener on the mbean and have the mbean emit an
event the detyped notification from the mbean will break the link between the
mbean class loader and the ejb loader. I think ;-) Ill try it.
Pete
"Pete Marshall" <[email protected]> wrote:
>
Hi,
I would like to have an mbean call an ejb. I have come against a (predictable!!)
class loading problem. The EJB Home cant be bundled with the mbean because
the
mbean class loader would load the interface, preventing ejb reload( Thats
what
the error msg indicates) and the ejb doesnt get deployed.
I have moved to an mlet based scheme (beacuse an mlet is a class loader)
to
load the mbeans, but now I have the problem that when the mbean looks
up the
home in jndi the cast fails ie the jndi object has an interface class
loaded by
the ejb class loader but the mlet has its own loaded home interface.
These class
loaders appear to be sibblings - but I havnt printed out the trees.
This is WLS 702 which seems to be JMX 1.1. Has anyone got a way around
this?
Have I invented a problem that doesnt exist? I cant go to WLS8.
My current way forward is to have the mbean find the class loader that
loaded
the interface class (jndi object) and then have the mbean use that class
loader
to load its copy of the interface class. Seems a bit complex. Im sure
I missed
something obvious.
Thanks
Pete Marshall

Pete,
could you explain better your thoughts...
I'm interested to hear them.
regards,
Pedro Salazar.
Pete Marshall wrote:
Must think before typing..
If I have the ejb register a listener on the mbean and have the mbean emit an
event the detyped notification from the mbean will break the link between the
mbean class loader and the ejb loader. I think ;-) Ill try it.
Pete
"Pete Marshall" <[email protected]> wrote:
Hi,
I would like to have an mbean call an ejb. I have come against a (predictable!!)
class loading problem. The EJB Home cant be bundled with the mbean because
the
mbean class loader would load the interface, preventing ejb reload( Thats
what
the error msg indicates) and the ejb doesnt get deployed.
I have moved to an mlet based scheme (beacuse an mlet is a class loader)
to
load the mbeans, but now I have the problem that when the mbean looks
up the
home in jndi the cast fails ie the jndi object has an interface class
loaded by
the ejb class loader but the mlet has its own loaded home interface.
These class
loaders appear to be sibblings - but I havnt printed out the trees.
This is WLS 702 which seems to be JMX 1.1. Has anyone got a way around
this?
Have I invented a problem that doesnt exist? I cant go to WLS8.
My current way forward is to have the mbean find the class loader that
loaded
the interface class (jndi object) and then have the mbean use that class
loader
to load its copy of the interface class. Seems a bit complex. Im sure
I missed
something obvious.
Thanks
Pete Marshall

Apparent EJB Class Loader Issue

I am having a problem loading narrowing an EJB. It appears to be a class loader
problem. I am getting a ClassCastException with the following message: Cannot
narrow remote object to com.dte.ejb.facade.AccessoryServiceHome.
Here is my code that looks up the EJB (I've ommitted the 'catch' clauses):
EJBHome ejbHome = (EJBHome) cache.get(homeClass);
try {
Object temp = ctx.lookup("ejb/" + homeClass.getName());
if (ejbHome == null) {
ejbHome = (EJBHome) PortableRemoteObject.narrow(temp, homeClass);
cache.put(homeClass, ejbHome);
Here is the output of some debugging information from the above method. Here I've
displayed the class.getName and the class.getClassLoader for the Class object
passed to this method and the remote object being cast by the narrow method:
homeClass : com.dte.ejb.facade.AccessoryServiceHome
homeClass : weblogic.utils.classloaders.ChangeAwareClassLoader@29164c finder:
weblogic.utils.classloaders.MultiClassFinder@300ec4
From Lookup: com.dte.ejb.facade.AccessoryServiceBean_krx5el_HomeImpl
From Lookup: weblogic.utils.classloaders.GenericClassLoader@1ea02f finder: weblogic.utils.classloaders.MultiClassFinder@6fca08
As you can see, the Class passed into this method has been loaded with the ChangeAwareClassLoader
but the HomeImpl class was loaded with the GenericClassLoader. I think that is
the problem (please correct me if I am wrong).
The application in question is an .ear with 2 .war modules and a ejb.jar file.
It was my understanding that all classes needed by any module in a .ear were all
loaded with the same class loader. Is this true? If so, then why am I having this
problem?
Thank you in advance for your help.

I just want to add few comments hoping the iPlanet engineer will be able to help me.
I mange to get one deployment of a war file with the client weblogic EJB to work; only if I add the Installation Directory path of the war file plus “web-inf/classes” to the classpath of the JVM configuration.
This tells me that the class loader looks for the JVM classpath to load the EJB home class at run time. I think; if I can make iPlanet class loader to look for the application classpath instead of the JVM my problem will go away.
Thank you in advance,
Nad

EJB Class loader and regular Java files class loader.

Hi,
Is the EJB's class loader the same as a "regular" java files class loader OR weblogic
has 2 class loaders, one for each???
Thanks,
les.

les <[email protected]> wrote:
Hi,
Is the EJB's class loader the same as a "regular" java files class loader OR weblogic
has 2 class loaders, one for each???Yes. Exact classloading architecture depends on which WebLogic version you use. If you
use 6.x+, you may want to read this article:
http://www.onjava.com/pub/a/onjava/2001/07/25/ejb.html
Thanks,
les.--
Dimitri

Class Loader Hierarchy in Weblogic 7.0

I have read the BEA documentation on the class loader hierarchy in Weblogic Server,
and I have some questions regarding some behavior I am seeing.
I am running Weblogic Server 7.0.
I have an ear file that contains 3 web apps (wars) and several utility jars. The
web apps' manifests contain the Class-Path entry for the utility jars. My understanding
of this is that each web app SHOULD have its own class loader. Also, the utility
jars will be scoped in a separate class loader and WILL NOT have visibility to
the web app classes. The web app classes should have visibility to the utility
jars.
Is this correct????
I added a static segment of code in each web app and printed the class loader
for each servlet when it was loaded. I also printed the class loader from a class
that is DEFINITELY contained in one of the utility jars. Here is the result:
Utility Class ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Utility Class
Parent ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
Servlet 1 ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Servlet 1 Parent
ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
Servlet 2 ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Servlet 2 Parent
ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
I'm a little confused.... I expected to see 3 different class loaders (i.e. one
for each class above). I believe the above printout says that all 3 classes are
being loaded by the SAME class loader instance (Launcher$AppClassLoader@b9d04).
Am I interpreting this correctly? If so, what's going on?

I rechecked the classpath for the user that starts Weblogic, and in the classpath
I found the project "src" directory (must have missed it earlier). When we did
our build, the classes are placed in the src structure then copied to the build
area. That's the reason I was not seeing the appropriate class loader hierarchy.
Thanks for all of the comments.
"Sanjeev Chopra" <[email protected]> wrote:
>
"Mark Cotherman" <[email protected]> wrote in message
news:[email protected]...
Thanks for your comments again Mark. I'm just trying to get a goodhandle
on how
this is working.
I'll assume that somehow my web app classes are being loaded into theroot
classloader.
The next question is... why??Just to be sure - is there any way these classes are sneaking into the
system classpath ?
My ear file contains the following:
a.war
b.war
c.war
lib/util1.jar
lib/util2.jar
lib/util3.jar
lib/util4.jar
The manifest in all three wars reference all util jars. This ear deployssuccessfully
on Weblogic with no errors.
How could these separate servlets (one in each war) not have seperateclass loaders
seperate from the root where the utils should reside. I don't thinkthat
I have
any control over where Weblogic loads the war classes, or do I?
See comments below....
Mark Spotswood <[email protected]> wrote:
Mark Cotherman wrote:
Thanks for the follow-up.
I want to make sure I follow what you are saying. All classes in
the
manifest
Class-Path of WARs are exported to the parent classloader.That's right.
To me this is the correct behavior since the manifest Class-Path
is
meant to provide
a way to share common utility classes among several web apps. AllEJB jars and
manifest Class-Path entries should be loaded by the same class loader.Its a way to share class definitions, but not necessarilly class
instances. I don't think that a web application should be extending
the classpath of its parent's classloader. This leads to namespace
problems as well as reloadability issues.
Ok, you lost me here. Shouldn't delegation handle the namespacecollisions??
If the web app class loader has a class definition (webapp:com.xyz.ClassA) with
exactly the same name in the same package as the root class loader(rootloader:
com.xyz.ClassA), I thought the web app would use (delegate loading)the
class
definition from the root class loader when PreferWebInf is set to false.
Isn't this why the PreferWebInf attribute, when set to true, can causeClassCastExceptions??
The web app when creating an instance of (webapp: com.xyz.ClassA)from
the web
app class loader can potentially pass a reference to this instanceto a
class
instance loaded from the root loader. The root class loader has adifferent class
definition for ClassA.
REALLY what makes since is that all common jar files be defined
in
the manifest
Class-Path OF THE ear FILE (if the WAR(s) are in an ear). These
jar
files should
then be loaded by the same class loader as the EJB jars. There shouldbe no need
for the WARs to have any reference to the utility jars since the
EJB
class loader
is the parent of the WAR class loaders.The ear file doesn't have a manifest classpath, but what you are getting
at makes sense. If you add a manifest to any EJBs in your app, theall
webapps (as well as all other EJBs) will be able to see it, sincewith
our structure, EJBs are loaded into the application's root classloader.
My problem is that the ACTUAL SERVLET classes are NOT being loadedby a separate
class loader from the EJB and common jar class loader. This is
completely
against
what is being said in the Weblogic documentation. The Manifest
Class-Path
should
have nothing to do with where the classes that reside in
WEB-INF/classes
of my
servlet are loaded.Classloaders will ask their parent for the class first before loading
it
themselves. So if the parent classloader somehow has visibility to
classes that your webpapp references, then it will get loaded by the
parent classloader.
I am in the middle of migrating an app from an older version of
Weblogic,
and
it would be helpful to have the ACTUAL class loading hierarchy welldocumented.
The basic hierarchy is all EJBs are in a root shared classloader and
each web application is loaded by a classloader that is a child of
that root.
Again, am I missing something here???My suspicion is that somehow these servlets are in the classpath ofthe
root classloader, so when the webapp classloaders delegate to thatone,
it will come up with the class.
mark
Mark Spotswood <[email protected]> wrote:
I believe what you are seeing is a bug in the servlet container.
The classloader organization is what you expect, but each webapp
is exporting the classpath information from its manifest to the
classloader above its classloader (which is common to all
three webapps) rather than to its own classloader. So because
of the delegation that happens with classloading, the common
parent classloader is the one that loads the class.
I believe that this behavior exists as an attempt to avoid
ClassCastExceptions, but I don't think that it is the right
solution to this problem. In our 8.1 release, this behavior
has been changed. That is, web applications no longer export
manifest classpath information to the parent of their classloader.
This change has not been ported back to the 7.x line, but a bug
report has been created (CR099889). You should be able to follow
up with support with this CR number.
mark
Mark Cotherman wrote:
I have read the BEA documentation on the class loader hierarchy
in
Weblogic Server,
and I have some questions regarding some behavior I am seeing.
I am running Weblogic Server 7.0.
I have an ear file that contains 3 web apps (wars) and several
utility
jars. The
web apps' manifests contain the Class-Path entry for the utility
jars.
My understanding
of this is that each web app SHOULD have its own class loader.
Also,
the utility
jars will be scoped in a separate class loader and WILL NOT have
visibility
to
the web app classes. The web app classes should have visibility
to
the utility
jars.
Is this correct????
I added a static segment of code in each web app and printed the
class
loader
for each servlet when it was loaded. I also printed the class loaderfrom a class
that is DEFINITELY contained in one of the utility jars. Here is
the
result:
Utility Class ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04
Utility
Class
Parent ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
Servlet 1 ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Servlet1 Parent
ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
Servlet 2 ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Servlet2 Parent
ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
I'm a little confused.... I expected to see 3 different class loaders(i.e. one
for each class above). I believe the above printout says that all
3
classes are
being loaded by the SAME class loader instance
(Launcher$AppClassLoader@b9d04).
Am I interpreting this correctly? If so, what's going on?

Dynamic Class Loading in an EJB Container

Hello,
We have a need to load classes from a nonstandard place with in an ejb container, ie a database or secure store. In order to do so we have created a custom class loader. Two issues have come up we have not been able to solve, and perhaps some one knows the answer to.
Issue 1.
Given the following code:
public static void main(String args[])
MyClassLoader loader = new MyClassLoader("lic.dat");
System.out.println("Loading class ..." + "TestObject");
Object o = Class.forName("TestObject",true,loader).newInstance();
System.out.println("Object:" + o.toString());
TestObject tstObj = (TestObject) o;
tstObj.doIt();
What happens when executed is as follows. Class.forName calls our loader and does load the class as we hoped, it returns it as well, and the o.toString() properly executes just fine. The cast of the object to the actual TestObject fails with a class not found exception. We know why this happens but don't know what to do about it. It happens because the class that contains main was loaded by the system class loader (the primordial class loader as its sometimes called), That class loader does not know about TestObject, so when we cast even though the class is "loaded" in memory the class we are in has no knowledge of it, and uses its class loader to attempt to find it, which fails.
> So the question is how do you let the main class know to use our class loader instead of
the system class loader dispite the fact is was loaded by the system class loader.
Issue 2:
To make matters worse we want to do this with in an EJB container. So it now begs the question how do you inform an EJB container to use a specific class loader for some classes?
Mike...

Holy crap! We are in a similar situation. In creating a plugin engine that dynamically loads classes we use a new class loader for each plugin. The purpose is so that we can easily unload and/or reload a class at runtime. This is a feature supposedly done by J2EE app servers for hot-deploy.
So our plugins are packaged as JAR files. If you put any class in the CLASSPATH, the JVM class loader (or the class loader of the class that is loading the plugin(s)), will load the class. The JavaDoc API states that the parent classloader is first used to see if it can find the class. Even if you create a new URLClassLoader with NULL for parent, it will always use the JVM class loader as its parent. So, ideally, in our couse, plugins will be at web sites, network drives, or outside of the classpath of the application and JVM.
This feature has two benefits. First, at runtime, new updates of plugins can be loaded without having to restart the app. We are even handling versions and dependencies. Second, during development, especially of large apps that have a long startup time, being able to reload only one plugin as opposed to the annoying startup time of Java apps is great! Speeds up development greatly.
So, our problem sounds just like yours. Apparently, the Client, which creates an instance of the plugin engine, tries to access a plugin (after the engine loades it via a new classloader instance for each plugin). Apparently, it says NoDefClassFound, because as you say, the client classloader has no idea about the plugin class loaded by another classloader.
My co-developer came up with one solution, which I really dont like, but seems to be the only way. The client MUST have the class (java .class file) in its classpath in order to work with the class loaded by another class loader. Much like how in an EJB container, the web server calling to EJB MUST contain the Home and Remote interface .class files in its classpath, the same thing needs to be done here. For us, this means if a plugin depends on 5 others, it must contain ALL of the .class files of those plugins it depends on, so that the classloader instance that loads the plugin, can also see those classes and work with them.
Have you got any other ideas? I really dislike that this has to be done in this manner. It seems to me that the JVM should be able to allow various class loaders to work with one another in such a way that if a client loaded by one classloader has an import statement in it to use a class, the JVM should be able to fetch the .class out of the other classloader and share it, or something!
This seems to me that there really is no way to actually properly unload and then reload a class so that the JVM will discard and free up the previous class completely, while using the new class.
I would be interested in discussing this topic further. Maybe some others will join in and help out on this topic. I am surprised there isn't a top-level forum topic about things like class loaders, JVM, etc. I wish there was a way to add one!

Is Dynamic Class Loading(RMI) Possible in EJB?

In Java RMI,it allows dynamic class loading,that is when the stub and interface class files are modified by the server,the client side can download the updated stub and inteface classes.
As the remote interface of EJB extends Javax.ejb.EJBObject which in turn extends java.rmi.remote.Also the Home interface of EJB extends
javax.ejb.EJBHome which also extends java.rmi.remote.
Therefore I wonder if EJB also supports dynamic class
loading as RMI does.If yes,how to do so?Is it the responsibility of the Application Servers and transparent
to client? If No,then is this a defect in EJB??
Thank you very much in advance!!
John

This would be done by the container and is transparent to the client. Most app servers support "hot deploy" where you can deploy beans while the server is running. This requires dynamic class loading.

WSAD, EJB, runtime class load error

In WSAD 5.1.1, for my EJB Project
I added required JAR files to Java Build Path correctly
I have compliled my EJB successfully.
I have Generated RMIC and Deploy ...
- MY EJB runs fine to display "Hello"
- But When I run the same EJB to connect the database which requires a JAR file
it gives error class not found at : Class.forName(driver).newInstance();
Can any one tell how to add JAR file to EJB class path to run my EJB successfully??
Thanks in advance...

1. After you add jar to your project build path, it ONLY helps in compiling these java source code. Those jars do nothing while you EJBs and helper classes running in EJB container.
2. While EJBs and helper classes running in container, the Application Server (WSAD test server or Websphere application server) will look for jars in server's classpath.
The best approach for adding jars as I know:
1. You usually have a J2EE application project (EAR project).
2. Add (copy) jars into the EAR project.
3. Other projects (EJB or Java project) set dependency in project properties rather than adding jar into build path.
This approach will help your code running anywhere. Also you may find the following article by IBM very helpful to you.
http://www-106.ibm.com/developerworks/websphere/library/techarticles/0112_deboer/deboer.html
Regards,
Joe

Problem with Dynamically accessing EJB Class objects in WL 7.0 SP1

I am trying to build a component which has the ability to instantiate and execute
an known EJB method on the fly.
I have managed to build the component but when I try and execute it I get a ClassNotFoundException.
I know that the EJB I am trying to invoke is deployed and available on the server,
as I can see it in the console, I also seen to have been able to get the remote
interface of the object, my problem occurs when I try and access the class object
so I can perform a create on the object and then execute my method
The code I have written is below:
private Object getRemoteObject(Context pCtx, String pJNDIName, String pHomeBean)
throws Exception {
     String homeCreate = "create";
     Class []homeCreateParam = { };
     Object []homeCreateParamValues = {};
try {
//This call seems to work and doesn't throw an exception
Object home = pCtx.lookup(pJNDIName);
//However this call throws a java.lang.ClassNotFoundException
Class homeBean = Class.forName(pHomeBean);
Method homeCreateMethod = homeBean.getMethod(homeCreate,homeCreateParam);
return homeCreateMethod.invoke(home, homeCreateParamValues);
} catch (NamingException ne) {
logStandardErrorMessage("The client was unable to lookup the EJBHome.
Please make sure ");
logStandardErrorMessage("that you have deployed the ejb with the JNDI
name "+pJNDIName+" on the WebLogic server ");
throw ne;
} catch (Exception e) {
logStandardErrorMessage(e.toString());
throw e;
Any advice would be really appreciated, I'm fast running out of ideas, I suspect
it has something to do with the class loader but I'm not sure how to resolve it
Regards
Jo Corless

Hello Joanne,
Congratulations! I'm very happy that you've managed to fix your problem. It's
always essential to understand how to package applications when deploying on BEA
WebLogic. Usually, by throwing everything into an EAR file solves just about all
the class loader problems. :-) Let us know if you have any further problems that
we can assist you with.
Best regards,
Ryan LeCompte
[email protected]
http://www.louisiana.edu/~rml7669
"Joanne Corless" <[email protected]> wrote:
>
>
I've fixed it!!!!!!!!
Thanks to everyone who gave me help!!!!
The class loader was the culprit which is what I suspected all along.
As soon
as I put the 2 jar files I was using into an EAR file the problem went
away!!!!!
Thanks again
Jo Corless
"Ryan LeCompte" <[email protected]> wrote:
Hello Joanne,
As Mr. Woollen mentioned, I also believe it's a problem with the class
loader.
You need to be careful how you arrange your EJBs, because WebLogic has
a specific
method in which it loads classes in an EAR, JAR, and WAR file(s). Please
refer
to http://dev2dev.bea.com/articles/musser.jsp for more information about
BEA WebLogic
class loading mechanisms and caveats. Also, try printing out the various
methods
that are available on the object that was returned to you via reflection.
For
example, use the getMethods() method, which returns an array of Method
objects
that you can subsequently cycle through and print out the various method
names.
This way you can discover if the class found/returned to you is indeed
the one
you intend to locate.
Hope this helps,
Ryan LeCompte
[email protected]
http://www.louisiana.edu/~rml7669
Rob Woollen <[email protected]> wrote:
I believe the issue is the home interface class for this EJB is not
available in the class loader which is doing the reflection.
If you do:
getClass().getClassLoader().loadClass(homeInterfaceClassName)
I suspect it will fail. Reflection still requires that the class be
loadable.
-- Rob
Joanne Corless wrote:
Hi Slava,
If I make my code look like you describe below I get a compliationerror telling
me that
home.getMethod() is not recognised (no such method)
If I change it slightly and use
Method homeCreateMethod =
home.getClass().getMethod(homeCreate,homeCreateParam);
The code will compile OK but when executed it still throws a NoSuchMethodException
Any ideas ?
Thanks for your help so far
Regards
Jo Corless
Your code should look like
Object home = pCtx.lookup(pJNDIName);
Method homeCreateMethod =
home.getMethod(homeCreate,homeCreateParam);
return homeCreateMethod.invoke(home, homeCreateParamValues);
Regards,
Slava Imeshev
"Joanne Corless" <[email protected]> wrote in message
news:[email protected]...
Hi Ryan,
I also wanted to mention that if you do a "header search" in this
particular
newsgroup
with the search query as "reflection", you will see many previousmessages
regarding
reflection and EJBs. I believe you could learn a lot from thedifficulties
that
others have faced and solved.I tried that and although there was a number of similar cases noneof them
actually
seem to fix my issue. Thanks for the suggestion though
Are the EJBs that you are trying to access accessible via your
system
classpath?
Try to avoid having them accessible via the main system classpath,and
only bundle
them in your appropriate EJB jar files (contained in an EAR file,for
example).Maybe I should have laid the problem out a little clearer.
I have a number of EJB's bundled up in a JAR file which is hot deployedto
the
server. Within this first JAR file is an EJB (SSB) component that
needs
to
be
able to invoke a known method on another EJB. This second EJB may
or
may
not be
within the first JAR file but it also will be hot deployed.
The component trying to invoke the method on the 2nd EJB has to
be
able to
create
an instance of the 2nd EJB without actually knowing anything bar
a
JNDI
Name which
is passed in at runtime.
I can get as far as doing the
Object home = pCtx.lookup(pJNDIName);
This returned a class with the name
"com.csc.edc.projects.allders.httppostoffice.postman.PostmanBean_mp8qy2_Home
Impl_WLStub"
My problem seems to occur when I try and invoke the create method
Method homeCreate = home.getClass().getMethod("create", new Class[0]);
My code throws a java.lang.NoSuchMethodException at this point so
I
am
unable
to progress to the next step of :
Object bean = homeCreate.invoke(home, null);
So I can return the instantiated bean back to the calling client.
Why am I getting the NoSuchMethodException, is is because I am gettinga
stub
back rather than the home interface and if so how do I get the truehome
interface
from the bean
Thanks in advance
Jo Corless

How can I make server use single class loader for several applications

I have several web/ejb applications. These applications use some common libraries and should share instances of classes from those libraries.
But applications are being deployed independently thus packaging all them to EAR is not acceptable.
I suppose the problem is that each application uses separate class loader.
How can I make AS use single class loader for a set of applications?
Different applications depend on different libraries so I need a way that will not share library for all applications on the domain but only for some exact applications.
When I placed common jar to *%domain%/lib* - all works. But that jar is shared between all applications on the domain.
When I tried to place common jar to *%domain%/lib/applibs* and specified --libraries* attribute on deploying I got exception
java.lang.ClassCastException: a.FirstDao cannot be cast to a.FirstDaoHere http://download.oracle.com/docs/cd/E19879-01/820-4336/6nfqd2b1t/index.html I read:
If multiple applications or modules refer to the same libraries, classes in those libraries are automatically shared.
This can reduce the memory footprint and allow sharing of static information.Does it mean that classes should be able to be casted ?

You didn't specify which version of the application server you are using, but the config is similar as long as you know what to look for. Basically, you need to change the classloader delegation. Here's how it is done in 8.2
http://download.oracle.com/docs/cd/E19830-01/819-4721/beagb/index.html

Dynamic class loading failed, why?

Hi there!
We are using WebLogic 5.1 togehter with Apache1.3.22/Tomcat4.01. It all worked
fine for about 2 month. All of a sudden, dynamic class loading refuses to work.
From one day to the other I got the excpetion: javax.naming.CommunicationException.
Root exception is weblogic.rmi.UnmarshalException: Unmarshalling return
- with nested exception:
[java.lang.ClassNotFoundException: class com.dsh.egb.aks.betrieb.ejbs.AnmeldenEJBHomeImpl_ServiceStub
previously not found]
Why does this happen? I can not remember having touched any properties.
Please help,
Heiner

If you were relying on client network classloading stubs from WebLogic, you
can test if it still works by pointing your browser to
htpp://yourweblogic:7001/classes/com/dsh/egb/aks/betrieb/ejbs/AnmeldenEJBHomeImpl_ServiceStub.class
Heiner Amthauer <[email protected]> wrote:
Hi there!
We are using WebLogic 5.1 togehter with Apache1.3.22/Tomcat4.01. It all worked
fine for about 2 month. All of a sudden, dynamic class loading refuses to work.
From one day to the other I got the excpetion: javax.naming.CommunicationException.
Root exception is weblogic.rmi.UnmarshalException: Unmarshalling return
- with nested exception:
[java.lang.ClassNotFoundException: class com.dsh.egb.aks.betrieb.ejbs.AnmeldenEJBHomeImpl_ServiceStub
previously not found]
Why does this happen? I can not remember having touched any properties.
Please help,
Heiner--
Dimitri

Class loader Exception

I am getting the following error even though the corresponding file is present in the app.jar.
This happens when hibernates are getting loaded , when i start the oracle app server.
Does anyone knows why its so.
Caused by: org.hibernate.MappingException: entity class not found: com.iflex.fcr.app.deposit.td.us.dto.DepositRateHistoryDTOCheckNew
     at org.hibernate.mapping.PersistentClass.getMappedClass(PersistentClass.java:99)
     at org.hibernate.tuple.PropertyFactory.getGetter(PropertyFactory.java:166)
     at org.hibernate.tuple.PropertyFactory.buildIdentifierProperty(PropertyFactory.java:44)
     at org.hibernate.tuple.EntityMetamodel.<init>(EntityMetamodel.java:115)
     at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:412)
     at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:108)
     at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55)
     at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:216)
     at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1176)
     at com.iflex.fcr.infra.das.orm.hibernate.SessionFactoryLoader.<clinit>(Unknown Source)
     ... 5 more
Caused by: oracle.classloader.util.AnnotatedClassNotFoundException:
     Missing class: com.iflex.fcr.app.deposit.td.us.dto.DepositRateHistoryDTOCheckNew
     Dependent class: org.hibernate.util.ReflectHelper
     Loader: global.libraries:1.0
     Code-Source: /D:/product/10.1.3.1/OracleAS_3/j2ee/FSI_RETAIL/applib/hibernate313.jar
     Configuration: <code-source> in /D:/product/10.1.3.1/OracleAS_3/j2ee/FSI_RETAIL/config/server.xml
This load was initiated at global.libraries:1.0 using the Class.forName() method.
The missing class is not available from any code-source or loader in the system.
     at oracle.classloader.PolicyClassLoader.handleClassNotFound(PolicyClassLoader.java:2078)
     at oracle.classloader.PolicyClassLoader.internalLoadClass(PolicyClassLoader.java:1679)
     at oracle.classloader.PolicyClassLoader.loadClass(PolicyClassLoader.java:1635)
     at oracle.classloader.PolicyClassLoader.loadClass(PolicyClassLoader.java:1620)
     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
     at java.lang.Class.forName0(Native Method)
     at java.lang.Class.forName(Class.java:164)
     at org.hibernate.util.ReflectHelper.classForName(ReflectHelper.java:108)
     at org.hibernate.mapping.PersistentClass.getMappedClass(PersistentClass.java:96)
     ... 14 more

Neither, not using Oracle HTTP Server nor using JDK 1.4 incluence the behaviour of OC4J. It is your application deployment. As it should be with every Java EE server you provide an EAR file structure with modules like WAR files or EJB jar files. Each of these modules has more or less its own class loading environment.
OC4J however supports application and global shared libraries. Application shared libraries can be packaged in the EAR file using the Java EE 5 library mechanism. In essence your libraries must be known by the class loader of the Java EE module otherwise your application doesn't work.
What I need to know is what type of application (WAR, EJB, combo of both) you're using and how the files are laid out in the directory structure.
To have an example, see this blog entry: http://blogs.oracle.com/olaf/2007/07/25
--olaf

Connector Class Loader in OC4J Classloader Tree

Where does connector class loader fit in the OC4J class loader tree. Is it a parent to the EJB Classloader (as in SunOne) or does it use its own classloader to load classes (similar to weblogic). Becos it can impact visibility into resource adapter's classes.

The classloader tree in the ClassLoadingInOC4J_WP.pdf applies to 10.1.2 and 9.0.4, probably even earlier, where the connector classcloader is the root classloader of an application.
For 10.1.3, the root classloader of an application loads both connector jars and ejb jars. See chapter 3 of Oracle Containers for J2EE Developer's Guide(10.1.3 preview).

Weblogic Class Loader issues.

Hi all!
Let me explain my problem.
I have an EJB which has in its same Java package some support classes
& also a startup class. I created an EJB jar file (containing the home,
remote, bean, the deployment descriptors & the container generated stubs)
for deployment. I also compiled all the support classes & the startup class
into the /weblogic/myserver/serverclasses directory. I also added the
required entries in the weblogic.properties file for the startup class.
Now the problem is that the support classes & the startup class contain
methods & constructors which have package level access (i.e the default
access in Java). At runtime, when my bean tries to access one of these
methods, an IllegalAccessException is thrown.
I understand that this exception is thrown when one tries to access a
method which should not be accessed (like private/protected/cross-package
access). However, both the EJB & these classes are in the same package.
So this should not be thrown.
Now the next thing I thought is that the EJB & the support classes are
being loaded by 2 different classloaders. I guess the classes under
/weblogic/myserver/serverclasses are being loaded by the WebLogic
Server ClassLoader & the EJB bean classes are being loaded by the
specialized EJB ClassLoader.
Now my question is,
1) Is it the case that the WebLogic Server does not recognize that the
EJB Bean class is in the same package as the support classes because
they are loaded by 2 separate class loaders? Please note that the EJB
jar file does not contain any support classes - so there is no
duplicate classes here.
2) Is this a bug?
3) What should I do to prevent this problem?
Some workarounds that I have done are:
1) Copied the Bean.class (implementation class of EJB bean) into the
serverclasses directory. Now the server does not throw any
IllegalAccessException. -- This, however, does not appeal as a solution
since it looks like the Bean class is now being loaded by the WebLogic
Class Loader instead of from the EJB jar file.
2) I changed all the default package access methods to public methods.
Works like a charm. -- Problem is that this is a third party set of classes
which I would like to avoid modifying.
Hope this is not too confusing. Please let me know if you need any further info.
Thanks much in advance,
--Das

You have to tell WLAS where to load your new classes. You can change
          workingDir of your JSP configuration in weblogic.properties to point to your
          new class directory.
          Cheers - Wei
          Hyung-Jin Kim <[email protected]> wrote in message
          news:[email protected]..
          > It seems that if I compile a class that a JSP uses while Weblogic is
          > running, Weblogic's class loader has this nasty habit of caching/writing
          > the class that already has loaded into memory into:
          >
          > weblogic/myServer/classfiles
          >
          > Weblogic then refers to the older class file under the above directory
          > when the server is started again. Is there any way to turn this "class
          > loader caching" off in Weblogic? Thanks!
          >
          > -hjk
          >

SJSAS 8.2 EJB class loader

Similar Messages

Maybe you are looking for