tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amy Roh <amy...@apache.org>
Subject Re: [5.0.2] New tag at the end of the week ?
Date Wed, 23 Apr 2003 01:06:48 GMT


Costin Manolache wrote:
> 
> 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.

Where does it say that?  J2EEManagedObject objectName has syntax of
[domainName]:j2eeType=value,name=value,<parent-j2eeType>[,property=value]
77.3.1.1.2 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.

> 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.

I don't think other hacks are needed.  See above.

> 
> 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.

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.  :-(  

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

>
> 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 )
> 
> Costin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message