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 20:16:12 GMT
Amy Roh wrote:

>> If you have a use case where this would actually help - we should discuss
>> it and do the change ASAP ( but on all components- I really don't see any
>> way embed can work otherwise ).
> Here is my use case and background info.  I need to create multiple
> engines (one engine per connector) because in TC we support defaultHost
> in engine level.  However, AppServer that I'm working on supports one
> defaultHost per listener(connector).  This forces me to create one
> engine per listener which results in having as many engines as listeners
> to map AppServer domain.xml and TC server.xml.  AppServer has its JSR77
> mbeans for domain, server, applications, ejbmodules, etc.  We want to
> use Tomcat MBeans for WebModules & Servlets sharing one default domain.
>   Not allowing multiple engines per domain means that the deployed
> WebModules will have different domains which doesn't follow JSR77.
> Maybe you have a better idea/suggestion to resolve this issue if we
> don't allow multiple engines per domain.

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.

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

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.


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

View raw message