Bug 1416413 - Failed to load module org.modeshape: Unsupported major.minor
Summary: Failed to load module org.modeshape: Unsupported major.minor
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: JBoss Data Virtualization 6
Classification: JBoss
Component: ModeShape
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
: ---
Assignee: Horia Chiorean
QA Contact: Jan Stastny
URL:
Whiteboard:
Depends On:
Blocks: 1393894
TreeView+ depends on / blocked
 
Reported: 2017-01-25 13:00 UTC by Jan Stastny
Modified: 2017-02-20 19:22 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-20 19:22:31 UTC
Type: Support Patch


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker MODE-2647 0 Major Resolved Add readme and .bat script to the jcr rest client kit 2017-02-20 19:19:44 UTC

Description Jan Stastny 2017-01-25 13:00:56 UTC
Description of problem:
DV Server can't be started on JDK 1.6 after applying the patch.

The message:
12:25:00,814 INFO  [org.jboss.as] (MSC service thread 1-6) JBAS015899: JBoss Red Hat JBoss Data Virtualization 6.3.4 (AS 7.5.12.Final-redhat-1) starting
12:25:01,488 WARN  [org.jboss.modules] (ServerService Thread Pool -- 18) Failed to define class org.modeshape.jboss.subsystem.ModeShapeExtension in Module "org.modeshape:main" from local module loader @3d9360e2 (finder: local module finder @16bdb503 (roots: w:\workspace\jdv-6.3.x-smoke-test\6eb0e882\work\modules,w:\workspace\jdv-6.3.x-smoke-test\6eb0e882\work\modules\system\layers\dv,w:\workspace\jdv-6.3.x-smoke-test\6eb0e882\work\modules\system\layers\base\.overlays\layer-base-jboss-eap-6.4.12.CP,w:\workspace\jdv-6.3.x-smoke-test\6eb0e882\work\modules\system\layers\base)): java.lang.UnsupportedClassVersionError: org/modeshape/jboss/subsystem/ModeShapeExtension : Unsupported major.minor version 51.0
         at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_45]
         at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [rt.jar:1.6.0_45]
         at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [rt.jar:1.6.0_45]
         at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.Module.loadModuleClass(Module.java:568) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:447) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:414) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at java.lang.Class.forName0(Native Method) [rt.jar:1.6.0_45]
         at java.lang.Class.forName(Class.java:249) [rt.jar:1.6.0_45]
         at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:346) [rt.jar:1.6.0_45]
         at java.util.ServiceLoader$1.next(ServiceLoader.java:428) [rt.jar:1.6.0_45]
         at org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:179) [jboss-as-controller-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         at org.jboss.as.controller.parsing.ExtensionXml.access$000(ExtensionXml.java:68) [jboss-as-controller-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:126) [jboss-as-controller-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:123) [jboss-as-controller-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_45]
         at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_45]
         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
         at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]

12:25:01,510 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
         at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:141) [jboss-as-controller-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         at org.jboss.as.server.ServerService.boot(ServerService.java:338) [jboss-as-server-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [jboss-as-controller-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
Caused by: javax.xml.stream.XMLStreamException: JBAS014674: Failed to load module org.modeshape
         at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:154) [jboss-as-controller-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:435) [jboss-as-server-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [jboss-as-server-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [jboss-as-server-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final-redhat-3.jar:1.1.0.Final-redhat-3]
         at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final-redhat-3.jar:1.1.0.Final-redhat-3]
         at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:133) [jboss-as-controller-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         ... 3 more
Caused by: java.util.concurrent.ExecutionException: java.lang.UnsupportedClassVersionError: org/modeshape/jboss/subsystem/ModeShapeExtension : Unsupported major.minor version 51.0
         at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) [rt.jar:1.6.0_45]
         at java.util.concurrent.FutureTask.get(FutureTask.java:83) [rt.jar:1.6.0_45]
         at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:146) [jboss-as-controller-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         ... 9 more
Caused by: java.lang.UnsupportedClassVersionError: org/modeshape/jboss/subsystem/ModeShapeExtension : Unsupported major.minor version 51.0
         at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_45]
         at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [rt.jar:1.6.0_45]
         at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [rt.jar:1.6.0_45]
         at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.Module.loadModuleClass(Module.java:568) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:447) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:414) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.7.Final-redhat-1]
         at java.lang.Class.forName0(Native Method) [rt.jar:1.6.0_45]
         at java.lang.Class.forName(Class.java:249) [rt.jar:1.6.0_45]
         at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:346) [rt.jar:1.6.0_45]
         at java.util.ServiceLoader$1.next(ServiceLoader.java:428) [rt.jar:1.6.0_45]
         at org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:179) [jboss-as-controller-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         at org.jboss.as.controller.parsing.ExtensionXml.access$000(ExtensionXml.java:68) [jboss-as-controller-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:126) [jboss-as-controller-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:123) [jboss-as-controller-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_45]
         at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_45]
         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
         at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]

Comment 1 Horia Chiorean 2017-01-25 13:21:08 UTC
This is bug that creeped in with https://issues.jboss.org/browse/MODE-2647 as I forgot that the source code has to be JDK 1.6 compatible and added a test case which uses JDK 1.7

So I'll fix this in the product branch and re-tag to JDV 6.3.4

Comment 2 Horia Chiorean 2017-01-25 13:41:24 UTC
Created a new tag for JDV 6.3.4 - 3.8.x-prod-ip6.3-update4_3 - which fixes the issue.

Comment 3 Jan 2017-01-25 16:05:06 UTC
Tag acknowledged, I will put the trakcer bug to MODIFIED and start working on DV 6.3.4 CR2

Comment 4 Alex Szczuczko 2017-01-25 22:11:16 UTC
We've found that maven now tries to compile the test for modeshape-client with a source/target of 1.6, which seems to defy the definition of 1.7 in the plugin execution. Obviously, since try-with-resources syntax is being used in the test, javac fails to compile the test.

There seems to be some IPBOM/jboss-parent weirdness happening, where the productised version (14.0.0.redhat-1) defines the compilerArgs configuration value to be -source 1.6 -target 1.6, whereas the community version (16) defines the same to be -source 1.7 -target 1.7. This overrides the regular definition of source and target in maven-compiler-plugin's configuration.

Normally I would just disable the test, but it seems that you really want this one to run Horia?

Our options, assuming keeping the test, are to either alter the test such that it uses 1.6 syntax, or to change the pom such that it overrides compilerArgs. The pom change can either be done as a productization patch or a change on your side Horia (and you give us a new tag).

Comment 5 Horia Chiorean 2017-01-26 07:17:33 UTC
(In reply to Alex Szczuczko from comment #4)
> We've found that maven now tries to compile the test for modeshape-client
> with a source/target of 1.6, which seems to defy the definition of 1.7 in
> the plugin execution. Obviously, since try-with-resources syntax is being
> used in the test, javac fails to compile the test.
> 

I'm not sure I follow: ModeShape's build uses the maven.compiler.target/source values coming from the IP-BOM which is 1.6 (it never overwrites these values)

Test wise, with the exception of the modeshape-client module, the same properties should be used (meaning JDK 6 compatibility). 

modeshape-client uses JDK7 (and relies on JDK7 features which are no available in JDK6). Therefore, I've explicitly made the change in this commit https://github.com/jboss-integration/modeshape/commit/c6bf9d9dcf7f3a816cb43e99eb799135544a23b3 so that only the maven-compiler testSource and testTarget properties are changed to 1.7. Note that this does not have any effect on the maven.compiler.target/source properties.


So, considering that:
* tests are not distributed to customers
* the JDK version for compiling main artifacts is 1.6

I don't see any reason why the tests can't use Java 7.

If the build is ran with Java 7 and above, everything should work as expected (this is what I've tested locally)

If the build is ran with Java 6, then using -Dmaven.test.skip=true instead of -DskipTests should make sure that the testCompile phase is not executed at all which should also work

Note that the tag handoff report mentions Java 7 being required, not 6.

Comment 6 Horia Chiorean 2017-01-26 08:34:48 UTC
>Normally I would just disable the test, but it seems that you really want this one to run Horia?

I would like to run this locally because it validates that the rest script(s) are working fine.

>Our options, assuming keeping the test, are to either alter the test such that it uses 1.6 syntax, or to change the pom such that it overrides compilerArgs. The pom change can either be done as a productization patch or a change on your side Horia (and you give us a new tag).

Using 1.6 syntax is not possible, since it requires specific API changes around the JDK's java.lang.ProcessBuilder present only in 7 and above.

As I tried to explain above, I don't really get why Maven would not be honoring the testSource and testTarget compiler properties; but in any case I would prefer disabling this test via a productizaton patch rather than removing it from the codebase altogether

Comment 7 Alex Szczuczko 2017-01-26 15:39:16 UTC
In maven debug mode we discovered that for the [maven-compiler-plugin:3.1:testCompile (test-compile) @ modeshape-client] execution:

The configuration values were (...'s added by me for brevity):

    basedir = /mnt/.../build/modeshape-client
    buildDirectory = /mnt/.../modeshape-client/target
    classpathElements = [ ... ]
    compileSourceRoots = [/mnt/.../modeshape-client/src/test/java]
    compilerArguments = {source=1.6, target=1.6}
    compilerId = javac
    debug = true
    encoding = UTF-8
    failOnError = true
    forceJavacCompilerUse = false
    fork = false
    generatedTestSourcesDirectory = /mnt/.../modeshape-client/target/generated-test-sources/test-annotations
    mojoExecution = org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile {execution: test-compile}
    optimize = false
    outputDirectory = /mnt/.../modeshape-client/target/test-classes
    showDeprecation = false
    showWarnings = false
    skipMultiThreadWarning = false
    source = 1.6
    staleMillis = 0
    target = 1.6
    testSource = 1.7
    testTarget = 1.7
    useIncrementalCompilation = true
    verbose = false
    mavenSession = org.apache.maven.execution.MavenSession@3da0fca3
    session = org.apache.maven.execution.MavenSession@3da0fca3

Which resulted in a javac command line of:

    javac -d ... -classpath ... -sourcepath ... -s ... -g -nowarn -target 1.7 -source 1.7 -encoding UTF-8 -source 1.6 -target 1.6

We initially thought the extra source/target on the end might be set by the source/target configuration values. However, when we tried setting them to 1.7 as well, that didn't change the javac command line. The compilerArguments setting is the only other place 1.6 occurs in the configuration.

So, the values for testSource/testTarget were being received and applied, but the compilerArguments setting (which allows arbitrary String=String definition of arguments) has been defined elsewhere to be "-source 1.6 -target 1.6", and since it gets added last to the command line, the values of testSource/testTarget are overridden.

Tracing back through the multiple levels of parents, I think compilerArguments is set by jboss-parent:

    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>${version.compiler.plugin}</version>
    <configuration>
        <showDeprecation>true</showDeprecation>
        <showWarnings>true</showWarnings>
        <compilerArguments>
            <source>${maven.compiler.argument.source}</source>
            <target>${maven.compiler.argument.target}</target>
        </compilerArguments>
    </configuration>

Note that:

    maven.compiler.argument.source
    maven.compiler.argument.target

are not identical to:

    maven.compiler.source
    maven.compiler.target

They are not standard maven-compiler-plugin properties. In jboss-parent 16 (used by IPBOM), both properties are set to 1.7. In jboss-parent 14.0.0.redhat-1 (used by jboss-as-parent), both properties are set to 1.6.

So, something happens in the alignment phase, and we end up with compilerArguments set to 1.6, which overrides anything. Possibly this was by design, or maybe whenever jboss-parent was written the discrete source/target configuration values didn't exist?

Either way, I think we will have to keep a patch for this in prod. I think that patch can just change the pom (re-define compilerArguments for test-compile @ modeshape-client), so that the test will keep functioning.

Comment 8 Horia Chiorean 2017-01-26 15:56:51 UTC
That's highly "interesting" in the sense that all these params manage to confuse the compiler.

Looking locally at 
jboss-parent(19)-jboss-integration-platform-parent(6.0.0.Final)-modeshape-parent

the values are:

jboss-parent(19)
----------------
<!-- maven-compiler-plugin -->
<maven.compiler.target>1.7</maven.compiler.target>
<maven.compiler.source>1.7</maven.compiler.source>

<maven.compiler.argument.target>${maven.compiler.target}</maven.compiler.argument.target>
<maven.compiler.argument.source>${maven.compiler.source}</maven.compiler.argument.source>

jboss-integration-platform-parent(6.0.0.Final)
-----------------------------------------------
<!-- Override Java source/target to be 1.6 -->
<maven.compiler.target>1.6</maven.compiler.target>
<maven.compiler.source>1.6</maven.compiler.source>

Actually I think I might like to take a look locally at this some more, check if I can force the compiler to correctly use the source and target

@Alex if you're ok with waiting until tomorrow, I can update this issue and perhaps submit a new tag if I can fix this in the ModeShape build

Comment 9 Horia Chiorean 2017-01-26 16:45:56 UTC
submitted 3.8.x-prod-ip6.3-update4_4 which is the last-ditch effort at this: I've overwritten the entire source and target but only of the default-testCompile execution and the module is not using the testSource and testTarget attributes anymore

Hopefully this fixes the duplicate -source -target arguments from above

Comment 10 Horia Chiorean 2017-01-26 17:00:01 UTC
not to mention test compiling should be skipped altogether when running -DskipTests

Comment 11 Jan 2017-01-26 19:32:19 UTC
Acknowledged this last patch. Starting build.


Note You need to log in before you can comment on or make changes to this bug.