1 Reply Latest reply on Feb 15, 2013 3:16 AM by Dominik Grupp

    For JPA test ClassNotFoundException: org.jboss.as.osgi.OSGiConstants

    Dominik Grupp Newbie

      Hi

       

      The arquillian starter kit (Testing Java Persistence - http://arquillian.org/guides/testing_java_persistence/) runs fine in my environment as a standalone project. However, when trying to take it (all classes and configuration files) over into a multi-module maven project the following exception is thrown. For full trace see attached logfile.

      Caused by: java.lang.ClassNotFoundException: org.jboss.as.osgi.OSGiConstants from [Module "deployment.arquillian-service:main" from Service Module Loader]
                at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.1.1.GA]
                at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) [jboss-modules.jar:1.1.1.GA]
                at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) [jboss-modules.jar:1.1.1.GA]
                at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423) [jboss-modules.jar:1.1.1.GA]
                at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.1.1.GA]
                at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) [jboss-modules.jar:1.1.1.GA]
                ... 23 more
      

       

      JBoss seems not to provide that module but that problem shouldn't come up since the arquillian starter kit standalone is running fine and so does the multimodule project. The problem possibly comes from how the container is started. When using the standalone version of the tutorial the container is started in the following way and the test runs just fine.

       

       

      INFO: Starting container with: [c:\Programme\Java\jdk1.6.0_37\\bin\java, -Xmx512m, -XX:MaxPermSize=128m, -ea, -Djboss.home.dir=c:\Daten\Programme\jboss-as-7.1.1.Final, -Dorg.jboss.boot.log.file=c:\Daten\Programme\jboss-as-7.1.1.Final/standalone/log/boot.log, -Dlogging.configuration=file:c:\Daten\Programme\jboss-as-7.1.1.Final/standalone/configuration/logging.properties, -Djboss.modules.dir=C:\Daten\Programme\jboss-as-7.1.1.Final\modules, -Djboss.bundles.dir=C:\Daten\Programme\jboss-as-7.1.1.Final\bundles, -jar, c:\Daten\Programme\jboss-as-7.1.1.Final\jboss-modules.jar, -mp, c:\Daten\Programme\jboss-as-7.1.1.Final\modules, -jaxpmodule, javax.xml.jaxp-provider, org.jboss.as.standalone, -server-config, standalone.xml]

       

       

      But when I try to start it from my project the string parameter

      -Djboss.modules.dir=C:\Daten\Programme\jboss-as-7.1.1.Final\modules
      

      is missing.

       

      Could that be the problem? If not, how can I find the solution?

       

      Update: If a try to update the module jboss-as-osgi-service-7.1.1.Final.jar which is delivered with jboss 7.1.1 with version jboss-as-osgi-service-7.1.3.Final.jar which does contain class org.jboss.as.osgi.OSGiConstants the following exception is thrown during startup.

       

      16:11:05,137 ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("parallel-extension-add") failed - address: ([]): java.lang.RuntimeException: JBAS014670: Failed initializing module org.jboss.as.osgi
                at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:99) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
                at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
                at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
                at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
                at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:149) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
                at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:190) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
                at org.jboss.as.server.ServerService.boot(ServerService.java:291) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
                at org.jboss.as.server.ServerService.boot(ServerService.java:266) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
                at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
                at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
      Caused by: java.util.concurrent.ExecutionException: java.lang.NoSuchMethodError: org.jboss.as.controller.ExtensionContext.registerSubsystem(Ljava/lang/String;III)Lorg/jboss/as/controller/SubsystemRegistration;
                at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) [rt.jar:1.6.0_37]
                at java.util.concurrent.FutureTask.get(FutureTask.java:83) [rt.jar:1.6.0_37]
                at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:91) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
                ... 9 more
      Caused by: java.lang.NoSuchMethodError: org.jboss.as.controller.ExtensionContext.registerSubsystem(Ljava/lang/String;III)Lorg/jboss/as/controller/SubsystemRegistration;
                at org.jboss.as.osgi.parser.OSGiExtension.initialize(OSGiExtension.java:69)
                at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:88) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
                at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
                at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:113) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
                at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_37]
                at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_37]
                at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
                at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
                at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
      
        • 1. Re: For JPA test ClassNotFoundException: org.jboss.as.osgi.OSGiConstants
          Dominik Grupp Newbie

          I found the cause of the problem: the mere presence of the following part in the main pom is the cause:

           

          <dependencyManagement>
                    <dependency>
                              <groupId>org.jboss.as</groupId>
                              <artifactId>jboss-as-parent</artifactId>
                              <version>7.1.3.Final</version>
                              <type>pom</type>
                              <scope>import</scope>
                    </dependency>
          </dependencyManagement>
          

           

          When

          • that part is removed from the main pom and
          • all dependencies in sub projects whose version had been dependent on jboss-as-parent:7.1.3.Final have been manually versioned to the _same_ version as given in jboss-as-parent:7.1.3.Final

          the problem disappeared.

           

          So there must be something in org.jboss.as:jboss-as-parent:7.1.3.Final which causes a problem. That is strange since that artifact was kept only in the dependencyManagement section.

           

          Did someone else have such a problem and found out what it really was? We'd be much interested in knowing the exact details.