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

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

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

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.

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.


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

View raw message