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 05:06:15 GMT
Amy Roh wrote:

>> 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.
> Where does it say that?  J2EEManagedObject objectName has syntax of
> [domainName]:j2eeType=value,name=value,<parent-j2eeType>[,property=value]
> says the key property list must contain at least the
> mandatory key properties but doesn't limit to only mandatory.  It says
> "it may contain any number of optional key properties whose order is not
> significant".  I think you can add "engineName" attribute.

I missed that part. Well, it seems there are few other things
that are missing in the jsr77 impl.

So the question remain if we want to add the "engine=XXX" to all mbeans,
and the code to use the engine name when refering to other components.

>> 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.
> I agree it adds complexity in the common case (single engine) to support
> uncommon cases(multiple engines).  If we decide not to support multiple
> engines, that's fine.  I just wish you voiced your opinion when I first
> raised the issue before I made the changes.  :-(

Really sorry - I missunderstood the proposal, my assumption was that you
would add support for multiple engines in /admin - and use the engine name
( which was equal with the domain ). I didn't know you need to add a name
and move all engines in the same domain.

The issue is not if we support multiple engines - we should support them in
both cases. I see no reasons not to. 

The only question is how - by changing the naming of the components to
include the name of the engine, and having multiple tomcat engines in the
same domain or by just having each engine in its own domain.

For "multi engine" use case - I'm very interested in /admin managing
multiple Engines, but some of them beeing proxys for remote VMs ( i.e.
managing a cluster ). And in this case having one domain per Engine is 
again simpler.

> But I still think it's not *too* complicated to add "name" and query
> "engineName" from webmodules though.  ;-)

It's not too complicated. However it requires a bit more work - the embeded
case had a lot of NPEs, and all components will have to have this extra 

Plus it breaks a very elegant model, where each servlet engine had it's own

I'm +1 on multiple servlet engines - but I preffer the 1 engine- 1 domain, 
and we can fix the jsr77 domain problem separately.

BTW, in my experience so far having one JMX domain with too many components 
can be quite confusing and is harder to use ( with the jmx console ) - so it
may be even better if we register the WebModules/Servlets in the jsr77
domain ( where they are required ), and keep the other tomcat components in
their own domain. 


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

View raw message