Question

I’m currently using AS6.final, with Weld upgraded to 1.1.1.final. EAR class isolatation is turned off. I have an EJB singleton, that I’ve registered with JMX – the EJB class is packaged in a JAR within an EAR. When I invoke one of the methods on this bean, via the JMX-console, I get this error:

09:13:49,984 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/jmx-console].[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception: java.lang.IllegalStateException: Singleton not set for BaseClas
sLoader@c68740c{vfs:///C:/jboss-6.0.0.Final/common/deploy/jmx-console.war}
        at org.jboss.weld.integration.provider.JBossSingletonProvider$EarSingleton.get(JBossSingletonProvider.java:59) [:6.0.0.Final]
        at org.jboss.weld.Container.instance(Container.java:58) [:2011-04-04 15:54]
        at org.jboss.weld.resolution.ResolvableBuilder.checkQualifier(ResolvableBuilder.java:209) [:2011-04-04 15:54]
        at org.jboss.weld.resolution.ResolvableBuilder.addQualifier(ResolvableBuilder.java:174) [:2011-04-04 15:54]
        at org.jboss.weld.resolution.ResolvableBuilder.addQualifiers(ResolvableBuilder.java:202) [:2011-04-04 15:54]
        at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:108) [:2011-04-04 15:54]
        at org.jboss.seam.transaction.TransactionInterceptor.aroundInvoke(TransactionInterceptor.java:188) [:3.0.0.Final]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_07]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_07]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_07]
        at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_07]
        at org.jboss.interceptor.proxy.InterceptorInvocation$InterceptorMethodInvocation.invoke(InterceptorInvocation.java:72) [:2.0.0.CR1]
        at org.jboss.interceptor.proxy.SimpleInterceptionChain.invokeNextInterceptor(SimpleInterceptionChain.java:82) [:2.0.0.CR1]
        at org.jboss.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:133) [:2.0.0.CR1]
        at org.jboss.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:112) [:2.0.0.CR1]
        at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:65) [:2011-04-04 15:54]
        at uk.co.myApp.myService.service.org$jboss$weld$bean-jboss$classloader$id="vfs$$$$C$$jboss-6$0$0$Final$server$all$deploy$myService-ear-2011$1$2-SNAPSHOT$ear"-ManagedBean-uk$co$myApp$myService$service$MyServiceerDAO$@org$jboss$seam$transaction$
Transactional(value=REQUIRED)@org$jboss$seam$transaction$TransactionalInterceptorBinding()${uk$co$myApp$myService$service$MyServiceerDAO$jamJobTrackerDAO$@javax$inject$Inject()$$uk$co$myApp$myService$service$MyServiceerDAO$linkDAO$@javax$inject$Inject
()$$uk$co$myApp$myService$service$MyServiceerDAO$ruleDAO$@javax$inject$Inject()$$uk$co$myApp$myService$service$MyServiceerDAO$sliceDAO$@javax$inject$Inject()$$uk$co$myApp$myService$service$MyServiceerDAO$myServiceJobDAO$@javax$inject$Inject()$$}_$$_WeldSubclass.l
oadSliceInitialiseMyServiceCollections(org$jboss$weld$bean-jboss$classloader$id="vfs$$$$C$$jboss-6$0$0$Final$server$all$deploy$myService-ear-2011$1$2-SNAPSHOT$ear"-ManagedBean-uk$co$myApp$myService$service$MyServiceerDAO$@org$jboss$seam$transaction$Tr
ansactional(value=REQUIRED)@org$jboss$seam$transaction$TransactionalInterceptorBinding()${uk$co$myApp$myService$service$MyServiceerDAO$jamJobTrackerDAO$@javax$inject$Inject()$$uk$co$myApp$myService$service$MyServiceerDAO$linkDAO$@javax$inject$Inject()
$$uk$co$myApp$myService$service$MyServiceerDAO$ruleDAO$@javax$inject$Inject()$$uk$co$myApp$myService$service$MyServiceerDAO$sliceDAO$@javax$inject$Inject()$$uk$co$myApp$myService$service$MyServiceerDAO$myServiceJobDAO$@javax$inject$Inject()$$}_$$_WeldSubclass.jav
a)
        at uk.co.myApp.myService.service.MyServiceService.startCDIJob(MyServiceService.java:96) [:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_07]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_07]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_07]
        at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_07]
        at org.gescobar.management.util.MBeanImpl.invoke(MBeanImpl.java:181) [:]
        at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164) [:6.0.0.GA]
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.GA]
        at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:258) [:]
        at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223) [:]
        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$3.run(HtmlAdaptorServlet.java:380) [:]
        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$3.run(HtmlAdaptorServlet.java:377) [:]
        at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_07]
        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:376) [:]
        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:287) [:]
        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:104) [:]
        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:86) [:]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [:1.0.0.Final]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [:1.0.0.Final]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [:6.0.0.Final]
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.Final]
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [:6.0.0.Final]
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [:6.0.0.Final]
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.0.0.Final]
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.0.0.Final]
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.0.0.Final]
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.Final]
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.Final]
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.Final]
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.Final]
        at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.Final]
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.Final]
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [:6.0.0.Final]
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654) [:6.0.0.Final]
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.Final]
        at java.lang.Thread.run(Thread.java:619) [:1.6.0_07]

The method involves opening a transaction, as you can see from the trace. I think the general error is to do with classloading, however (see https://issues.jboss.org/browse/SEAMJMS-16); by invoking the method via the JMX-console in a browser, I’m doing it ‘outside’ of the EAR app which contains the EJB class.

I’ve tried specifying scoped class loading (http://community.jboss.org/wiki/ClassLoadingConfiguration) by adding the following code (with necessary syntax changes between the files) to both the EAR jboss-app.xml and the jmx-console.war jboss-web.xml:

<class-loading java2ClassLoadingCompliance="false">
  <loader-repository>
     my.domain:archive=myapp-ear
     <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
  </loader-repository>
</class-loading>

However this has had no effect.

I’ve been referred to https://issues.jboss.org/browse/WELD-888, and think I could pursue a similar solution; turn off WAR class isolation for the jmx-console.war, so it can see the other classes deployed (EAR class isolation is already off).

http://community.jboss.org/wiki/UseJBossWebClassLoaderInJBoss5 gives 2 ways to do this:

1. Comment out WarClassLoaderDeployer bean in all/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml

2. Add a new file, jboss-classloading, to jmx-console.war/WEB-INF/ with the following content:

   <?xml version="1.0" encoding="UTF-8"?>
   <classloading xmlns="urn:jboss:classloading:1.0"
       name="jmx-console.war"
       domain="DefaultDomain"
       parent-domain="Ignored"           
       export-all="NON_EMPTY"
       import-all="true">
   </classloading>
   

I’ve tried both of these, separately, both with the jmx-console.war directory in common/deploy and in server/all/deploy – none of them seem to work.

Even putting all required libs in jmx-console.war/WEB-INF/lib/ doesn’t work, as it tries to deploy the EJB again (at least into Weld) when you call the JMX-console! That wasn’t a good solution anyway – every time you deployed, you’d have to update the lib, as well.

So… any ideas how I can achieve EAR class visibility for jmx-console.war? And actually use it to do something meaningful?

Answer 1

Sorted this now, thanks to Ales Justin on the JBoss.org forum (http://community.jboss.org/message/616328).

Basically, my registration code was calling the only public method available to register the mbean, MBeanServer.registerMBean(Object object, ObjectName name). This doesn’t specify a classloader, and the classloader registered with the bean in the JMX registry is therefore null.

This means that when you invoke a method on the bean via the JMX console in the browser, it falls back to the classloader on the invoking thread – not helpful if you’re trying to do anything involved, as it won’t have any of your classes, hence the error above.

Ales pointed me at an alternative way of registering the bean which overcomes this issue, which is used in JBoss service code. So instead of

DynamicMBean mBean = getMBeanFactory().createMBean(this);
MBeanServer mBeanServer = MBeanServerLocator.instance().getmBeanServer();
ObjectName name;
try {
    name = new ObjectName(jmxObjectName);
    mBeanServer.registerMBean(mBean, name);
}
catch (Throwable t) {
    log.error(String.format("Unable to register [%s] with JMX under [%s]:", serviceName, jmxObjectName), t);
}

I’m now using

DynamicMBean mBean = getMBeanFactory().createMBean(this);
MBeanServer mBeanServer = MBeanServerLocator.instance().getmBeanServer();
ObjectName name;
try {
    name = new ObjectName(jmxObjectName);

    Map<String, Object> values = new HashMap<String, Object>();
    ClassLoader classLoader = this.getClass().getClassLoader();
    log.info(String.format("Registering to JMX with classLoader [%s]",classLoader.toString()));
    values.put(ServerConstants.CLASSLOADER, classLoader);

    mBeanServer.invoke(
        ObjectNameFactory.create(ServerConstants.MBEAN_REGISTRY), 
        "registerMBean", 
        new Object[] { mBean, name, values }, 
        new String[] { Object.class.getName(), ObjectName.class.getName(), Map.class.getName() }
    );
} catch (Throwable t) {
    log.error(String.format("Unable to register [%s] with JMX under [%s]:", serviceName, jmxObjectName), t);
}

This is taken from org.jboss.system.ServiceCreator.installPlainMBean(MBeanServer server, ObjectName objectName, ServiceMetaData metaData). You invoke registerMBean on the MbeanResgistry bean itself, it seems, and here you can pass a classloader, which is then switched to when you invoke the bean method in the browser.