tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amy Roh" <>
Subject Re: [5.0.2] New tag at the end of the week ?
Date Wed, 23 Apr 2003 16:50:56 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
> >
> > 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.

Do we have to add "engineName" to *all* mbeans?

How about we add an option to set "J2EEDomain" for WebModule and Servlet?
So when J2EEDomain for those components aren't null, we can register the
mbeans under J2EEDomain as well as tomcat domain.  At the time of
registration we can save tomcatDomain name as "engineName" for those J2EE
mbeans.  In Tomcat, we can just look at "engineName" for WebModule and
Servlet mbeans to do JMX operations if they're set to something.  If not, we
can assume its domain is the same as tomcat domain.  This way we won't have
to change other components (keep one engine per domain) and should work both
in Tomcat and J2EE world?  I'll check with jsr77 to see if registering in
both domains are ok and if there're better ways to handle this.


> >> I'm very much against multiple engines per domain because of the same
> >> reason - it adds complexity :-) The problem is that it adds complexity
> >> the common case ( one Engine per domain - most people don't have
> >> 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
> 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
> case had a lot of NPEs, and all components will have to have this extra
> overhead.
> Plus it breaks a very elegant model, where each servlet engine had it's
> space.
> 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
> can be quite confusing and is harder to use ( with the jmx console ) - so
> may be even better if we register the WebModules/Servlets in the jsr77
> domain ( where they are required ), and keep the other tomcat components
> their own domain.
> Costin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message