You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Amy Roh <am...@apache.org> on 2003/04/02 08:54:55 UTC
disable jmx option in tc5
Just out of curiosity, is there a simple way to disable jmx in tc5 other
than changing tomcat code to avoid registration/unregistration manually
which won't be trivial.
Thanks,
Amy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: disable jmx option in tc5
Posted by Remy Maucherat <re...@apache.org>.
Amy Roh wrote:
> Just out of curiosity, is there a simple way to disable jmx in tc5 other
> than changing tomcat code to avoid registration/unregistration manually
> which won't be trivial.
It had been decided that Tomcat 5 would require JMX, so it is not
possible to disable it.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: disable jmx option in tc5
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>> Hmmm. We could use the "jsr77" option ( that is now in 4.1.x ) and
>> generate JSR77 names only if it is on.
>>
>> Or we could just use the other kind of names allways - and have a
>> separate module that re-register the objects with JSR77 names ( if needed
>> ).
>>
>> But the real issue is that a product shouldn't "handle JSR77 for
>> webmodules", that's plain wrong. The mbeans for WebModule and Servlet
>> must be handled by tomcat - who is the one that knows when a servlet
>> or webmodule is instantiated or removed or changes state, and can
>> provide usefull info ( statistics, etc ).
>
> I completely agree, but the webmodule users don't agree, apparently. For
> example, the core JBoss folks insist that JBoss should be the one doing
> that JSR 77 stuff, for some reason, and that the web container should
> provide methods to access the stats (we do, so it's ok, I guess).
That's plain stupid IMO.
Tomcat implements the servlet and webmodule - so most likely knows better
what's manageable inside and how to manage. Well - they'll probably loose
some features and dumb down the management of servlets and webmodules.
Not sure what you mean by "webmodule user" - I assume you're talking about
the JSR77 implementors. I can't see how a webmodule user would want the
webmodule managed by a third party entity instead of the servlet container.
>> A product that creates some wrappers or dummy objects with JSR77 names
>> is useless - they'll have no real management value, since you would
>> manage the wrong components.
>>
>> The EJB container should handle the JSR77 components that are related
>> with EJBs, and tomcat ( or whatever servlet implementation ) should
>> handle the JSR77 for its components.
>>
>> ( jboss seems to be one case where jsr77 is implemented outside of the
>> servlet container ).
>
> Indeed, and there's no change on the horizon.
That means we'll probably have to have a flag to disable jsr77.
It'll be ugly - since tomcat itself relies on the WebModule and Servlet to
be manageable and expose a number of attributes and control.
Not sure how this will work - we basically need to be able to deal with dumb
WebModules wrappers and be able to located the real component somehow.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: disable jmx option in tc5
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Hmmm. We could use the "jsr77" option ( that is now in 4.1.x ) and generate
> JSR77 names only if it is on.
>
> Or we could just use the other kind of names allways - and have a separate
> module that re-register the objects with JSR77 names ( if needed ).
>
> But the real issue is that a product shouldn't "handle JSR77 for
> webmodules", that's plain wrong. The mbeans for WebModule and Servlet
> must be handled by tomcat - who is the one that knows when a servlet
> or webmodule is instantiated or removed or changes state, and can provide
> usefull info ( statistics, etc ).
I completely agree, but the webmodule users don't agree, apparently. For
example, the core JBoss folks insist that JBoss should be the one doing
that JSR 77 stuff, for some reason, and that the web container should
provide methods to access the stats (we do, so it's ok, I guess).
> A product that creates some wrappers or dummy objects with JSR77 names
> is useless - they'll have no real management value, since you would manage
> the wrong components.
>
> The EJB container should handle the JSR77 components that are related with
> EJBs, and tomcat ( or whatever servlet implementation ) should handle the
> JSR77 for its components.
>
> ( jboss seems to be one case where jsr77 is implemented outside of the
> servlet container ).
Indeed, and there's no change on the horizon.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: disable jmx option in tc5
Posted by Amy Roh <am...@apache.org>.
Costin Manolache wrote:
> Amy Roh wrote:
>
>
>>>>Just out of curiosity, is there a simple way to disable jmx in tc5 other
>>>>than changing tomcat code to avoid registration/unregistration manually
>>>>which won't be trivial.
>>>
>>>
>>>Just out of curiosity, why would you want to do this ?
>>
>>I don't. I was just thinking of different options to integrate tomcat
>>into a product that already handles jsr77 code for webmodules. just
>>brain storming...
>
>
> Hmmm. We could use the "jsr77" option ( that is now in 4.1.x ) and generate
> JSR77 names only if it is on.
>
> Or we could just use the other kind of names allways - and have a separate
> module that re-register the objects with JSR77 names ( if needed ).
>
> But the real issue is that a product shouldn't "handle JSR77 for
> webmodules", that's plain wrong. The mbeans for WebModule and Servlet
> must be handled by tomcat - who is the one that knows when a servlet
> or webmodule is instantiated or removed or changes state, and can provide
> usefull info ( statistics, etc ).
Yeah, I've already thought about the alternative. It's not very pretty.
There can be lots of coordination problems. and it's missing the point.
BTW, how about that servlet unavilable error? Were you able to figure
out what's the problem? Didn't see any commits on that.
>
> A product that creates some wrappers or dummy objects with JSR77 names
> is useless - they'll have no real management value, since you would manage
> the wrong components.
>
> The EJB container should handle the JSR77 components that are related with
> EJBs, and tomcat ( or whatever servlet implementation ) should handle the
> JSR77 for its components.
>
> ( jboss seems to be one case where jsr77 is implemented outside of the
> servlet container ).
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: disable jmx option in tc5
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
>>>Just out of curiosity, is there a simple way to disable jmx in tc5 other
>>>than changing tomcat code to avoid registration/unregistration manually
>>>which won't be trivial.
>>
>>
>> Just out of curiosity, why would you want to do this ?
>
> I don't. I was just thinking of different options to integrate tomcat
> into a product that already handles jsr77 code for webmodules. just
> brain storming...
Hmmm. We could use the "jsr77" option ( that is now in 4.1.x ) and generate
JSR77 names only if it is on.
Or we could just use the other kind of names allways - and have a separate
module that re-register the objects with JSR77 names ( if needed ).
But the real issue is that a product shouldn't "handle JSR77 for
webmodules", that's plain wrong. The mbeans for WebModule and Servlet
must be handled by tomcat - who is the one that knows when a servlet
or webmodule is instantiated or removed or changes state, and can provide
usefull info ( statistics, etc ).
A product that creates some wrappers or dummy objects with JSR77 names
is useless - they'll have no real management value, since you would manage
the wrong components.
The EJB container should handle the JSR77 components that are related with
EJBs, and tomcat ( or whatever servlet implementation ) should handle the
JSR77 for its components.
( jboss seems to be one case where jsr77 is implemented outside of the
servlet container ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: disable jmx option in tc5
Posted by Amy Roh <am...@apache.org>.
Costin Manolache wrote:
> Amy Roh wrote:
>
>
>>Just out of curiosity, is there a simple way to disable jmx in tc5 other
>>than changing tomcat code to avoid registration/unregistration manually
>>which won't be trivial.
>
>
> Just out of curiosity, why would you want to do this ?
I don't. I was just thinking of different options to integrate tomcat
into a product that already handles jsr77 code for webmodules. just
brain storming...
>
> The whole point of using ( and requiring ) JMX is to simplify the
> model. I know that right now it doesn't look simpler, especially since
> some pieces are broken - but things are getting consistent and at least
> in my opinion they'll be much simpler in the end.
I couldn't agree more.
Thanks,
Amy
> A lot of the complexity in the current JMX stuff is related with the
> 2 config models - we need to support server.xml and direct API calls for
> backward compat.
>
> Costin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: disable jmx option in tc5
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
> Just out of curiosity, is there a simple way to disable jmx in tc5 other
> than changing tomcat code to avoid registration/unregistration manually
> which won't be trivial.
Just out of curiosity, why would you want to do this ?
The whole point of using ( and requiring ) JMX is to simplify the
model. I know that right now it doesn't look simpler, especially since
some pieces are broken - but things are getting consistent and at least
in my opinion they'll be much simpler in the end.
A lot of the complexity in the current JMX stuff is related with the
2 config models - we need to support server.xml and direct API calls for
backward compat.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org