Remy Maucherat wrote: > Costin Manolache wrote: >> Hmmm. We could use the "jsr77" option ( that is now in 4.1.x ) and >> generate JSR77 names only if it is on. >> >> Or we could just use the other kind of names allways - and have a >> separate module that re-register the objects with JSR77 names ( if needed >> ). >> >> But the real issue is that a product shouldn't "handle JSR77 for >> webmodules", that's plain wrong. The mbeans for WebModule and Servlet >> must be handled by tomcat - who is the one that knows when a servlet >> or webmodule is instantiated or removed or changes state, and can >> provide usefull info ( statistics, etc ). > > I completely agree, but the webmodule users don't agree, apparently. For > example, the core JBoss folks insist that JBoss should be the one doing > that JSR 77 stuff, for some reason, and that the web container should > provide methods to access the stats (we do, so it's ok, I guess).
That's plain stupid IMO. Tomcat implements the servlet and webmodule - so most likely knows better what's manageable inside and how to manage. Well - they'll probably loose some features and dumb down the management of servlets and webmodules. Not sure what you mean by "webmodule user" - I assume you're talking about the JSR77 implementors. I can't see how a webmodule user would want the webmodule managed by a third party entity instead of the servlet container. >> A product that creates some wrappers or dummy objects with JSR77 names >> is useless - they'll have no real management value, since you would >> manage the wrong components. >> >> The EJB container should handle the JSR77 components that are related >> with EJBs, and tomcat ( or whatever servlet implementation ) should >> handle the JSR77 for its components. >> >> ( jboss seems to be one case where jsr77 is implemented outside of the >> servlet container ). > > Indeed, and there's no change on the horizon. That means we'll probably have to have a flag to disable jsr77. It'll be ugly - since tomcat itself relies on the WebModule and Servlet to be manageable and expose a number of attributes and control. Not sure how this will work - we basically need to be able to deal with dumb WebModules wrappers and be able to located the real component somehow. Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
