tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: [POLL] Tomcat 3.3.2 updates
Date Wed, 25 Sep 2002 06:18:42 GMT
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.

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>



--
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