geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Fairly big problem with tomcat integration
Date Mon, 08 May 2006 06:42:25 GMT

On May 7, 2006, at 6:56 PM, anita kulshreshtha wrote:

>     I have a similar concern with *Connectors. The attributes of the
> connectors should be set only via GBeans. But using Jconsole one could
> easily modify the attributes of the tomcat connector Mbeans, thereby
> creating an inconsistent state and unpredictable behavior. It is very
> easy to mistake one for the other. The new debug console would also
> allow this.

It looks to me as if any changes made to a tomcat connector mbean  
will be visible in the gbean console, but that the new value will not  
be saved in the attribute store (config.xml).  Changes made in the  
gbean console will be visible in the mbean server and will also be  
saved in config.xml.  Is this the behavior you see?

thanks
david jencks

>
> Thanks
> Anita
>
>
> --- David Jencks <david_jencks@yahoo.com> wrote:
>
>> I've run into a couple fair-sized problems with the tomcat
>> integration and I'm not sure how to proceed.  The problems are:
>>
>> 1. commons-modeler 1.1 is broken for use in a jsr-77 compliant
>> environment.  The BaseModelMBean has a method
>> ObjectName getObjectName()
>>
>> which is used in preference to any method on the wrapped resource
>> object such as the jsr-77 required
>>
>> String getObjectName()
>>
>> method implemented by StandardContext and StandardWrapper (the
>> servlet wrapper).  As a result,  getting the value of the objectName
>>
>> attribute from the MEJB returns an ObjectName rather than the spec
>> required String.
>>
>> This is fixed in the commons modeler svn trunk (actually fixed in rev
>>
>> 139253 sept 2003
>>
>> http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/modeler/
>> trunk/src/java/org/apache/commons/modeler/BaseModelMBean.java?
>> rev=139253&r1=139233&r2=139253
>> )  but AFAICT there have been no releases since that fix.  Current
>> trunk does not build cleanly for me, I get a test failure.
>>
>> I imagine that since the commons modeler community has not released
>> anything for more than 1.5 years despite this fix being required for
>>
>> use in a j2ee compliant environment we have 0 chance of getting an
>> official release any time soon.
>>
>> About the only thing I can think to do here is make a private build
>> of commons-modeler.
>>
>> I believe we did not see this earlier because the MEJB was not
>> showing anything for the tomcat created mbeans since it was using a
>> "fake" mbean server wrapping the geronimo kernel, showing only
>> gbeans.  Now we are bridging gbeans into the mbean server and MEJB is
>>
>> querying the real mbean server.
>>
>> 2. We have 2 mbeans claiming to be the web module: one from our
>> gbean, which has no servlets, and one from  tomcat, which actuallly
>> has the servlets.  These have rather different naming policies.  For
>>
>> instance, the tomcat one has J2EEModule=//context-root whereas ours
>> has J2EEModule=jarname or configid/moduleId.
>>
>> I'm tempted to make our gbean claim to be a WebModuleWrapper or
>> something like that so jsr-77 only finds one mbean/web module.  I'd
>> like to get at least the J2EEApplication set correctly on the tomcat
>>
>> mbeans and preferably get the WebModule to agree with our setting.
>>
>> Comments? Other proposals?
>>
>> thanks
>> david jencks
>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com


Mime
View raw message