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.
The BEA support is currently studying the problem.
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
