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 22:18:16 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.
> It seems my undersanding of JSR77 was completely off...
> I assumed that 77.3.2 and the servers[] reffer more to a cluster-like 
> setup, not to have multiple J2EE server in the same VM. 
> And the fact that all navigation is in terms of ObjectName[] missled me
> to think that you can have any object name - this is the first I hear the 
> restriction that _all_ names need to be in the same domain.

I don't know about having _all_ names in the same domain.  However, 
webmodules and servlets should be under the same domain as the 
J2EEServer who's responsible for its deployment.

> If this is the case - the only option is to treat tomcat as a separate
> entity, in a separate domain from the webapps.
> We have 3 options:
> - Webapps registered once, in the jsr77Domain. Tomcat will listen for events
> and register them, but nothing else ( i.e. no contexts in the tomcat
> domain)

+1.  We can keep context mbeans under tomcat domain in tomcat standalone 
case - keep it the way it is?

> - webapps registered twice, once in tomcat domain and once in the JSR77
> domain. That can use either the same (local) name, or we can use the name
> in tomcat4.1 ( but what would admin use ? IMO it should be the standard
> names ).
> - webapps registered once, in tomcat domain - and wrappers registered in 
> the jsr77Domain.
>>>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.  :-)
> I don't see any need. 
> The do need to know the domain of the engine - but you can configure this 
> as an attribute. The only need is to construct the engine name - so it can
> invoke the addContext() callback.
>>>>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?
> There is no reason to have the webapps and the engine in the same domain. It
> may be even cleaner if they are in separate domains.
> There is no reason to even have the connector in the same domain with the
> engine. 
> All we need is that each component is able to find the other components it
> needs. That can be done by constructing it's name using the same domain,
> but it is easy to override it.
> Sorry - I allways was under the impression that JSR77 doesn't require that
> all components are in the same domain, and you can just navigate from root
> to any component using the ObjectNames.
> Costin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message