You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Alban Peignier <al...@free.fr> on 2003/01/29 11:24:28 UTC
JMX Weblogic Stop Task
Hello,
I need to manage a small troupe of WebLogic 6.1 clusters. Because the
whole deployement process is made via an ant script, i tried to study
the possibility to stop a weblogic cluster with a small Java program. For
the lucky people who never tried to stop a weblogic 6.1 cluster, I remind
that this operation can't be made with the Ant WLStop task because a
cluster uses one or more "managed" weblogic server which can't be stopped
directly but only through the "administration" weblogic server.
The solution is to use the "management" weblogic API (based on the JMX
API). It works when you include this code into a classic java application.
But when the same Java code is running whithin an Ant task, the Weblogic
internal classes throw a NullPointerException.
I'll contact the BEA technical support but I want to know if someone has
already experienced this kind of problem.
Contact me if you need more details.
Thanks, Alban
--- Exception Log ---
java.lang.ExceptionInInitializerError: java.lang.NullPointerException
at
weblogic.utils.classloaders.ServletClassFinder.<init>(ServletClassFinder.java:32) at
weblogic.j2ee.ApplicationManager.getFinder(ApplicationManager.java:283) at
weblogic.j2ee.ApplicationManager.loadFromNetwork(ApplicationManager.java:261) at
weblogic.j2ee.ApplicationManager.loadClass(ApplicationManager.java:194) at
weblogic.j2ee.ApplicationManager.loadClass(ApplicationManager.java:106) at
weblogic.rmi.internal.ClientRuntimeDescriptor.computeInterfaces(ClientRuntimeDescriptor.java:218) at
weblogic.rmi.internal.ClientRuntimeDescriptor.intern(ClientRuntimeDescriptor.java:111) at
weblogic.jndi.WLInitialContextFactoryDelegate.<clinit>(WLInitialContextFactoryDelegate.java:154) at weblogic.jndi.Environment.getContext(Environment.java:208)
at weblogic.jndi.Environment.getInitialContext(Environment.java:191)
at weblogic.management.Helper.getMBH(Helper.java:58)
at weblogic.management.Helper.getAdminMBeanHome(Helper.java:28)
at WLJMXStop.execute(WLJMXStop.java:71)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) at org.apache.tools.ant.Task.perform(Task.java:319)
at org.apache.tools.ant.Target.execute(Target.java:309)
at org.apache.tools.ant.Target.performTasks(Target.java:336)
at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
at org.apache.tools.ant.Project.executeTargets(Project.java:1250)
at org.apache.tools.ant.Main.runBuild(Main.java:610)
at org.apache.tools.ant.Main.start(Main.java:196)
at org.apache.tools.ant.Main.main(Main.java:235)
---
--
http://www.tryphon.homeip.net/~alban
---------------------------------------------------------------------
To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ant-dev-help@jakarta.apache.org
Re: JMX Weblogic Stop Task
Posted by 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
Re: JMX Weblogic Stop Task
Posted by Paul King <ki...@asert.com.au>.
Alban Peignier wrote:
>I've found the same workaround. .. but I doesn't need to fork :
>
>--- build.xml part ---
> <target name="test.main" depends="prepare, prepare.classpath, test.check">
> <java classname="Main" classpathref="classpath">
> <arg line="--server ${server}"/>
> <arg line="--password ${password}"/>
> <arg line="--url ${adminurl}"/>
> </java>
> </target>
>
> <target name="test.task" depends="prepare, prepare.classpath, test.check">
> <taskdef name="wljmxstop" classname="WLJMXStop"
> classpathref="classpath" />
> <wljmxstop username="system" servername="${server}"
> password="${password}" adminserverurl="${adminurl}"/>
> </target>
>---
>
>The 'test.main' target works. The 'test.task' targt doesn't work.
>
>The BEA support is currently studying the problem.
>
>Alban
>
>
>
My experience (so far) has been that it would be easier to write a
facade task
which collects all the params (with the exact params you have in your
current
custom task) but then calls Java task methods underneath the covers.
But please let me know if BEA give you a better work around. It would
really help me solve a similar problem I have been having.
Paul.
---------------------------------------------------------------------
To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ant-dev-help@jakarta.apache.org
Re: JMX Weblogic Stop Task
Posted by Alban Peignier <al...@free.fr>.
I've found the same workaround. .. but I doesn't need to fork :
--- build.xml part ---
<target name="test.main" depends="prepare, prepare.classpath, test.check">
<java classname="Main" classpathref="classpath">
<arg line="--server ${server}"/>
<arg line="--password ${password}"/>
<arg line="--url ${adminurl}"/>
</java>
</target>
<target name="test.task" depends="prepare, prepare.classpath, test.check">
<taskdef name="wljmxstop" classname="WLJMXStop"
classpathref="classpath" />
<wljmxstop username="system" servername="${server}"
password="${password}" adminserverurl="${adminurl}"/>
</target>
---
The 'test.main' target works. The 'test.task' targt doesn't work.
The BEA support is currently studying the problem.
Alban
--
http://www.tryphon.homeip.net/~alban
---------------------------------------------------------------------
To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ant-dev-help@jakarta.apache.org
Re: JMX Weblogic Stop Task
Posted by Paul King <ki...@asert.com.au>.
Alban Peignier wrote:
>I need to manage a small troupe of WebLogic 6.1 clusters...
>...
>The solution is to use the "management" weblogic API (based on the JMX
>API). It works when you include this code into a classic java application.
>But when the same Java code is running whithin an Ant task, the Weblogic
>internal classes throw a NullPointerException.
>I'll contact the BEA technical support but I want to know if someone has
>already experienced this kind of problem.
>Contact me if you need more details.
>
I have seen the exact same error - never fully tracked it down. I believe
the ant classloader interacts with the weblogic over-the-wire classloader.
The only solution that worked for me at the time was to simply have
a java task with fork="true" and put all the smarts in there. Even this
could
be hidden behind a facade task but I never bothered to try that.
Paul.
---------------------------------------------------------------------
To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ant-dev-help@jakarta.apache.org