Derby
  1. Derby
  2. DERBY-3887

Embedded Derby fails under JBoss because of JMX-related conflicts

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 10.4.2.0
    • Fix Version/s: 10.4.2.1, 10.5.2.0, 10.6.1.0
    • Component/s: JMX
    • Labels:
      None
    • Environment:
      Windows XP SP2, JBoss 4.2.3.GA, Embedder Derby 10.4.2.0.
      Also tested with JBoss 5.0.0.CR2 with the same result.
    • Issue & fix info:
      High Value Fix
    • Bug behavior facts:
      Regression

      Description

      I'm trying to use embedded Derby as datasource for JBoss and found that it fails with error.
      See stacktrace below.
      It looks like JMX module in Derby conflicts with JBoss JMX.
      After I have disabled Derby JMX removing "derby.module.mgmt.jmx=org.apache.derby.impl.services.jmx.JMXManagementService" line from org\apache\derby\modules.properties file in derby.jar JAR, the bug disappears.

      How to reproduce the issue:
      1). Install JBoss
      2). Copy jboss\docs\examples\varia\derby-plugin.jar into jboss\server\default\lib
      3). Copy Derby JAR (derby.jar) into jboss\server\default\lib
      4). Copy datasource file into jboss\server\default\lib
      5). Start JBoss using bin\run.bat

      Datasource file (zzzzz-ds.xml):

      ==={{{
      <?xml version="1.0" encoding="UTF-8"?>

      <!DOCTYPE datasources
      PUBLIC "-//JBoss//DTD JBOSS JCA Config 1.5//EN"
      "http://www.jboss.org/j2ee/dtd/jboss-ds_1_5.dtd">

      <datasources>
      <local-tx-datasource>
      <jndi-name>zzzzzDatasource</jndi-name>
      <driver-class>org.apache.derby.jdbc.EmbeddedDriver</driver-class>
      <!--connection-url>jdbc:derby:$

      {jboss.server.data.dir} {/}derby{/}

      zzzzz;create=true</connection-url-->
      <connection-url>jdbc:derby:IGNORED</connection-url>
      <user-name>IGNORED</user-name>
      <password>IGNORED</password>
      <min-pool-size>5</min-pool-size>
      <max-pool-size>20</max-pool-size>
      <idle-timeout-minutes>5</idle-timeout-minutes>
      <track-statements/>
      <depends>jboss:service=zzzzzDerbyDB</depends>
      </local-tx-datasource>

      <!-- Don't forget to install derby-plugin.jar and derby*.jar into jboss/server/default/lib -->
      <mbean code="org.jboss.jdbc.DerbyDatabase" name="jboss:service=zzzzzDerbyDB">
      <attribute name="Database">zzzzz</attribute>
      <attribute name="User">sa</attribute>
      <attribute name="Password"></attribute>
      </mbean>

      </datasources>
      ===}}}

      Part of JBoss log with error and stacktrace:

      ==={{{
      02:40:28,031 INFO [DerbyDatabase] starting derby jdbc:derby:C:\opt\jboss-4.2.3.GA\server\default\data/derby/zzzzz;create=true
      02:40:28,468 WARN [ServiceController] Problem starting service jboss:service=zzzzzDerbyDB
      java.lang.ExceptionInInitializerError
      at java.lang.Class.forName0(Native Method)
      at java.lang.Class.forName(Class.java:247)
      at org.jboss.jdbc.DerbyDatabase.getConnection(DerbyDatabase.java:222)
      at org.jboss.jdbc.DerbyDatabase.startService(DerbyDatabase.java:189)
      at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
      at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
      at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
      at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
      at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
      at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
      at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
      at $Proxy0.start(Unknown Source)
      at org.jboss.system.ServiceController.start(ServiceController.java:417)
      at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
      at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
      at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
      at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
      at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
      at $Proxy4.start(Unknown Source)
      at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
      at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
      at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
      at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
      at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
      at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
      at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
      at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
      at $Proxy42.start(Unknown Source)
      at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
      at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
      at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
      at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
      at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
      at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
      at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
      at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
      at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
      at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
      at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
      at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
      at $Proxy9.deploy(Unknown Source)
      at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
      at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
      at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
      at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
      at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
      at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
      at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
      at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
      at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
      at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
      at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
      at $Proxy0.start(Unknown Source)
      at org.jboss.system.ServiceController.start(ServiceController.java:417)
      at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
      at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
      at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
      at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
      at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
      at $Proxy4.start(Unknown Source)
      at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304)
      at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
      at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
      at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
      at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
      at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
      at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
      at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
      at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
      at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
      at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
      at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
      at $Proxy5.deploy(Unknown Source)
      at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
      at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
      at org.jboss.Main.boot(Main.java:200)
      at org.jboss.Main$1.run(Main.java:508)
      at java.lang.Thread.run(Thread.java:619)
      Caused by: javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class org.jboss.mx.server.MBeanServerBuilderImpl: java.lang.ClassNotFoundException: org/jboss/mx/server/MBeanServerBuilderImpl
      at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:480)
      at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:511)
      at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:298)
      at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:213)
      at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:174)
      at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302)
      at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504)
      at org.apache.derby.impl.services.jmx.JMXManagementService$3.run(Unknown Source)
      at org.apache.derby.impl.services.jmx.JMXManagementService$3.run(Unknown Source)
      at java.security.AccessController.doPrivileged(Native Method)
      at org.apache.derby.impl.services.jmx.JMXManagementService.findServer(Unknown Source)
      at org.apache.derby.impl.services.jmx.JMXManagementService.boot(Unknown Source)
      at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source)
      at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source)
      at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
      at org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Unknown Source)
      at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unknown Source)
      at org.apache.derby.impl.services.monitor.FileMonitor.<init>(Unknown Source)
      at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown Source)
      at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source)
      at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source)
      at org.apache.derby.jdbc.EmbeddedDriver.<clinit>(Unknown Source)
      ... 110 more
      Caused by: java.lang.ClassNotFoundException: org/jboss/mx/server/MBeanServerBuilderImpl
      at java.lang.Class.forName0(Native Method)
      at java.lang.Class.forName(Class.java:169)
      at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:427)
      at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:465)
      ... 131 more
      02:40:29,250 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
      02:40:29,562 INFO [A] Bound to JNDI name: queue/A
      02:40:29,562 INFO [B] Bound to JNDI name: queue/B
      02:40:29,562 INFO [C] Bound to JNDI name: queue/C
      02:40:29,562 INFO [D] Bound to JNDI name: queue/D
      02:40:29,578 INFO [ex] Bound to JNDI name: queue/ex
      02:40:29,593 INFO [testTopic] Bound to JNDI name: topic/testTopic
      02:40:29,593 INFO [securedTopic] Bound to JNDI name: topic/securedTopic
      02:40:29,609 INFO [testDurableTopic] Bound to JNDI name: topic/testDurableTopic
      02:40:29,609 INFO [testQueue] Bound to JNDI name: queue/testQueue
      02:40:29,656 INFO [UILServerILService] JBossMQ UIL service available at : /127.0.0.1:8093
      02:40:29,703 INFO [DLQ] Bound to JNDI name: queue/DLQ
      02:40:29,875 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
      02:40:30,093 INFO [TomcatDeployer] deploy, ctxPath=/jmx-console, warUrl=.../deploy/jmx-console.war/
      02:40:30,250 ERROR [URLDeploymentScanner] Incomplete Deployment listing:

      — MBeans waiting for other MBeans —
      ObjectName: jboss:service=zzzzzDerbyDB
      State: FAILED
      Reason: java.lang.ExceptionInInitializerError
      Depends On Me:
      jboss.jca:service=ManagedConnectionFactory,name=zzzzzDatasource

      — MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM —
      ObjectName: jboss:service=zzzzzDerbyDB
      State: FAILED
      Reason: java.lang.ExceptionInInitializerError
      Depends On Me:
      jboss.jca:service=ManagedConnectionFactory,name=zzzzzDatasource

      02:40:30,656 INFO [Http11AprProtocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8080
      02:40:30,687 INFO [AjpAprProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009
      02:40:30,703 INFO [Server] JBoss (MX MicroKernel) [4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181439)] Started in 23s:375ms

      1. Derby3887.java
        0.5 kB
        Kathey Marsden
      2. derby-3887_test_attempt_diff.txt
        5 kB
        Kathey Marsden
      3. derby-3887_diff.txt
        3 kB
        Kathey Marsden

        Issue Links

          Activity

          Hide
          Dag H. Wanvik added a comment -

          Derby will try to start a JMX server. Looking at the Javadoc for MBeanServerFactory,
          http://java.sun.com/j2ee/1.4/docs/api/javax/management/MBeanServerFactory.html
          I notice that the property javax.management.builder.initial, if set, will be used to decide which builder
          to use for the MBeansServer. A possibility is that your environment defines this property
          to the missing class "org.jboss.mx.server.MBeanServerBuilderImpl", and that class is not
          on your classpath. Could this be your problem?

          Show
          Dag H. Wanvik added a comment - Derby will try to start a JMX server. Looking at the Javadoc for MBeanServerFactory, http://java.sun.com/j2ee/1.4/docs/api/javax/management/MBeanServerFactory.html I notice that the property javax.management.builder.initial, if set, will be used to decide which builder to use for the MBeansServer. A possibility is that your environment defines this property to the missing class "org.jboss.mx.server.MBeanServerBuilderImpl", and that class is not on your classpath. Could this be your problem?
          Hide
          Marco added a comment -

          We - http://www.jfire.org - have the same problem and assume that it is a caused by the deployment configuration: Because we use Derby for JBoss' messaging (JBossMQ), we have to put derby.jar into the lib directory (otherwise the JBossMQ fails with exceptions). However, the JMX seems to be in JBoss' deploy directory and therefore Derby has no chance to ever find the class (didn't verify this - just an assumption).

          Additionally, it might be a problem with timing: When Derby is loaded, maybe the JMX is not yet started?

          I don't know the best solution to this problem, but I know that we don't need JMX. That's why we deactivated this line mentioned above. However, patching a libraries JAR is not a nice way. Therefore, I'd like to ask for another - more convenient solution:

          1) Instead of an exception, it should simply log a warning and continue (JMX isn't really essential - is it?).
          2) It should be possible to provide a system property which deactivates the JMX hooking on startup (to get rid of the WARN log).

          In the long run, it would be nice to have a clean solution that takes the said problems (deployment location + timing) into account.

          Show
          Marco added a comment - We - http://www.jfire.org - have the same problem and assume that it is a caused by the deployment configuration: Because we use Derby for JBoss' messaging (JBossMQ), we have to put derby.jar into the lib directory (otherwise the JBossMQ fails with exceptions). However, the JMX seems to be in JBoss' deploy directory and therefore Derby has no chance to ever find the class (didn't verify this - just an assumption). Additionally, it might be a problem with timing: When Derby is loaded, maybe the JMX is not yet started? I don't know the best solution to this problem, but I know that we don't need JMX. That's why we deactivated this line mentioned above. However, patching a libraries JAR is not a nice way. Therefore, I'd like to ask for another - more convenient solution: 1) Instead of an exception, it should simply log a warning and continue (JMX isn't really essential - is it?). 2) It should be possible to provide a system property which deactivates the JMX hooking on startup (to get rid of the WARN log). In the long run, it would be nice to have a clean solution that takes the said problems (deployment location + timing) into account.
          Hide
          Kristian Waagan added a comment -

          Added a link to DERBY-3429, as it contains some discussion regarding disabling/enabling JMX.

          Show
          Kristian Waagan added a comment - Added a link to DERBY-3429 , as it contains some discussion regarding disabling/enabling JMX.
          Hide
          Dag H. Wanvik added a comment -

          I found this code fragment in org.apache.derby.impl.services.jmx#findServer,
          notice the catch clause comment:

          try {
          mbeanServer = AccessController
          .doPrivileged(new PrivilegedAction<MBeanServer>() {
          public MBeanServer run()

          { return ManagementFactory.getPlatformMBeanServer(); }

          });

          } catch (SecurityException se) {
          // Ignoring inability to create or
          // find the mbean server. MBeans can continue
          // to be registered with this service and
          // startMangement() can be called to get
          // them registered with JMX if someone else
          // starts the MBean server.

          Perhaps this ignore action should apply to the classNotFoundException, too?

          Show
          Dag H. Wanvik added a comment - I found this code fragment in org.apache.derby.impl.services.jmx#findServer, notice the catch clause comment: try { mbeanServer = AccessController .doPrivileged(new PrivilegedAction<MBeanServer>() { public MBeanServer run() { return ManagementFactory.getPlatformMBeanServer(); } }); } catch (SecurityException se) { // Ignoring inability to create or // find the mbean server. MBeans can continue // to be registered with this service and // startMangement() can be called to get // them registered with JMX if someone else // starts the MBean server. Perhaps this ignore action should apply to the classNotFoundException, too?
          Hide
          Jeremy Gustie added a comment -

          I have been seeing this issue as well, after a little poking around it appears that the JBoss classloader which contains the "missing" JBoss server builder is temporarily taken out of context by the DERBY-3745 fix (which sets the context class loader to null) in the JMXManagementService.

          The "org.jboss.mx.server.MBeanServerBuilderImpl" class identified by the "javax.management.builder.initial" system property actually lives in the "JBOSS_HOME/lib/jboss-jmx.jar" JAR; this class is available on classloader being taken out of context by the DERBY-3745 fix.

          What is not clear to me is why the platform MBean server isn't set by JBoss before this code executes: my guess is that this error is occurring before JBoss has fully initialized. If the ManagementFactory.getPlatformMBeanServer gets called anytime before Derby attempts to call it with a null context classloader this might not be a problem since the already created MBeanServerImpl instance would just be returned - like I said, if JBoss is not fully initialized this might not be possible. I'm not familiar enough with JMX or the JBoss implementation to know where this issue would need to be addressed (i.e. is this a JBoss or Derby issue). I don't think that ignoring the ClassNotFoundException would resolve the issue because you may end up masking other problems and making very difficult to track down why the management beans aren't being registered.

          If you are running JBoss with a security manager, you could in theory deny the Derby JMXManagementService the "setContextClassLoader" runtime permission; that would prevent the classloader from being taken out of context (and Derby will silently eat the security exception in the name of backwards compatibility). I'm not sure what other problems that causes though (I haven't tried it).

          Show
          Jeremy Gustie added a comment - I have been seeing this issue as well, after a little poking around it appears that the JBoss classloader which contains the "missing" JBoss server builder is temporarily taken out of context by the DERBY-3745 fix (which sets the context class loader to null) in the JMXManagementService. The "org.jboss.mx.server.MBeanServerBuilderImpl" class identified by the "javax.management.builder.initial" system property actually lives in the "JBOSS_HOME/lib/jboss-jmx.jar" JAR; this class is available on classloader being taken out of context by the DERBY-3745 fix. What is not clear to me is why the platform MBean server isn't set by JBoss before this code executes: my guess is that this error is occurring before JBoss has fully initialized. If the ManagementFactory.getPlatformMBeanServer gets called anytime before Derby attempts to call it with a null context classloader this might not be a problem since the already created MBeanServerImpl instance would just be returned - like I said, if JBoss is not fully initialized this might not be possible. I'm not familiar enough with JMX or the JBoss implementation to know where this issue would need to be addressed (i.e. is this a JBoss or Derby issue). I don't think that ignoring the ClassNotFoundException would resolve the issue because you may end up masking other problems and making very difficult to track down why the management beans aren't being registered. If you are running JBoss with a security manager, you could in theory deny the Derby JMXManagementService the "setContextClassLoader" runtime permission; that would prevent the classloader from being taken out of context (and Derby will silently eat the security exception in the name of backwards compatibility). I'm not sure what other problems that causes though (I haven't tried it).
          Hide
          Jeremy Gustie added a comment -

          You can enable JBoss to act as the platform MBean server on Java 5+ runtimes using the "jboss.platform.mbeanserver" system property (add it to the JBoss run script in the JAVA_OPTS variable). See JBAS-1610 on the JBoss JIRA site. Doing this will ensure that ManagementFactory.getPlatformMBeanServer returns the JBoss MBeanServerImpl instead of trying to create a new one with implementations that are not available.

          Show
          Jeremy Gustie added a comment - You can enable JBoss to act as the platform MBean server on Java 5+ runtimes using the "jboss.platform.mbeanserver" system property (add it to the JBoss run script in the JAVA_OPTS variable). See JBAS-1610 on the JBoss JIRA site. Doing this will ensure that ManagementFactory.getPlatformMBeanServer returns the JBoss MBeanServerImpl instead of trying to create a new one with implementations that are not available.
          Hide
          John H. Embretsen added a comment -

          Some possibly useful reading material for anyone wanting to investigate further:
          http://blogs.sun.com/jmxetc/entry/the_mystery_of_multiple_mbeanservers

          Show
          John H. Embretsen added a comment - Some possibly useful reading material for anyone wanting to investigate further: http://blogs.sun.com/jmxetc/entry/the_mystery_of_multiple_mbeanservers
          Hide
          Kathey Marsden added a comment -

          I am thinking I should back out the JMX portiion of the fix for DERBY-3745 to correct this issue, to get rid of the regression and file a new issue for the potential classloader leak that can occur if that fix is backed out. I will keep the rest of the DERBY-3745 fix as nobody has complained about any issues with that. Any objections?

          Show
          Kathey Marsden added a comment - I am thinking I should back out the JMX portiion of the fix for DERBY-3745 to correct this issue, to get rid of the regression and file a new issue for the potential classloader leak that can occur if that fix is backed out. I will keep the rest of the DERBY-3745 fix as nobody has complained about any issues with that. Any objections?
          Hide
          Kathey Marsden added a comment -

          Here is the patch to back out the JMX related portion of DERBY-3745. I am running tests now. I don't have a reproduction for DERBY-3887, so I would appreciate someone who is seeing this issue could give this patch a try.

          Thanks

          Kathey

          Show
          Kathey Marsden added a comment - Here is the patch to back out the JMX related portion of DERBY-3745 . I am running tests now. I don't have a reproduction for DERBY-3887 , so I would appreciate someone who is seeing this issue could give this patch a try. Thanks Kathey
          Hide
          Kathey Marsden added a comment -

          Tests ran fine. Marking patch available. I'll check in as soon as I hear feedback on whether it corrects the issue.

          Show
          Kathey Marsden added a comment - Tests ran fine. Marking patch available. I'll check in as soon as I hear feedback on whether it corrects the issue.
          Hide
          Kathey Marsden added a comment -

          committed change to 10.6,10.5, and 10.4. I hope some JBOSS users can confirm this fix. I will file a new issue for the apparent JMX related class loader leak after a bit more research.

          Show
          Kathey Marsden added a comment - committed change to 10.6,10.5, and 10.4. I hope some JBOSS users can confirm this fix. I will file a new issue for the apparent JMX related class loader leak after a bit more research.
          Hide
          Kathey Marsden added a comment -

          Attached is a reproduction for this issue. Without the fix, it fails with:
          Exception in thread "main" java.lang.ExceptionInInitializerError
          at java.lang.J9VMInternals.initialize(J9VMInternals.java:222)
          at java.lang.Class.forNameImpl(Native Method)
          at java.lang.Class.forName(Class.java:136)
          at Derby3887.main(Derby3887.java:6)
          Caused by: javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class Derby3887: java.lang.ClassNotFoundException: Derby3887
          at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:491)
          at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:522)
          at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:309)
          at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:224)
          at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:185)
          at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:298)
          at org.apache.derby.impl.services.jmx.JMXManagementService$3.run(JMXManagementService.java:207)
          at org.apache.derby.impl.services.jmx.JMXManagementService$3.run(JMXManagementService.java:205)
          at java.security.AccessController.doPrivileged(AccessController.java:202)
          at org.apache.derby.impl.services.jmx.JMXManagementService.findServer(JMXManagementService.java:204)
          at org.apache.derby.impl.services.jmx.JMXManagementService.boot(JMXManagementService.java:114)
          at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2021)
          at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
          at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573)
          at org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Monitor.java:366)
          at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseMonitor.java:398)
          at org.apache.derby.impl.services.monitor.FileMonitor.<init>(FileMonitor.java:60)
          at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.java:289)
          at org.apache.derby.iapi.jdbc.JDBCBoot.boot(JDBCBoot.java:69)
          at org.apache.derby.jdbc.EmbeddedDriver.boot(EmbeddedDriver.java:201)
          at org.apache.derby.jdbc.EmbeddedDriver.<clinit>(EmbeddedDriver.java:96)
          at java.lang.J9VMInternals.initializeImpl(Native Method)
          at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
          ... 3 more
          Caused by: java.lang.ClassNotFoundException: Derby3887
          at java.lang.Class.forName(Class.java:136)
          at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:438)
          at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:476)
          ... 25 more

          and I confirmed it passes with the fix. I will look at getting this checked in as a regression test, but will still leave this issue in a resolved state since the code fix is checked in.

          Show
          Kathey Marsden added a comment - Attached is a reproduction for this issue. Without the fix, it fails with: Exception in thread "main" java.lang.ExceptionInInitializerError at java.lang.J9VMInternals.initialize(J9VMInternals.java:222) at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:136) at Derby3887.main(Derby3887.java:6) Caused by: javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class Derby3887: java.lang.ClassNotFoundException: Derby3887 at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:491) at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:522) at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:309) at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:224) at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:185) at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:298) at org.apache.derby.impl.services.jmx.JMXManagementService$3.run(JMXManagementService.java:207) at org.apache.derby.impl.services.jmx.JMXManagementService$3.run(JMXManagementService.java:205) at java.security.AccessController.doPrivileged(AccessController.java:202) at org.apache.derby.impl.services.jmx.JMXManagementService.findServer(JMXManagementService.java:204) at org.apache.derby.impl.services.jmx.JMXManagementService.boot(JMXManagementService.java:114) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2021) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573) at org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Monitor.java:366) at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseMonitor.java:398) at org.apache.derby.impl.services.monitor.FileMonitor.<init>(FileMonitor.java:60) at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.java:289) at org.apache.derby.iapi.jdbc.JDBCBoot.boot(JDBCBoot.java:69) at org.apache.derby.jdbc.EmbeddedDriver.boot(EmbeddedDriver.java:201) at org.apache.derby.jdbc.EmbeddedDriver.<clinit>(EmbeddedDriver.java:96) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) ... 3 more Caused by: java.lang.ClassNotFoundException: Derby3887 at java.lang.Class.forName(Class.java:136) at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:438) at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:476) ... 25 more and I confirmed it passes with the fix. I will look at getting this checked in as a regression test, but will still leave this issue in a resolved state since the code fix is checked in.
          Hide
          Kathey Marsden added a comment -

          I found that I am able to make a JUnit test based on the repro which will fail without my change but pass with it, but I can only get it to fail (with the old code) if it is run as the first test. If other tests booting derby are run prior to this one in the same JVM, I think a successful call to getPlatformMBeanServer() has already been made and thus registered, so the call to getPlatformMBeanServer() is successful.

          I did not immediately see a way to clear the platformMBeanServer. Please let me know if you know of one. Otherwise I think I will work on trying to make a call to launch a Junit test in another JVM, which I need for the store recover tests anyway.

          Attached is derby-3887_test_attempt_diff.txt with my initial attempt.

          Show
          Kathey Marsden added a comment - I found that I am able to make a JUnit test based on the repro which will fail without my change but pass with it, but I can only get it to fail (with the old code) if it is run as the first test. If other tests booting derby are run prior to this one in the same JVM, I think a successful call to getPlatformMBeanServer() has already been made and thus registered, so the call to getPlatformMBeanServer() is successful. I did not immediately see a way to clear the platformMBeanServer. Please let me know if you know of one. Otherwise I think I will work on trying to make a call to launch a Junit test in another JVM, which I need for the store recover tests anyway. Attached is derby-3887_test_attempt_diff.txt with my initial attempt.
          Hide
          Valery Khromov added a comment -

          Hi Kathey,

          I'd like to test the fix.
          It there a binary build available with this patch?
          Latest Derby at http://www.apache.org/dist/db/derby/db-derby-current-bin.tar.gz is 10.5.1.1.

          Show
          Valery Khromov added a comment - Hi Kathey, I'd like to test the fix. It there a binary build available with this patch? Latest Derby at http://www.apache.org/dist/db/derby/db-derby-current-bin.tar.gz is 10.5.1.1.
          Hide
          Knut Anders Hatlen added a comment -

          You could try the binaries used in the nightly testing of the 10.5 branch, found here: http://dbtg.thresher.com/derby/bits/10.5/

          Show
          Knut Anders Hatlen added a comment - You could try the binaries used in the nightly testing of the 10.5 branch, found here: http://dbtg.thresher.com/derby/bits/10.5/
          Hide
          Kristian Waagan added a comment -

          Some JBoss users might find this blog entry helpful: http://alistairisrael.wordpress.com/2009/03/31/creating-derby-datasource-in-jboss/

          What's the status on the fix?
          Has it been confirmed?

          Show
          Kristian Waagan added a comment - Some JBoss users might find this blog entry helpful: http://alistairisrael.wordpress.com/2009/03/31/creating-derby-datasource-in-jboss/ What's the status on the fix? Has it been confirmed?

            People

            • Assignee:
              Kathey Marsden
              Reporter:
              Valery Khromov
            • Votes:
              4 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development