dev@glassfish.java.net

Re: any thoughts on bug #6342808?

From: Jan Luehe <Jan.Luehe_at_Sun.COM>
Date: Tue, 01 Nov 2005 10:06:24 -0800

Lloyd,

Jan Luehe wrote On 10/27/05 18:34,:
> Lloyd,
>
> Lloyd L Chambers wrote On 10/27/05 13:03,:
>
>>Jan,
>>
>>6342808 "JSR 77 specification violation when deploying sample app
>>jndi-url.ear"
>>
>>Deploy sample application 'jndi-url.ear' (I used the GUI). Observe the
>>following MBeans ("com.sun.appserv:" omitted for clarity):
>>
>>j2eeType=AppClientModule,name=jndi-urlClient.jar,J2EEServer=server,J2EEApplication=jndi-url,category=runtime
>>
>>j2eeType=EJBModule,name=jndi-urlEjb.jar,J2EEServer=server,J2EEApplication=jndi-url,category=runtime
>>
>>j2eeType=J2EEApplication,name=jndi-url,J2EEServer=server,category=runtime
>>j2eeType=StatefulSessionBean,name=jndi-urlEJB,J2EEServer=server,J2EEApplication=jndi-url,EJBModule=jndi-urlEjb.jar,category=runtime
>>
>>j2eeType=WebModule,name=//server/jndi-url,J2EEServer=server,J2EEApplication=null
>>
>>
>>PROBLEM: j2eeType=WebModule,name=//server/jndi-url has
>>'J2EEApplication=null'. According to the JSR 77 spec, it must have
>>'J2EEApplication=jndi-url'. Also, there is no 'category=runtime'
>>property as with the other JSR 77 MBeans associated with this application.
>>
>>HOWEVER: Is this some kind of special case? The archive 'jndi-url.ear'
>>doesn't contain any 'war' file. Is there some special case in which a
>>WebModule is implicitly loaded?
>
>
>
> The EAR in question contains a nested app client. As the app client
> module is loaded, the web container registers an adhoc web module at a
> specified context root (or leverages a web module that already exists
> at that context root), along with a dedicated servlet that will handle
> all Java Web Start related HTTP requests. I don't think it makes any
> sense for the adhoc web module or its servlet to be managed via JMX. I
> will therefore change the code so that no mbeans are registered when an
> adhoc web module is started.


After running QL with my change and getting 2 failures, I realized that
ad-hoc web modules and their servlets must register JSR77 mbeans with
JMX, in order for Tomcat's MapperListener, which listens for
notifications emitted by the JMX registry, to be able to update its
mapping tables, which will route subsequent requests to the appropriate
web module and servlet.

I've changed the ad-hoc registration API to accept an application name
parameter, which will be reflected in the JSR 77 and monitoring
mbean object names of ad-hoc web modules and their servlets, and changed
the callers of this API to provide such a name.


Jan