RE: [PROPOSAL] Re: Tomcat5 MBeans/JMX context creation

2004-03-02 Thread Shapira, Yoav

Hi,

>Proposed object names for the classloaders:
>
>Main CLs:
>[Server]:type=ServerClassLoader,name=(common|shared|server)
>Webapps CLs:
>[EngineName]:type=WebappClassLoader,path=[context_path],host=[host_name
]
>
>I am likely to move jmx.jar to "bin", since bootstrap will need to
>register the CLs it creates. The good thing is that this way all JDKs
>will have JMX in the classpath, like JDK 1.5 has.
>
>Once this "minor" issue is cleared out, this should all work.
>
>Any comments on this ?

Even though you've already done and committed this, I still wanted to +1
it.  Getting the JMX behavior under JDK 1.4 to be much closer to 1.5 is
a significant enhancement.  Thanks, as always ;)

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PROPOSAL] Re: Tomcat5 MBeans/JMX context creation

2004-03-02 Thread Remy Maucherat
Remy Maucherat wrote:
Any comments on this ?
All done. The changes are not too intrusive, since TC 5 already required 
JMX.
This should hopefully make Tomcat useable through JMX remote on JDK 1.5 
(which was my plan, if you remember my emails a few weeks ago).

The object name to use in most cases is 
Catalina:type=ServerClassLoader,name=server (the object name is mostly 
hardcoded)

The webapp CLs are also registered, which is not as useful. If some 
webapps are JMX aware, this could be used to instantiate their MBeans 
remotely.
Example object name: Catalina:type=WebappClassLoader,path=/,host=localhost

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


[PROPOSAL] Re: Tomcat5 MBeans/JMX context creation

2004-03-01 Thread Remy Maucherat
Randy Watler wrote:

Remy Maucherat wrote:


Randy Watler wrote:


I am currently experimenting with the Java 1.5 remote JMX/MBeans for 
use in our build process.
...
Can anyone clarify how the "createStandardContext" should be invoked?


You can look at the JBoss integration code for examples.
...
There's additional code, but this is for creating a basic context, and 
configuring its classloader. The Tomcat code which allows doing this 
is a lot more recent than the harcoded admin webapp methods, and is 
more JavaBean like.


Remy,

Note that I am using the JMX remote "Out-of-the-box" Java 1.5 Monitoring 
and Management, so some of the JBoss setup may not apply, (like the 
ClassLoader configuration that passes object instances). Here is what I 
am trying:

// create context
mbeanServer.createMBean( "org.apache.commons.modeler.BaseModelMBean", 
context,
 new Object [] { 
"org.apache.catalina.core.StandardContext" },
 new String [] { "java.lang.String" } ) ;
mbeanServer.setAttribute( context, new Attribute( "docBase", 
"/tmp/testsite" ) ) ;
mbeanServer.setAttribute( context, new Attribute( "path", "/testsite" ) ) ;


> Unfortunately, the createMBean call above throws the following exception:
>
> javax.management.ReflectionException: The MBean class could not be
> loaded by the default loader repository
> at
> 
com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.findClassWithDefaultLoaderRepo
> sitory(MBeanInstantiatorImpl.java:61)
> at
> 
com.sun.jmx.mbeanserver.MBeanInstantiatorImpl.instantiate(MBeanInstantiatorI
> mpl.java:378)
> at
> 
com.sun.jmx.mbeanserver.JmxMBeanServer.instantiate(JmxMBeanServer.java:1011)
> at
> 
com.sun.jmx.remote.security.MBeanServerAccessController.createMBean(MBeanSer
> verAccessController.java:167)
> at
> 
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.
> java:1418)
> at
> 
javax.management.remote.rmi.RMIConnectionImpl.access+100(RMIConnectionImpl.j
> ava:81)
> at
> 
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMICon
> nectionImpl.java:1301)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> 
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConne
> ctionImpl.java:1395)
> at
etc, etc

This makes sense to me perhaps because the JVM does not understand the 
Tomcat5 ClassLoader hierarchy and cannot load 
org.apache.commons.modeler.BaseModelMBean, no? Consequently, I am 
guessing that I am not going to be able to create new MBeans without 
doing so via existing registered MBeans? Am I missing something that 
should be obvious? Perhaps Tomcat can register its own "loader 
repository" somehow?
Well, ok, there's a problem.

You have to use that form of createBean, otherwise it's not going to 
work:  ObjectInstance createMBean(String className, ObjectName name, 
ObjectName loaderName, Object[] params, String[] signature)

The problem is that right now the CL aren't registered in JMX. Woops. 
Better luck next release, I guess ;) (I think I had written somewhere 
that the JMX stuff was "not done yet")

To address this issue, the classloaders used and created by Tomcat 
standalone should be registered with JMX.
The registration will take place:
- in ClassLoaderFactory for the standard classloaders (common, shared 
and server)
- in WebappLoader for the webapp classloaders (the loaders are already 
registered)
To avoid dependencies on the rest of the world (commons-*), the 
StandardClassLoader MBean will be a standard MBean (not too hard: no 
attributes or operations are needed).
The webapp classloader only needs an entry in mbeans-descriptors.

Proposed object names for the classloaders:

Main CLs:
[Server]:type=ServerClassLoader,name=(common|shared|server)
Webapps CLs:
[EngineName]:type=WebappClassLoader,path=[context_path],host=[host_name]
I am likely to move jmx.jar to "bin", since bootstrap will need to 
register the CLs it creates. The good thing is that this way all JDKs 
will have JMX in the classpath, like JDK 1.5 has.

Once this "minor" issue is cleared out, this should all work.

Any comments on this ?

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]