Community
Participate
Working Groups
Build Identifier: All I have thirteen web applications deployed in one JVM. When I connect with the JConsole and browse to org.eclipse.jetty.server.session I find that the hashsessionmanager and sessionhandler instances are named with a number such that I can't see which one is for which context. When I register my own mbeans I register them using the context of the application they are deployed in. Reproducible: Always
Created attachment 185501 [details] JConsole screenshot
This can be done by adding real MBean instances for these mbeans. But we don't want to create too many real MBeans for too many objects. Essentially this is a deficiency of jconsole, as earlier versions were able to link through the ObjenctName links from other mbeans
We will look into improving the names allocated to core mbeans
Went through the Code of MBeanContainer.java and ObjectMBean.java and debugged adding MBeans a bit. There's no (easy) way to identify the webapp context the object is running in. Greg, where do you want to have the context information? Prefix the mbean name?
In order to implement this enhancement we are going to introduce an additional property named 'context' into the ObjectName of instances of Handler, Holder, and Mapping classes that are subordinate to a ContextHandler. This will allow us to provide requested context information without creating any confusion about the purpose of each of the properties. It is going to be implemented by adding context basis member to the base classes of the above mentioned classes, as well as adding appropriate ObjectMBean subclasses for each of the above base classes to propagate the context basis and name basis (if appropriate, e.g. for a Holder instance) to be included into the ObjectName of the corresponding MBean. Context basis of the subordinate instances will be set to the enclosing context's basis when they are added to the context.
Adding SessionManager to the list of affected classes.
Committed r3101.
This has broken the build as it uses non 1.5 methods
Also I'm not keen on the whole contextBasis plumbing through the handlers. It is difficult enough to wire up handlers with servers and scopes etc. without extra complexity. I really prefer JMX concerns to not affect the design of the base beans at all - stuff like this should really be put only in MBean classes. Let me review the mechanism and come up with some recommendations of a better way.
I've backed this change out for now, mostly because we cannot change the Handler API in a dot release. Still working on a recommendation for an alternative
I think that this change can (must) be done with out any significant changes to the core jetty classes. The Handler API certainly cannot be changed. While the Mapping interface and AbstractMapping class might be justifiable for other reasons, I also think that we have to do without. So for the session manager mbean, we need to find the enclosing context from the mbean class to set the name. You can navigate from the session manager to the session handler and from there get the server. I will add a method on the Abstract Handlers to help search the hierarchy for parent handlers.
I've added AbstractHandlerContainer.findContainerOf which is a static method that helps you search for the parent of a handler. Ie you can use it to the context handler for a given session handler.
Changed the implementation to do most of the work inside MBean classes. Committed r3120.
Resolved -> Closed
