Re: mx4j and weblogic problems!

Hi Zahid,

[sorry for posting a second time, but the first was rejected by
sourceforge due to a wrong mail-header]

Zahid Ebrahim wrote:

> Doe snayone knwo how to force weblogic to use mx4j rather than its own
> implementation of jmx? I have a web application running on weblogic. In
> the WEB-INF/lib directory of the web app I have my mx4j jar files. One
> of the Classes is ObjectName which I am using to try and invoke methods
> on a remote MBeanServer.

What version of Weblogic are you using ? If you are using something
below 9 you will not be able to get in a second JMX implementation. For
 for Weblogic 9 which is JMX 1.2 compatible (Ver. 8.1 has only 1.0) you
might be able to get a different implementation of a MBeanServer but the
core classes (like ObjectName) will be the ones from the JMX
implementation on the system classpath.

The problem in using JMX in application for a J2EE enviroment are mostly
connected to classloader issues and that the classes on the
systemclasspath (weblogic.jar) take always the highest precedence due to
the 'parent loader first' paradigm for class resolving.
Since weblogic provides javax.management within weblogic.jar, these
classes get always loaded from the system class loader. If your MBeans
must get instantiated from within an MBeanServer, they need to be loaded
also from the Systemclassloader (since the system classloader has no
access to your webapps's classloader).

There is a way to tell Weblogic 8 that it should first look into your
own classes by setting 'prefer-web-inf-classes' to 'true' in
WEB-INF/weblogic.xml. Well, this work for most classes, but not for
javax.management.*. For the reason, please check out
http://forums.bea.com/bea/message.jspa?messageID=200016727&tstart=0

You could try to put mx4j.jar on the system classpath (e.g. in the
startup script) before weblogic jar, but for Weblogic 8.1. this must be
a JMX 1.0 version of mx4j. I'm afraid this won't work either.

Actually, IMO the main problem are not these classloader issues but that
the JMX specification requires for a JMX implemention to provided
certain javax.management *classes* and not only implementation of
javax.management *interfaces* (and base classes like ObjectName are
distributed with the specification). It's really not very nice to have a
 handful of different (and incompatible) javax.management.ObjectName
classes out there.

This will get much better when Weblogic and co. are going to use JMX
from Java 5. But this might take some time .....

But coming back to your problem: Why don't you use a JSR 160 connector
to directly call your remote MBeanServer ? I didn't get it why you have
to send a ObjectName object from one side to the other ....

ciao....
-- 
                                                        ...roland huss
                                                             consol.de



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf