JBossDeveloper

I'm still seeing this after updating the microcontainer and aop libs. Here's the stack trace (just pasting the caused by):

Caused by: java.lang.NullPointerException
 at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.<init>(DistributedReplicantManagerImpl.java:117)
 at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.<init>(DistributedReplicantManagerImpl.java:102)
 at AOPContainerProxy$3.<init>(AOPContainerProxy$3.java)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
 at java.lang.Class.newInstance0(Class.java:350)
 at java.lang.Class.newInstance(Class.java:303)
 at org.jboss.aop.proxy.container.GeneratedAOPProxyFactory.instantiateAndConfigureProxy(GeneratedAOPProxyFactory.java:148)
 at org.jboss.aop.proxy.container.GeneratedAOPProxyFactory.getProxy(GeneratedAOPProxyFactory.java:122)
 ... 29 more

Another problem I'm seeing is that many beans implement MBeanRegistration, but those callbacks aren't getting invoked. I think this is because the object registered with the MBeanServer is not the bean itself but rather a StandardMBean created in JMXIntroduction. That object doesn't implement MBeanRegistration.

With the beans I'm working with, it's actually not necessary to wrap them in a StandardMBean object before registering them. They are all already compliant standard mbeans of the X implements XMBean variety.

I'm going to play a bit and see if there's any issue with registering the beans directly.

That is correct. We really should validate whether the target already implements a particular jmx interface, or just add an attribute to the annotation to indicate if the target should not be wrapped before registration.

I was playing with the StandardMBean thing and rebuilt the aop-mc-int-dep.jar from source. After that the DistributedReplicantManager NPE went away. Is the microcontainer snapshot on repository.jboss.com up to date?

Tweaking JMXIntroduction so it just directly registered my beans worked just fine. The problem is there is no way to cleanly express that that's what I want done:

1) JMXIntroduction could just try to register context.getTarget(), catch NotCompliantMBeanException, and then create and register the StandardMBean. Problem is this approach ignores the @JMX.exposedInterface value -- what if the bean is Foo implements FooMBean, Bar, and @JMX.exposedInterface=Bar.class? Kind of an edge case, but not clean.

2) JMXIntroduction could try to register context.getTarget() only if @JMX.exposedInterface=null. This would be a clean solution. Problem is null is not a valid value for an annotation attribute, and the attribute type is Class, so you can't use the "" means null trick. (Hacky idea -- make it "Class exposedInterface() default void.class". The compiler accepts that.)

3) I tried adding another attribute "boolean registerDirectly() default false;" to @JMX. But the deployment of any beans where it didn't specify the attribute failed in SimpleAnnotationValidator, which makes no attempt to read default values.

Kabir implemented b) above, and I've checked in the addition of the @JMX.registerDirectly() attribute to microcontainer trunk (see http://jira.jboss.com/jira/browse/JBMICROCONT-109).

"scott.stark@jboss.org" wrote:
We really should validate whether the target already implements a particular jmx interface.

Want to confirm that I understand your semantics:

AUTO = try to register directly, if it fails, create and register StandardMBean
STRICT = try to register directly, if it fails, throw exception
NONE = just create and register StandardMBean

This is OK by me, but probably won't get done this week. Also, is use of an enum allowed in the microcontainer (I don't know enough about the retroweaver to know). And can jbossxb populate an enum from a XML string? There was a mention of that on another thread, but I don't know if it happened. If either of the above are issues, we can just use a string.

With AUTO I wouldn't go register it directly and see if it fails. I would go and validate it first, if it passes then register it directly - ok it can still fail - but we at least know we tried our best.

With STRICT we also validate first - if it doesn't even pass validation throw an exception - and if it later fails ofcourse.

NONE is ok as it is.

>> can jbossxb populate an enum from a XML string?

Sure. You are the one writting binding code. See org.jboss.kernel.plugins.deployment.xml.[name]Handler.
How this goes with retro stuff - don't know yet. :-(

"bstansberry@jboss.com" wrote:
Also, is use of an enum allowed in the microcontainer (I don't know enough about the retroweaver to know). And can jbossxb populate an enum from a XML string? There was a mention of that on another thread, but I don't know if it happened. If either of the above are issues, we can just use a string.

java.lang.IllegalArgumentException: Wrong arguments. setEnumProperty for target org.jboss.test.kernel.config.support.SimpleBean@150bd4d expected=[org.jboss.test.kernel.config.support.SimpleBean$Alphabet] actual=[java.lang.String]
 at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:224)
 at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
 at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:108)
 at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
 at org.jboss.test.kernel.config.test.AbstractKernelConfigTest.configure(AbstractKernelConfigTest.java:130)
 at org.jboss.test.kernel.config.test.ConfigureAttributeFromStringTestCase.configureSimpleBean(ConfigureAttributeFromStringTestCase.java:239)
 at org.jboss.test.kernel.config.test.ConfigureAttributeFromStringTestCase.testEnum(ConfigureAttributeFromStringTestCase.java:209)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at junit.framework.TestCase.runTest(TestCase.java:154)
 at junit.framework.TestCase.runBare(TestCase.java:127)
 at junit.framework.TestResult$1.protect(TestResult.java:106)
 at junit.framework.TestResult.runProtected(TestResult.java:124)
 at junit.framework.TestResult.run(TestResult.java:109)
 at junit.framework.TestCase.run(TestCase.java:118)
 at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
 at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)