Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <3EA5AEA3.5020404@apache.org>
Date: Tue, 22 Apr 2003 14:05:39 -0700
From: Amy Roh <amyroh@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.0.2) Gecko/20030208 Netscape/7.02
MIME-Version: 1.0
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
Subject: Re: [5.0.2] New tag at the end of the week ?
References: <20030422014556.36981.qmail@web9403.mail.yahoo.com>
 <3EA4D6D2.9050302@apache.org> <b82mjg$1vc$1@main.gmane.org>
 <3EA58FA6.6090306@apache.org> <b845gs$9uo$1@main.gmane.org>
 <3EA59FD6.2000904@sun.com> <b847tm$mkq$1@main.gmane.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


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

This is not an issue.  The issue is that we need WebModules and Servlets 
to be in the same domain as the J2EEServer.

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

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

What do you think?
Amy

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