tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: [POLL] Tomcat 3.3.2 updates
Date Wed, 25 Sep 2002 13:15:53 GMT
Bill Barker wrote:

> My first choice is still for split-jars in j-t-c util.  In TC 4.1.x/5.0
> both
> jars go to server/lib (same as 3.3 lib/container).  So Costin's dream of
> every servlet being able to access JMX still requires a [VOTE]. :-)  In
> 3.3
> we can send one to lib/container and one to lib/common.  Easy, simple,
> secure.
> 
> However, since Costin is already on record as vetoing split-jars, I'm +1
> for this module.

Sorry, I didn't meant it as a 'veto'. 

Usually 'veto' is used for code commits - on long term proposals like
that a -1 is more 'I don't think this is the best idea'. And my reason
is more that I don't want to add instability or code changes until 
the JMX is actually usefull - that requires adding getters for intersting
information and implementing the config storage layer ( for 5.0, but 
that can be used for 3.3 too or anything else ).

In addition, it may be a good moment to merge the class loader tricks 
and create a common loader and loader policy. 

Costin

> 
> As much as I would really like JMX support, (with my webmaster hat on) I
> can't take it at the expense of choice of XML parsers.  (Of course, this
> means nothing, since at the end of the day, I can (and will :) just edit
> my
> copy of  j-t-c/util/build.xml).
> 
> ----- Original Message -----
> From: "Larry Isaacs" <Larry.Isaacs@sas.com>
> To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
> Sent: Tuesday, September 24, 2002 10:10 PM
> Subject: RE: [POLL] Tomcat 3.3.2 updates
> 
> 
> Hi Henri,
> 
> The basic problem is that o.a.t.u.mx.DynamicMBeanProxy.java
> carries dependencies, which imposes requirements on the
> classloader hierarchy for any class that uses it.  In this
> case the "jmx", "parser", and "tranform" jars would need
> to move to lib/common where tomcat-util.jar lives.  I would
> be in favor of sacrificing code reuse to avoid these
> restrictions.  I think this would be a lot easier than
> trying to implement classloader tricks.
> 
> I think the best way of accomplishing this is to make
> the JMX support an add-on module with its own local copy
> of DynamicMBeanProxy.  Then, there is no impact on
> classloaders and enabling is simply dropping a war file
> in the "modules" directory.
> 
> A first pass implementation, derived from what you have
> done, can be found here:
> 
> <http://jakarta.apache.org/~larryi/JmxSupport.war>
> 
> It contains the mx4j jars, so they aren't needed in
> lib/container.  If this approach is acceptable, I can
> update the jakarta-tomcat build to include it.
> 
> Note: You will need the recent TrustedLoader.java
> update before add-ons will deploy successfully.
> 
> Cheers,
> Larry
> 
> 
>> -----Original Message-----
>> From: Henri Gomez [mailto:hgomez@apache.org]
>> Sent: Tuesday, September 24, 2002 6:32 PM
>> To: Tomcat Developers List
>> Subject: Re: [POLL] Tomcat 3.3.2 updates
>>
>>
>> Bill Barker wrote:
>> > ----- Original Message -----
>> > From: "Henri Gomez" <hgomez@apache.org>
>> > To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
>> > Sent: Tuesday, September 24, 2002 1:38 AM
>> > Subject: Re: [POLL] Tomcat 3.3.2 updates
>> >
>> >
>> >
>> >>Larry Isaacs wrote:
>> >>
>> >>>Hi Henri,
>> >>>
>> >>>I would prefer to minimize the impact of upgrading from
>> >>>3.3.1 to 3.3.2.  I agree with Costin that using 4 with
>> >>>documentation on the steps to enable the MxInterceptor
>> >>>would be a resonable way to implement this.
>> >>
>> >>So I'll have to take a look at MxInterceptor to see if
>> >>nothing is broken ...
>> >>
>> >>BTW, I could spend sometimes to play ClassLoader,
>> >>making MxInterceptor loading mx4j/mx4-tools from
>> >>container ClassLoader but I need some advices.
>> >>
>> >
>> >
>> > You can get the loader from ContextManager.getContainerLoader().
>> >
>> I tried to use it before loading JMX or JMXTOOLS class but it didn't
>> works. Some working example are welcomed.
>>
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
>> For
>> additional commands,
>> e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>
>>
>>
> 
> --
> To unsubscribe, e-mail:  
> <mailto:tomcat-dev-unsubscribe@jakarta.apache.org> For additional
> commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>

-- 
Costin



--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message