tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [5.0.2] New tag at the end of the week ?
Date Wed, 23 Apr 2003 00:14:22 GMT
Amy Roh wrote:

>> No, I think we should keep one engine per domain ( i.e. no name ), but
>> fix the WebModule and Servlet - so you can keep them all in one domain (
>> different than tomcat ).
>> Actually - there is another option, to just register the WebModule and
>> Servlet in both domains. Still few changes are required - but that would
>> be the easiest solution.
> When you say both domains, you mean its engine's domain and also
> J2EEDomain?  Sounds ugly.

It's a matter of taste :-)

Using multiple Engines is what creates the problem in the first place. 
We need one engine per domain to keep things simple ( and not ugly ). 
IMO the "normal" case is to have the engine and the j2eeServer in the same
domain - and have one servlet engine per j2eeServer. 

I don't know what the j2ee specs are saying - but having multiple servlet
engines in a single j2ee server is going to create a lot of pain (
configuration - where do you deploy the apps, etc ). 

>> There are 2 ways:
>> 1. ( easy ) add an attribute to WebModule ( say "j2eeDomain" ), when the
>> context is started it'll register itself in the j2eeDomain ( and it'll
>> remain registered in the tomcat domain as well ). There are some fixes to
>> deal with preRegister/preUnregister.
>> 2. Add an attribute to WebModule ( "engineName" ). Then change the code
>> in WebModule to use engineName as a domain when constructing the Host or
>> Engine names. I think that would require more changes.
> Too complex.  Admin will have to be completely rewriten in that part if
> we have to construct Host & Engine using "engineName" domain.

> I still don't understand why we can't add "name" attribute to
> type=Engine mbeans so that we can have multiple engines under one domain
> following jsr 77.  If figuring out which engine each webmodule belongs
> to is the problem, it can be fixed by just adding "engineName" attribute
> to webmodule & servlet mbeans.  But you won't have to register in two
> different domains to do so.  What am I missing here?

No, you can't change the object name of Servlet and WebModule. It is defined
in JSR77, and we're stuck with the attributes there. Can't "extend" the
standard by adding more to the names.

The whole point of using JMX in tomcat is to be able to manage it using 
JMX ( instead of internal APIs ). You want to add/remove a connector to 
tomcat - just create the Connector mbean, set the attributes, and call
init/start. You add a new webapp ? Create mbean, set attributes, call 
init/start. All this can happen at almost any time and in almost any order,
you don't need to restart the server.

In order for this to work - we need to play with the object names. 
JMX is a component registry - you can find and configure and operate on any
component using its name. 

In all cases, components that are created need to find the engine. With 1
Engine per domain - it's very simple- use the domain the component was
registered with, add ":type=Engine". 

If you add name to engine, _all_ components that need the engine will have 
to have an extra attribute as well, and use it to locate the engine. For
WebModule and Servlet - we can't add attributes, so other hacks are needed.

But the fundamental issue is that Engine corresponds to a servlet engine,
with all the settings and components. Mixing 2 serlvet engines in the same
domain is ugly - you don't do it for the J2EEServer I assume ( jsr77
actually requires you to have a single j2ee server per domain )

Is there any J2EE spec that sugests that a j2ee server should support
multiple servlet engines ?

> If we're not allowing to register multiple engines per domain by adding
> "name" attribute, I think all this just adds complexity.  I can just add
> the code in the J2EE product to create its mbeans for webmodule and
> ignore mbeans in tomcat domain.  We won't have to worry about
> registering both in J2EEDomain and tomcat in tomcat itself.

Then you loose the timing and other info. 
That's one option ( you could just wrap the tomcat mbeans - a dynamic mbean
or modeler could probably allow you to keep the tomcat attributes exposed ).

I'm very much against multiple engines per domain because of the same reason
- it adds complexity :-) The problem is that it adds complexity in the 
common case ( one Engine per domain - most people don't have multiple
servlet engines running in the same VM ), in order to support a very 
hacky use case.

Let's wait until Remy ( and other French people ) wakes up and maybe get
some other opinions. I have no problems with making changes to the names -
but if we add engine name, all components must add it and we need an answer
on what to do about WebModule ( where we can't add keys to the name )


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

View raw message