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: <3EA6FCF8.6080200@apache.org>
Date: Wed, 23 Apr 2003 13:52:08 -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>
CC: Hans Hrasna <Hans.Hrasna@sun.com>
Subject: Re: TC5 JMX domain engine issue
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>
 <3EA5AEA3.5020404@apache.org> <b84fbm$rhs$1@main.gmane.org>
 <3EA5C5EC.4040201@apache.org> <b84h7n$47r$1@main.gmane.org>
 <3EA5D08A.9090602@apache.org> <b84ls6$m1d$1@main.gmane.org>
 <3EA5E728.540A05C2@apache.org> <b85al9$qa4$1@main.gmane.org>
 <000901c309b8$8c171020$8f1cea0c@apache.org> <b86som$5i6$1@main.gmane.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Costin Manolache wrote:
> Amy - one more question. 
> 
> What if we just move back to not support JSR77 directly in tomcat ?

Yeah, this is an option.  Remember I asked a while ago about turning off 
jmx in TC5.  That was due to the same reason.  Tomcat supports JSR77 
partially.  It might be better for j2ee container to use tomcat mbeans 
to do jsr77 stuff.

> 
> I was reading jsr77 again - and it may be a better idea to just use 
> type=Context, etc - internal tomcat names, etc.
> 
> Then a j2ee container could just wrap those objects. The problem is that
> if we want to support the statistics ( and we do have a lot of metrics
> already ), JSR77 requires us to depend on javax.management.j2ee.statistics 
> and present them in a certain way. Nothing wrong with that - but we can
> have an easier life if we leave this for the people who integrate tomcat
> in a j2ee server.
> 
> The reason I tought we should implement jsr77 in tomcat was the fact that we
> do have all the information already, and it would be easier for us to just 
> use the standard names ( even if 1/2 of it is not used - j2eeApp and
> server). And it seemed logical that the StandardContext object, which is
> the tomcat implementation of a WebApplication, is registered as a jsr77,
> without another intermediary. 
> 
> Decoupling them - I think you already suggested that - would probably loose
> some info and control, at least in a simple implementation. But it can be
> done via a dynamic or model mbean that proxies all the methods and
> attributes in StandardContext, and adds the extra JSR77 specific stuff (i.e
> statistics, etc ).

I'd like to hear Han's comment on this.  This means the admin webapp 
needs to be rewritten *again!* to accommodate the new objectnames.  :-( 
I'm open to what's the best.

Thanks Costin!
Amy

> 
> Would that be a better solution for you ?  
> 
> 
> Costin
> 
> 
> 
> Amy Roh wrote:
> 
> 
>>>Amy Roh wrote:
>>>
>>>
>>>>>No, you can't change the object name of Servlet and WebModule. It is
>>>>>defined in JSR77, and we're stuck with the attributes there. Can't
>>>>>"extend" the standard by adding more to the names.
>>>>
>>>>Where does it say that?  J2EEManagedObject objectName has syntax of
>>>>
>>>
>>[domainName]:j2eeType=value,name=value,<parent-j2eeType>[,property=value]
>>
>>>>77.3.1.1.2 says the key property list must contain at least the
>>>>mandatory key properties but doesn't limit to only mandatory.  It says
>>>>"it may contain any number of optional key properties whose order is
>>>>not
>>>>significant".  I think you can add "engineName" attribute.
>>>
>>>I missed that part. Well, it seems there are few other things
>>>that are missing in the jsr77 impl.
>>>
>>>So the question remain if we want to add the "engine=XXX" to all mbeans,
>>>and the code to use the engine name when refering to other components.
>>
>>Do we have to add "engineName" to *all* mbeans?
>>
>>How about we add an option to set "J2EEDomain" for WebModule and Servlet?
>>So when J2EEDomain for those components aren't null, we can register the
>>mbeans under J2EEDomain as well as tomcat domain.  At the time of
>>registration we can save tomcatDomain name as "engineName" for those J2EE
>>mbeans.  In Tomcat, we can just look at "engineName" for WebModule and
>>Servlet mbeans to do JMX operations if they're set to something.  If not,
>>we
>>can assume its domain is the same as tomcat domain.  This way we won't
>>have to change other components (keep one engine per domain) and should
>>work both
>>in Tomcat and J2EE world?  I'll check with jsr77 to see if registering in
>>both domains are ok and if there're better ways to handle this.
>>
>>Thanks,
>>Amy
>>
>>
>>>>>I'm very much against multiple engines per domain because of the same
>>>>>reason - it adds complexity :-) The problem is that it adds complexity
>>>>
>>in
>>
>>>>>the common case ( one Engine per domain - most people don't have
>>>>
>>multiple
>>
>>>>>servlet engines running in the same VM ), in order to support a very
>>>>>hacky use case.
>>>>
>>>>I agree it adds complexity in the common case (single engine) to
>>>>support
>>>>uncommon cases(multiple engines).  If we decide not to support multiple
>>>>engines, that's fine.  I just wish you voiced your opinion when I first
>>>>raised the issue before I made the changes.  :-(
>>>
>>>
>>>Really sorry - I missunderstood the proposal, my assumption was that you
>>>would add support for multiple engines in /admin - and use the engine
>>>name ( which was equal with the domain ). I didn't know you need to add a
>>>name and move all engines in the same domain.
>>>
>>>The issue is not if we support multiple engines - we should support them
>>
>>in
>>
>>>both cases. I see no reasons not to.
>>>
>>>The only question is how - by changing the naming of the components to
>>>include the name of the engine, and having multiple tomcat engines in the
>>>same domain or by just having each engine in its own domain.
>>>
>>>For "multi engine" use case - I'm very interested in /admin managing
>>>multiple Engines, but some of them beeing proxys for remote VMs ( i.e.
>>>managing a cluster ). And in this case having one domain per Engine is
>>>again simpler.
>>>
>>>
>>>
>>>
>>>>But I still think it's not *too* complicated to add "name" and query
>>>>"engineName" from webmodules though.  ;-)
>>>
>>>It's not too complicated. However it requires a bit more work - the
>>
>>embeded
>>
>>>case had a lot of NPEs, and all components will have to have this extra
>>>overhead.
>>>
>>>Plus it breaks a very elegant model, where each servlet engine had it's
>>
>>own
>>
>>>space.
>>>
>>>I'm +1 on multiple servlet engines - but I preffer the 1 engine- 1
>>>domain, and we can fix the jsr77 domain problem separately.
>>>
>>>BTW, in my experience so far having one JMX domain with too many
>>
>>components
>>
>>>can be quite confusing and is harder to use ( with the jmx console ) - so
>>
>>it
>>
>>>may be even better if we register the WebModules/Servlets in the jsr77
>>>domain ( where they are required ), and keep the other tomcat components
>>
>>in
>>
>>>their own domain.
>>>
>>>
>>>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
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org