JMX exporter fails on dynamic proxies [INT-1675]

[spring-operator]

Mark Fisher opened INT-1675 and commented

There seems to be an ordering problem: if the IntegrationMBeanExporter manages to run before the vanilla MBeanExporter it creates proxies that allegedly cannot be wrapped. Probably a bug in Spring Core as well (I can think of no reason why a Proxy cannot be wrapped, but I could be wrong), but we should try and find a workaround.

---

Affects: 2.0 Final

Reference URL: http://forum.springsource.org/showthread.php?t=98816

Issue Links:

• Routers Cause MBean Registration Failures When Using Both Spring and Spring Integration MBean Exporters [INT-2307] #6292 Routers Cause MBean Registration Failures When Using Both Spring and Spring Integration MBean Exporters

[spring-operator]

Dave Syer commented

I still can't reproduce this problem with the JMX unit tests (although I did see it in the Cafe demo, so that's something to work on). I did notice a surprising related problem though: the context:mbean-exporter/ registers a bean with id=mbeanExporter (non-configurable), so if you happen to use the same id for int-jmx:mbean-exporter/ then there is a clash and only one of them will be registered (normal override rules). I'll make mbeanExporter illegal to prevent that.

[spring-operator]

Dave Syer commented

The problem is not the order of the MBeanExporter definitions, rather it is to do with the order of the Integration component definitions (MessageHandlers in particular) and the MBeanExporters:

If the context contains both an IntegrationMBeanExporter and a vanilla MBeanExporter with annotation MBeanInfo, the vanilla exporter must be initialized before the integration one. Otherwise the integration one creates proxies for handlers etc, which then cause the vanilla exporter to barf later. If the proxies are created after the vanilla exprter has initialized and registered all its MBeans, everything works fine.

The least hacky approach I found was to add an explicit call to beanFactory.getBeansOfType(MBeanExporter.class) in the initializer of the integration exporter. The RouterMBeanTests were extended to cover all the scenarios that might have failed.

Unfortunately that leads to other problems (partially of our own making) with bean initialization: getBeansOfType() or getBeanNamesForType() both cause factory beans to to initialized, and any factory bean that aggressively creates its product on initialization will then create a product that is not available to be registered as an MBean because the exporter has itself not yet been initialized. If factory beans only created their products lazily in getObject() I believe the problem could be avoided, but that would be quite a big assumption (and a big job to clean up just the Spring Integration factory beans). GatewayProxyFactoryBean was the main culprit that I found: if there is one of those in the context then its downstream MessageChannel is not registered as an MBean because it is created too early.

An alternative might be to lazily force the vanilla MBeanExporter to initialize, not in the initializer of the IntegrationMBeanExporter, but in the first call to postProcessAfterInitialization(). This has the desired effect of allowing the IntegrationMBeanExporter to register all the beans that it needs to, but ignores the potential needs of others - e.g. AbstractMessageRouter is an @ManageedResource, but that resource is not exposed if there is an IntegrationMBeanExporter because it is wrapped in a proxy before the vanilla MBeanExporter gets a chance to look at it..

Another approach which would work would be to set proxy-target-class="true" on the proxy factory used to create the monitor beans. Problems with that: a) requires cgib on classpath, b) many Spring Integration components do not have a default constructor. If we don't care about a) we could fix b) but it's hard to enforce.

Yet another approach would be to remove @ManagedResource from any concrete class that gets exposed by IntegrationMBeanExporter. The only one I found was AbstractMessageRouter. We would need to add the @Managed* methods from that concrete class to an interface somewhere and implement it in the monitor bean. Those methods were marked to expose them to the control bus, so again there is an enforcement problem (hard to prevent new components from wanting to expose @ManagedOperations). Perhaps it would be worth enforcing a rule of no @Managed* on concrete types at compile time somehow (aspects) anyway?

Or we could figure out what the problem is in Spring, fix that, and tell Integration users that they need to upgrade Spring if they want to use JMX. Might be messy, especially if concrete types are being annotated. Maybe that's why the check is in there now - to prevent @Managed* methods from being dropped when a bean is advised? So the fix would have to involve pulling the target out of an Advised instance (if there was one).

I have also found another problem with bean definition ordering and the Core Spring exporter: it sometimes fails to autodetect Router beans anyway (even if they are not hidden in a Proxy by the IntegrationMBeanExporter). This is surprisingly easy to reproduce: all you need is a factory bean that produces a @ManagedResource (like the RouterFactoryBean does) - a factory bean is not asked for its product by the MBeanExporter, so if the product is not created before the MBeanExporter it is never registered. To force registration, a singleton bean is needed, defined before the MBeanExporter, and depending on the factory bean. Yuck.

[spring-operator]

Dave Syer commented

Here's what we did (for now at least):

• The beans that we wrap in monitor aspects are explicitly excluded from the other MBean exporters in the context
• The monitors are exposed as before
• The targets of the monitors are also exposed (with the same name but a different type) if they are a @ManagedResource
• There is no need for all @Managed* to be in an interface (but it would make sense at least for framework resources)

[spring-operator]

Dave Syer commented

Observations on the solution:

• If Spring would expose beans with @ManagedResource on the superclass or interfaces we would get a lot more action in the integration components. Why does it not? See SPR-7814.
• It's possible that it only works with factory bean products (which applies to some but not all of the integration components). More testing required (please open another issue if you find a problem).