Re: JMX Weblogic Stop Task

[Alban Peignier <al...@free.fr>]

>
>
>> The BEA support is currently studying the problem.
>
I spent several hours before finding the problem with the help of the 
french BEA support. It's in fact a class loading problem into the 
weblogic API.

If you look at the stack trace, you'll see the ApplicationManager class 
and the loadClass methods. At this moment, the weblogic API tries to 
load dynamic the MBeanStub class. This class is the same weblogic.jar 
file than ApplicationManager .. and it doesn't find it .. It remind me a 
problem of the same kind with a Corba ORB. The ORB implementation used 
the ClassLoader associated to the current Thread 
(Thread.getContextClassLoader) and not the ClassLoader which has loaded 
the ORB classes.
This supposition was confirmed when I looked at the Java task 
implementation. It uses the ExecuteJava class to execute the specified 
application .. and the ExecuteJava changes the Context ClassLoader 
before executing the application.

When a thread executes a Ant target, the Context ClassLoader is the JVM 
ClassLoader. When a thread executes a application into the Java target, 
the Context ClassLoader is the AntClassLoader which the defined 
classpath. In the second case, the weblogic.jar is present into the 
Context ClassLoader .. and it's work ...

To verify this interresting suppositon, I added the weblogic.jar to the 
Ant JVM classpath .. and it worked :o))

The french BEA support confirms with the ApplicationManager source that 
the Context ClassLoader is used. The BEA development team confirms that 
the ClassLoader associated to the ApplicationManager 
(ApplicationManager.class.getClassLoader()) isn't used for a security 
purpose. No modification is planned.

I hope this analysis will be usefull to anyone else :o)

Alban

I spent several hours before finding the problem with the help of the 
french BEA support. It's in fact a class loading problem into the 
weblogic API.   

If you look at the stack trace, you'll see the ApplicationManager class 
and the loadClass methods. At this moment, the weblogic API tries to 
load dynamically the MBeanStub class. This class is the same file 
weblogic.jar than ApplicationManager .. and it doesn't find it ..

It reminded me a problem of the same kind with a Corba ORB. The ORB 
implementation was using the ClassLoader associated to the current 
Thread (Thread.getContextClassLoader) and not the ClassLoader which had 
loaded the ORB classes. 
This supposition was confirmed when I looked at the Java Ant task code. 
It uses the ExecuteJava class to execute the specified application .. 
and the ExecuteJava changes the Context ClassLoader before executing the 
application.   
When a thread executes a Ant target, the Context ClassLoader is the JVM 
ClassLoader. When a thread executes a application into the Java target, 
the Context ClassLoader is the AntClassLoader with the classpath 
specified to the target. In the second case, the weblogic.jar is present 
into the Context ClassLoader .. and it works ...   

To verify this interesting supposition, I added the weblogic.jar to the 
classpath of the Ant JVM  .. and it works :o))   

The french BEA support confirms that only the Context ClassLoader is 
used into the ApplicationManager. The BEA development team confirms that 
the ClassLoader associated to the ApplicationManager 
(ApplicationManager.class.getClassLoader()) isn't used for a security 
reason. No modification is planned.   

I hope this analysis will be useful to someone else :o)

Alban

-- 
http://www.tryphon.org/~alban