tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amy Roh <>
Subject Re: TC5 JMX domain engine issue
Date Wed, 23 Apr 2003 21:23:53 GMT
Costin Manolache wrote:
> Amy Roh wrote:
>>>>Personally, here's what I would like:
>>>>- 1 engine <-> 1 domain <-> 1 service
>>>That provides the cleanest solution for tomcat, and I don't think it
>>>hurts anything. We can still have as many engines as we want in the VM.
>>The problem is that this doesn't follow jsr77.  You should be able to
>>have more than one server(engine) under one domain (see jsr77.3.2).  If
>>we treat engine's name as domain and not allow multiple engines under
>>one domain we're skipping one level (j2eeserver) and problems occur.
> Can you have more than one J2EE server under one domain ? 

Yes - JSR77.3.2.1.

> Is there anything in the J2EE spec that requires a J2EE server to support
> more than one Servlet Engine ? 

Not sure.

> Please keep in mind that tomcat itself ( the Engine, connectors, etc ) are
> _not_ constrainted by JSR77. Only the WebModule and Servlet are defined in
> 77. 


>>>>- An option to configure in which domain the JSR 77 beans go (the other
>>>>parts of the appserver must have their stuff in the same domain I assume)
>>>I'm leaning toward this option as well. I agree with Amy, registering
>>>them in both tomcat and j2ee domain is hacky.
>>Yeah, I don't think this is a good elegant long term solution.  We don't
>>want to have two mbeans registered in two different domains.  When a
>>user browses through WebModule & Servlet jsr77 mbeans, you'll see two
>>registered in j2eedomain and tomcat each.  Hacky.
> There is no need to register them twice. The mapper receives notifications
> for all domains. 


> You can register WebModules in any domain - all we need is an attribute (
> not even part of the name ) that tells wich engine it needs to be
> registered in. 

I was under impression that WebModules have to be in the same domain as 
engine in order for everything to work.  If all we need is engineName, 
then we won't have to register them twice.  :-)

>>>Multiple Engines are not a bad thing, quite the contrary. But
>>>they should be used in a clean way. JMX domains are a good way to
>>>organize the info.
>>I agree we should decide to use a clean way that follows the spec to
>>achieve this goal.
> +1 - if tomcat is to support JSR77 ( for contexts/servlets ), it needs to
> be able to place them in the j2eeServer domain, and if multiple engines are
> used each must use the same domain for webmodules ( as long as they are
> part of the same j2eeServer ).

I don't see how this can be achieved if we don't allow multiple engines 
per domain.  You're saying "if multiple engines are used, each must use 
the same domain for webmodules."  But we don't allow multiple engines to 
share the same domain as for webmodules that are placed in the 
j2eeServer domain.  Doesn't it make sense to put the engines under the 
same j2eeDomain in order for it to work?

> That doesn't impose any restrictions on the domain for tomcat.
> We could as well use one domain for the Engine, Mapper and all
> servlet-implementation components, and a separate domain for the connector. 
> ( for a use case of having one connector used for multiple engines for
> example. 
> Placing too many components in the same domain results in a mess. It may be
> much better to not place non-JSR77 components ( like Engine or Connector )
> in the jsr77 domain.
> The only issue is that the components registered in jsr77 for WebModule 
> should be either StandardContext or a proxy/wrapper that exposes the info
> and operations in StandardContext. Maybe with some changes ( for Statistics
> for example ).
> Costin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message