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 Tue, 22 Apr 2003 23:30:18 GMT

> 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 not very difficult to fix the creation of WebModule - to move it
>>>under the same domain.
>>When context is created, it inherits its domain name from its parent
>>engine.  If we don't allow multiple engines in one domain, how can we
>>move it under the same domain?
> 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?

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.

> In the end - all WebModules will be in the same domain. In the first case
> they'll also be registered in the tomcat domain. In the second case - some
> code will be slightly more complex.
>>>The problem is how to figure out what Engine a WebModule belongs to, if
>>>you use JMX ( and embed ) to create it.
>>>Attribute is the only solution I can find - and that restricts engines
>>>from registering 2 webmodules with the same name.
>>We *should* restrict registering 2 webmodules with the same name, no?
> You mean don't allow /examples to be available on 2 Engines ? 
> I assume the connectors are virtual hosts - and I don't think we can
> restrict vhosts this way. But I assume the j2eeApplication will be
> different..
>>>You have a point with the J2EEDomain. IMO the solution is to fix the
>>>WebModule and Servlet registration. If we find how to associate them back
>>>to the Engine - it shouldn't be hard to implement.
>>with "parentName" (engineName) attribute?  So all we have to change is
>>in WebModule and Servlet to include its parent objectName, right?
> The second solution. Yes, that works for me.
> Other opinions ? Remy ? 
> Costin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message