search

jetty / jetty.project

Eclipse Jetty® - Web Container & Clients - supports HTTP/2, HTTP/1.1, HTTP/1.0, websocket, servlets, and more
https://eclipse.dev/jetty
Other
3.87k stars 1.91k forks source link

JMX-ify children of unmanaged beans #5818

Open sbordet opened 3 years ago

sbordet commented 3 years ago

Jetty version 9.4.x

Description The ContextHandler.MANAGED_ATTRIBUTES context parameter key allow webapps to declare a comma-separated list of context attribute names.

When the webapp calls ServletContext.setAttribute(name, obj) with one of the names of the list, ContextHandler adds the value as an unmanaged bean to itself. This in turn triggers listeners such as MBeanContainer that export the value obj as a JMX MBean.

The problem is that if the value obj is itself a ContainerLifeCycle with children beans, the children are not exported to JMX.

This behavior contrasts with adding a managed bean to ContextHandler. Since it's managed, the ContextHandler listeners that implement InheritedListener are also added to the managed bean, which allows to export its children to JMX.

There should be a generic way -- not tied to JMX -- to notify a bean of InheritedListeners even if it's not managed.

sbordet commented 3 years ago

@gregw now that CometD has its own executor and scheduler, it would be great if this is implemented. Thoughts?

sbordet commented 3 years ago

Also, there may be classloader issues?

As jetty-jmx is provided by the server, can web application objects such as CometD objects share the JMX mechanism with the server?

Or perhaps we just add jetty-jmx to the web application and create another MBeanContainer but this time in the web classloader space? Could there be a clash with the ObjectNames, if e.g. another QueuedThreadPool is registered?

gregw commented 3 years ago

Adding application objects as anything but unmanaged beans will introduce classloading issues. An unmanaged bean is dumped simply by calling it's toString method. For an application object to be managed and deeply dumped, it would need to have access to the container classes for LifeCycle and Dumpable... probably more.

To make this workable, we'd need to devise some kind of JMX/Dump interface that could be based on attributes, but only use java classes like Supplier<String> for a Dumpable.

We already dump context attributes and each servlet/filter, so for Dump, I think most things can be dumped there.

JMX is a bit more difficult. We do use reflection to make MBeans, but the app would need to share the servers annotation classes. This will need careful thought to not make a bad situation worse.

github-actions[bot] commented 2 years ago

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] commented 1 year ago

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] commented 9 months ago

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.