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 22:45:00 GMT

Costin Manolache wrote:
> Amy Roh wrote:
>>>For the first part - it works both ways. If you use 1 Engine/domain -
>>>then you'll also have each connector in the same domain with the
>>>corresponding engine. I see no problem here.
>>This is not an issue.  The issue is that we need WebModules and Servlets
>>to be in the same domain as the J2EEServer.
> Ok. Let's fix that then, and let the Engine in its own domain.

I'm not sure what you mean.  Are you agreeing to have engine name *and* 
domain name and allow for them to be different?  ;-)

>>>The second part is a bit trickier ( and it seems a valid use case ... ).
>>>You want the WebModules and Servlets to be in the same domain. I think
>>>this can be done with some changes in WebModules and Servlets.
>>>Let me ask you one question first: would it be ok if we use the
>>>j2eeServer to match the engine name ( and it's domain ) ?
>>No.  J2EEServer and J2EEApplication names should be set as part of
>>integration as you mentioned and should be out of Tomcat scope.  This
>>will only restrict more on top of domain name having to be the same as
>>engine name.
> So if I create a Context, give it an ObjectName - how do I figure out what 
> Engine ( and Connector ) should it be mapped to ? 
> The only solution I can think of is to have a "engineName" attribute on the
> context. 

I think WebModule mbeans should have "parentName" attribute to store its 
parent engine objectname so that it knows which engine it belongs to and 
so forth.

>>>You see - the real problem is that the JSR77 name is fixed - you have
>>>webapp name, j2eeApplication ( that's the .ear - and it's part of the
>>>integration code with j2ee server to set it right ), and j2eeServer.
>>>Nothing else. My understanding was that all webapps will be in the same
>>>j2eeServer, and this would be set by the integration code.
>>>The webapp mbean needs to find the engine - at least in embeded case.
>>>Right now all it needs is in its own name. And I assume other pieces of
>>>code could benefit from beeing able to tell what engine a webapp is
>>>associated with - looking at the name.
>>>We could just use an attribute in StandardContext and StandardWrapper to
>>>override the domain - in case using the j2eeServer attribute is not
>>>But that would break if you have 2 webapps with the same name, inside
>>>identical EARs running on 2 different connectors - the generated name
>>>will be completely identical. I assume different connectors correspond to
>>>different vhosts - and if this is the case, I think it's reasonable to
>>>expect to be able to deply the same .ear on 2 vhosts.
>>>Could you point to the JSR77 section where the mbeans are required to be
>>>in the same domain ? My understanding so far has been that the domain is
>>>not specified, and implementations can use it, for example to deal with
>>>this case, of multiple servlet engine instances running in the same
>>>j2eeServer, with the same context name and j2eeApplication.
>>If you look at JSR77.3.2, J2EEServer extends J2EEDomain.
>>J2EEModule(WebModule) and J2EEApplication extend J2EEDeployedObject
>>which extends J2EEServer.  Therefore, all WebModules that are deployed
>>under J2EEServer should be in the same J2EEDomain.  When TC is
>>integrated in AppServer, if multiple engines are created, there isn't a
>>way for the WebModules to be under same domain.  They'll get deployed
>>under engine name domain not the J2EEServer, J2EEDomain from the
>>integration which is not JSR77 compliant.
> 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?

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

> The thing I miss is the relation between multiple engines ( and connectors )
> and ears. The context name is based on .ear name, server name, and context
> name. How do you associate this with an engine ?
>>What do you think?
> 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?


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

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

View raw message