Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3.0
    • Fix Version/s: 2.3.0
    • Component/s: Enhance
    • Labels:
      None

      Description

      OpenJPA currently has a dependency on ASM 3.2 for some post-enhancement processing to fix up the stack map tables (Java 7 requirement). The latest release of ASM is 4.1, which just came out last week. The immediate need is to move up to ASM 4.0. We can entertain 4.1 at a later date.

        Issue Links

          Activity

          Hide
          ASF subversion and git services added a comment -

          Commit 1532523 from Rick Curtis in branch 'openjpa/trunk'
          [ https://svn.apache.org/r1532523 ]

          OPENJPA-2283 : Merge changes from 2.3.x to trunk.

          Show
          ASF subversion and git services added a comment - Commit 1532523 from Rick Curtis in branch 'openjpa/trunk' [ https://svn.apache.org/r1532523 ] OPENJPA-2283 : Merge changes from 2.3.x to trunk.
          Hide
          ASF subversion and git services added a comment -

          Commit 1532519 from Rick Curtis in branch 'openjpa/branches/2.3.x'
          [ https://svn.apache.org/r1532519 ]

          OPENJPA-2283: Seperate test/runtime source/target levels in root pom.xml

          Show
          ASF subversion and git services added a comment - Commit 1532519 from Rick Curtis in branch 'openjpa/branches/2.3.x' [ https://svn.apache.org/r1532519 ] OPENJPA-2283 : Seperate test/runtime source/target levels in root pom.xml
          Hide
          Kevin Sutter added a comment -

          Mark, It looks like there are multiple conversations going on between openjpa-2171 and this JIRA... Sorry about that. I just noticed the code changes come across this JIRA, so I commented here...

          Thinking through this a bit more, I see your point. Whether we have a dependency on ASM or the xbean version of ASM, it really shouldn't make a difference. And, from a WebSphere perspective, they can provide an xbean dependency as well as an ASM dependency. So, let's do what's right for OpenJPA and move forward. Thanks for your patience (and perseverance).

          Show
          Kevin Sutter added a comment - Mark, It looks like there are multiple conversations going on between openjpa-2171 and this JIRA... Sorry about that. I just noticed the code changes come across this JIRA, so I commented here... Thinking through this a bit more, I see your point. Whether we have a dependency on ASM or the xbean version of ASM, it really shouldn't make a difference. And, from a WebSphere perspective, they can provide an xbean dependency as well as an ASM dependency. So, let's do what's right for OpenJPA and move forward. Thanks for your patience (and perseverance).
          Hide
          Mark Struberg added a comment -

          Tell me where the difference is between having a direct dependency to a badly maintained version of asm jars which are NOT binary compatible with each other vs having an Apache internal xbean-asm4-shaded which we maintain over at the Geronimo project?
          There is a good reason why OpenWebBeans, OpenEJB, a few other Apache projects plus Spring, etc dropped the direct ASM dependency already...

          Show
          Mark Struberg added a comment - Tell me where the difference is between having a direct dependency to a badly maintained version of asm jars which are NOT binary compatible with each other vs having an Apache internal xbean-asm4-shaded which we maintain over at the Geronimo project? There is a good reason why OpenWebBeans, OpenEJB, a few other Apache projects plus Spring, etc dropped the direct ASM dependency already...
          Hide
          Kevin Sutter added a comment -

          Mark,
          This change puts a direct dependency on the xbean version of asm:

          import org.apache.xbean.asm4.ClassReader;
          import org.apache.xbean.asm4.ClassWriter;

          We can't do that. We need OpenJPA to stay independent of these type of shaded asm versions. This type of change now requires any user of OpenJPA (including WebSphere) to also ship a version of the xbean shaded jar. I don't agree with this change.

          Show
          Kevin Sutter added a comment - Mark, This change puts a direct dependency on the xbean version of asm: import org.apache.xbean.asm4.ClassReader; import org.apache.xbean.asm4.ClassWriter; We can't do that. We need OpenJPA to stay independent of these type of shaded asm versions. This type of change now requires any user of OpenJPA (including WebSphere) to also ship a version of the xbean shaded jar. I don't agree with this change.
          Hide
          ASF subversion and git services added a comment -

          Commit 1530808 from Mark Struberg in branch 'openjpa/branches/2.3.x'
          [ https://svn.apache.org/r1530808 ]

          OPENJPA-2283 use xbean-asm4-shaded ASM version as the dynamic handling doesn't work out

          This makes sure we always have a guaranteed ASM version 4 regardless what ASM a
          user might add to the project. This also rolls back the dynamic ASM handling of
          OPENJPA-2171.

          Show
          ASF subversion and git services added a comment - Commit 1530808 from Mark Struberg in branch 'openjpa/branches/2.3.x' [ https://svn.apache.org/r1530808 ] OPENJPA-2283 use xbean-asm4-shaded ASM version as the dynamic handling doesn't work out This makes sure we always have a guaranteed ASM version 4 regardless what ASM a user might add to the project. This also rolls back the dynamic ASM handling of OPENJPA-2171 .
          Hide
          Mark Struberg added a comment -

          This looks like a pretty heavy bug in ASM so far.

          ClassWriter#getCommonSuperClass always only takes the own ClassLoader.
          I thought this has been fixed in ASM-4 but got proven wrong.

          The original code have had a hack by overwriting this method and providing an own ClassLoader for this operation. This is not really possible anymore with the dynamic approach as there is no fixed class we can extend. This would only be possible with ASM which is kind of a chicken-egg problem now.

          I suggest to code against xbean-asm4-shaded instead of ASM directly. This has the benefit that we at least know which exact version we have - without trashing other project or getting trashed by customer dependencies.

          Show
          Mark Struberg added a comment - This looks like a pretty heavy bug in ASM so far. ClassWriter#getCommonSuperClass always only takes the own ClassLoader. I thought this has been fixed in ASM-4 but got proven wrong. The original code have had a hack by overwriting this method and providing an own ClassLoader for this operation. This is not really possible anymore with the dynamic approach as there is no fixed class we can extend. This would only be possible with ASM which is kind of a chicken-egg problem now. I suggest to code against xbean-asm4-shaded instead of ASM directly. This has the benefit that we at least know which exact version we have - without trashing other project or getting trashed by customer dependencies.
          Hide
          Mark Struberg added a comment -

          Kevin Sutter oki, gonna fix the ordering to xbean-asm4, xbean-asm3, spring-asm, asm-native

          Rick Curtis I think the wrong ClassLoader comes from the fact that the input class byte array comes from the BCClass instance in the PCEnhancer. So you will most probably always get the ClassLoader which loads OpenJPA itself. But this is wrong for nested ClassLoaders. We need the ClassLoader from the Class which gets enhanced at all.
          Please note that this will most probably only have an impact if the enhancement gets done at runtime. Doing further debugging atm and try to create a unit test.

          Gonna fix this in 2.3.x and trunk.

          Show
          Mark Struberg added a comment - Kevin Sutter oki, gonna fix the ordering to xbean-asm4, xbean-asm3, spring-asm, asm-native Rick Curtis I think the wrong ClassLoader comes from the fact that the input class byte array comes from the BCClass instance in the PCEnhancer. So you will most probably always get the ClassLoader which loads OpenJPA itself. But this is wrong for nested ClassLoaders. We need the ClassLoader from the Class which gets enhanced at all. Please note that this will most probably only have an impact if the enhancement gets done at runtime. Doing further debugging atm and try to create a unit test. Gonna fix this in 2.3.x and trunk.
          Hide
          Kevin Sutter added a comment -

          Mark, okay, I give... I just talked with Rick and he convinced me this was okay. I have always struggled with this change since I was wondering why would we (OpenJPA) be checking for these alternate packages, when we don't have a direct dependency on them. But, this is for application server environments like you said. Environments where there might be multiple versions of ASM (both app server and application), and OpenJPA needs to use the "right one". In OpenJPA's premier app server (WebSphere), we can determine which ASM to use based on the classloader "magic". But, that ability is not always available in every environment. So, I'm good with this ordering change.

          But, since we're re-looking at this change due to the ASM 4 upgrade, should the xbean-asm4 be first in the list? I know that differs from my earlier comment, but now that I understand why you want the xbean shaded jars first, it would seem logical to have xbean-asm4 first.

          Show
          Kevin Sutter added a comment - Mark, okay, I give... I just talked with Rick and he convinced me this was okay. I have always struggled with this change since I was wondering why would we (OpenJPA) be checking for these alternate packages, when we don't have a direct dependency on them. But, this is for application server environments like you said. Environments where there might be multiple versions of ASM (both app server and application), and OpenJPA needs to use the "right one". In OpenJPA's premier app server (WebSphere), we can determine which ASM to use based on the classloader "magic". But, that ability is not always available in every environment. So, I'm good with this ordering change. But, since we're re-looking at this change due to the ASM 4 upgrade, should the xbean-asm4 be first in the list? I know that differs from my earlier comment, but now that I understand why you want the xbean shaded jars first, it would seem logical to have xbean-asm4 first.
          Hide
          Mark Struberg added a comment -

          Kevin, if you take org.objectweb.asm as default, then you risk to get into deep troubles. There was a reason that there is a shaded version of asm used in OpenEJB, Geronimo, OpenWebBeans, Spring, etc. All those projects basically got to a point where they were broken sometimes because they use plain ASM.

          The reason is that ASM folks changed their API over time and introduced backward incompatibilities. But they didn't change the package names.
          So whenever a custom WAR or EAR deployed in the container of your choice brings an own ASM version, then you can never be sure that it is compatible with OpenJPA! And I really don't like to render OpenJPA useless only because some customer projects bring an old ASM version as dependency.

          Of course, I can see your point with ASM3 as primary target, thus I'd suggest to set the ordering as following:

          1. xbean-asm3
          2. xbean-asm4
          3. asm-spring
          4. asm native
          Show
          Mark Struberg added a comment - Kevin, if you take org.objectweb.asm as default, then you risk to get into deep troubles. There was a reason that there is a shaded version of asm used in OpenEJB, Geronimo, OpenWebBeans, Spring, etc. All those projects basically got to a point where they were broken sometimes because they use plain ASM. The reason is that ASM folks changed their API over time and introduced backward incompatibilities. But they didn't change the package names. So whenever a custom WAR or EAR deployed in the container of your choice brings an own ASM version, then you can never be sure that it is compatible with OpenJPA! And I really don't like to render OpenJPA useless only because some customer projects bring an old ASM version as dependency. Of course, I can see your point with ASM3 as primary target, thus I'd suggest to set the ordering as following: xbean-asm3 xbean-asm4 asm-spring asm native
          Hide
          Kevin Sutter added a comment -

          I still don't agree with the change in ordering. We define our specific dependencies via the pom. Right now, we require ASM 3.2. We're looking to upgrade that to 4.0 or 4.1. Our code should be treating the "real" ASM as our preferred choice, not some shaded version provided by another project. A project that we have no dependencies on.

          Show
          Kevin Sutter added a comment - I still don't agree with the change in ordering. We define our specific dependencies via the pom. Right now, we require ASM 3.2. We're looking to upgrade that to 4.0 or 4.1. Our code should be treating the "real" ASM as our preferred choice, not some shaded version provided by another project. A project that we have no dependencies on.
          Hide
          Rick Curtis added a comment -

          Running with java7 –

          .../openjpa-parent> mvn clean install

          It should blow up while enhancing openjpa-persistence-jdbc.

          Show
          Rick Curtis added a comment - Running with java7 – .../openjpa-parent> mvn clean install It should blow up while enhancing openjpa-persistence-jdbc.
          Hide
          Romain Manni-Bucau added a comment -

          @Rick: how to reproduce it?

          Show
          Romain Manni-Bucau added a comment - @Rick: how to reproduce it?
          Hide
          Mark Struberg added a comment -

          Rick, are you able to provide a small test?

          Show
          Mark Struberg added a comment - Rick, are you able to provide a small test?
          Hide
          Rick Curtis added a comment -

          Hey Romain –

          Your proposed change doesn't fix my problem...my guess is that the problem is somehow related to :

          // ClassWriter.getCommonSuperClass uses TCCL
          Thread.currentThread().setContextClassLoader(bc.getClassLoader());

          Show
          Rick Curtis added a comment - Hey Romain – Your proposed change doesn't fix my problem...my guess is that the problem is somehow related to : // ClassWriter.getCommonSuperClass uses TCCL Thread.currentThread().setContextClassLoader(bc.getClassLoader());
          Hide
          Mark Struberg added a comment -

          to make this more clear: for now we let the reflection stuff as is, but we only change the lookup order to check for xbean-asm4 first, then the rest.

          tryClass("org.apache.xbean.asm4.");
          tryClass("org.apache.xbean.asm.");
          tryClass("org.objectweb.asm.");
          tryClass("org.springframework.asm.");
          

          The argument is that we know that xbean-asm4 is perfect, xbean-asm3 is still good enough, but org.objectweb.asm could even be ASM-2 and older. So if anyone ships his webapp with ASM-2 as dependency, we still would take xbean-asm4 if available (e.g. in Geronimo or TomEE).

          Show
          Mark Struberg added a comment - to make this more clear: for now we let the reflection stuff as is, but we only change the lookup order to check for xbean-asm4 first, then the rest. tryClass( "org.apache.xbean.asm4." ); tryClass( "org.apache.xbean.asm." ); tryClass( "org.objectweb.asm." ); tryClass( "org.springframework.asm." ); The argument is that we know that xbean-asm4 is perfect, xbean-asm3 is still good enough, but org.objectweb.asm could even be ASM-2 and older. So if anyone ships his webapp with ASM-2 as dependency, we still would take xbean-asm4 if available (e.g. in Geronimo or TomEE).
          Hide
          Romain Manni-Bucau added a comment -

          just talked with Mark on IRC about it, since openjpa depends on asm java 7 features and tomee doesn't care about xbean-asm4 in the apps we can test xbean-asm4 first and avoid issues this way. so changing my -1 in +1 (sorry for the noise)

          Show
          Romain Manni-Bucau added a comment - just talked with Mark on IRC about it, since openjpa depends on asm java 7 features and tomee doesn't care about xbean-asm4 in the apps we can test xbean-asm4 first and avoid issues this way. so changing my -1 in +1 (sorry for the noise)
          Hide
          Romain Manni-Bucau added a comment -

          PS: i just tested with asm 4.1 as dependency and openjpa-persistence-jdbc tests are passing.

          Show
          Romain Manni-Bucau added a comment - PS: i just tested with asm 4.1 as dependency and openjpa-persistence-jdbc tests are passing.
          Hide
          Kevin Sutter added a comment -

          I agree with Romain – no change to the asm dependency itself.

          Show
          Kevin Sutter added a comment - I agree with Romain – no change to the asm dependency itself.
          Hide
          Romain Manni-Bucau added a comment -

          If openjpa switch to xbean-asm4 we'd need to support a tomee-asm (not exiting today) since openjpa can be provided in webapps and we don't want to conflict with it (why xbean-asm was created). So ok to change the order, -1 to depend explicitely on the shade.

          Show
          Romain Manni-Bucau added a comment - If openjpa switch to xbean-asm4 we'd need to support a tomee-asm (not exiting today) since openjpa can be provided in webapps and we don't want to conflict with it (why xbean-asm was created). So ok to change the order, -1 to depend explicitely on the shade.
          Hide
          Mark Struberg added a comment - - edited

          +1
          but we should change the lookup order as we don't know whether the 'native' ASM stuff is 'good enough' for us (means ASM3++).

          As alternative, we might also think about forcing the dependency to xbean-asm4.
          I would actually even prefer this to the other options. once there is a non compat change in asm, the xbean team will shade to a different package again. Thus xbean-asm4 can co-exist beside any other ASM version without interference.

          Show
          Mark Struberg added a comment - - edited +1 but we should change the lookup order as we don't know whether the 'native' ASM stuff is 'good enough' for us (means ASM3++). As alternative, we might also think about forcing the dependency to xbean-asm4. I would actually even prefer this to the other options. once there is a non compat change in asm, the xbean team will shade to a different package again. Thus xbean-asm4 can co-exist beside any other ASM version without interference.
          Hide
          Romain Manni-Bucau added a comment - - edited

          Can't it be fixed with:

          static {
                  // try the "real" asm first, then the others
                  tryClass("org.objectweb.asm.");
                  tryClass("org.apache.xbean.asm4.");
                  tryClass("org.apache.xbean.asm.");
                  tryClass("org.springframework.asm.");
          
                  // get needed stuff
                  try {
                      COMPUTE_FRAMES = cwClass.getField("COMPUTE_FRAMES").getInt(null);
                      classReaderAccept = crClass.getMethod("accept", findClassVisitor(), int.class);
                      classReaderConstructor = crClass.getConstructor(InputStream.class);
                      classWriterConstructor = cwClass.getConstructor(int.class);
                      classWritertoByteArray = cwClass.getMethod("toByteArray");
                  } catch (Exception e) {
                      throw new IllegalStateException(_loc.get("static-asm-exception").getMessage(), e);
                  }
              }
          
              private static Class<?> findClassVisitor() throws ClassNotFoundException {
                  final String cwName = cwClass.getName();
                  return cwClass.getClassLoader().loadClass(cwName.substring(0, cwName.length() - "ClassWriter".length()) + "ClassVisitor");
              }
          
          Show
          Romain Manni-Bucau added a comment - - edited Can't it be fixed with: static { // try the "real" asm first, then the others tryClass( "org.objectweb.asm." ); tryClass( "org.apache.xbean.asm4." ); tryClass( "org.apache.xbean.asm." ); tryClass( "org.springframework.asm." ); // get needed stuff try { COMPUTE_FRAMES = cwClass.getField( "COMPUTE_FRAMES" ).getInt( null ); classReaderAccept = crClass.getMethod( "accept" , findClassVisitor(), int .class); classReaderConstructor = crClass.getConstructor(InputStream.class); classWriterConstructor = cwClass.getConstructor( int .class); classWritertoByteArray = cwClass.getMethod( "toByteArray" ); } catch (Exception e) { throw new IllegalStateException(_loc.get( " static -asm-exception" ).getMessage(), e); } } private static Class <?> findClassVisitor() throws ClassNotFoundException { final String cwName = cwClass.getName(); return cwClass.getClassLoader().loadClass(cwName.substring(0, cwName.length() - "ClassWriter" .length()) + "ClassVisitor" ); }
          Hide
          Kevin Sutter added a comment -

          As mentioned above, I'm having some problems with the changes submitted for making ASM optional (OpenJPA-2171)... I'm trying to upgrade OpenJPA trunk to use ASM 4.0. I got by the "easy" problem when reflectively finding the accept() method [1]. But, after making that change, I am getting a strange error [2] when our enhancement process is working on CacheTest.class in our JUnit bucket. This error doesn't happen with all of the other enhancement processing that happens before this one. I have no idea if other classes would also fail later in the bucket since it never gets that far.

          If I replace AsmAdapter.java with the previous version (pre-OpenJPA-2171), then everything works just fine. Thoughts or suggestions? Since the move to ASM 4.0 is important, I'd like to do something that's compatible with these OpenJPA-2171 changes. But, if I can't figure something out quickly, I might have to re-open that JIRA and back out the changes to make progress on ASM 4.0. Thanks!

          [1] classReaderAccept = crClass.getMethod("accept", cwClass.getSuperclass(), int.class);
          [2]
          18450 xml-persistence-unit INFO [main] openjpa.Tool - Enhancer running on type "class org.apache.openjpa.persistence.datacache.CacheTest".
          java.io.IOException: java.lang.reflect.InvocationTargetException
          at org.apache.openjpa.enhance.AsmAdaptor.toJava7ByteArray(AsmAdaptor.java:156)
          at org.apache.openjpa.enhance.AsmAdaptor.writeJava7(AsmAdaptor.java:137)
          at org.apache.openjpa.enhance.AsmAdaptor.write(AsmAdaptor.java:107)
          at org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:633)
          at org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:619)
          at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4899)
          at org.apache.openjpa.ant.PCEnhancerTask.executeOn(PCEnhancerTask.java:89)
          at org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:171)
          at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
          at java.lang.reflect.Method.invoke(Method.java:613)
          at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
          at org.apache.tools.ant.Task.perform(Task.java:348)
          at org.apache.tools.ant.Target.execute(Target.java:357)
          at org.apache.tools.ant.Target.performTasks(Target.java:385)
          at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
          at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
          at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
          at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:416)
          at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
          at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
          at java.lang.reflect.Method.invoke(Method.java:613)
          at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
          at org.apache.tools.ant.Task.perform(Task.java:348)
          at org.apache.tools.ant.Target.execute(Target.java:357)
          at org.apache.tools.ant.Target.performTasks(Target.java:385)
          at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
          at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
          at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
          at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:416)
          at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
          at java.lang.reflect.Method.invoke(Method.java:613)
          at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
          at org.apache.tools.ant.Task.perform(Task.java:348)
          at org.apache.tools.ant.Target.execute(Target.java:357)
          at org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:118)
          at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:98)
          at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
          at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
          at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
          at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
          at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
          at java.lang.reflect.Method.invoke(Method.java:613)
          at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
          at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
          at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
          at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
          Caused by: java.lang.reflect.InvocationTargetException
          at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
          at java.lang.reflect.Method.invoke(Method.java:613)
          at org.apache.openjpa.enhance.AsmAdaptor.toJava7ByteArray(AsmAdaptor.java:152)
          ... 63 more
          Caused by: java.lang.ClassFormatError: JVMCFRE113 unexpected EOF; class=org/apache/openjpa/persistence/datacache/CacheTest, offset=0
          at java.lang.ClassLoader.defineClassImpl(Native Method)
          at java.lang.ClassLoader.defineClass(ClassLoader.java:286)
          at org.apache.tools.ant.AntClassLoader.defineClassFromData(AntClassLoader.java:1146)
          at org.apache.tools.ant.AntClassLoader.getClassFromStream(AntClassLoader.java:1324)
          at org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1388)
          at org.apache.tools.ant.AntClassLoader.findClass(AntClassLoader.java:1341)
          at org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:1088)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:660)
          at java.lang.ClassLoader.defineClassImpl(Native Method)
          at java.lang.ClassLoader.defineClass(ClassLoader.java:286)
          at org.apache.tools.ant.AntClassLoader.defineClassFromData(AntClassLoader.java:1146)
          at org.apache.tools.ant.AntClassLoader.getClassFromStream(AntClassLoader.java:1324)
          at org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1388)
          at org.apache.tools.ant.AntClassLoader.findClass(AntClassLoader.java:1341)
          at org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:1088)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:660)
          at java.lang.Class.forNameImpl(Native Method)
          at java.lang.Class.forName(Class.java:176)
          at org.objectweb.asm.ClassWriter.getCommonSuperClass(Unknown Source)
          at org.objectweb.asm.ClassWriter.a(Unknown Source)
          at org.objectweb.asm.Frame.a(Unknown Source)
          at org.objectweb.asm.Frame.a(Unknown Source)
          at org.objectweb.asm.MethodWriter.visitMaxs(Unknown Source)
          at org.objectweb.asm.ClassReader.accept(Unknown Source)
          at org.objectweb.asm.ClassReader.accept(Unknown Source)
          ... 67 more
          [INFO] ------------------------------------------------------------------------

          Show
          Kevin Sutter added a comment - As mentioned above, I'm having some problems with the changes submitted for making ASM optional (OpenJPA-2171)... I'm trying to upgrade OpenJPA trunk to use ASM 4.0. I got by the "easy" problem when reflectively finding the accept() method [1] . But, after making that change, I am getting a strange error [2] when our enhancement process is working on CacheTest.class in our JUnit bucket. This error doesn't happen with all of the other enhancement processing that happens before this one. I have no idea if other classes would also fail later in the bucket since it never gets that far. If I replace AsmAdapter.java with the previous version (pre-OpenJPA-2171), then everything works just fine. Thoughts or suggestions? Since the move to ASM 4.0 is important, I'd like to do something that's compatible with these OpenJPA-2171 changes. But, if I can't figure something out quickly, I might have to re-open that JIRA and back out the changes to make progress on ASM 4.0. Thanks! [1] classReaderAccept = crClass.getMethod("accept", cwClass.getSuperclass(), int.class); [2] 18450 xml-persistence-unit INFO [main] openjpa.Tool - Enhancer running on type "class org.apache.openjpa.persistence.datacache.CacheTest". java.io.IOException: java.lang.reflect.InvocationTargetException at org.apache.openjpa.enhance.AsmAdaptor.toJava7ByteArray(AsmAdaptor.java:156) at org.apache.openjpa.enhance.AsmAdaptor.writeJava7(AsmAdaptor.java:137) at org.apache.openjpa.enhance.AsmAdaptor.write(AsmAdaptor.java:107) at org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:633) at org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:619) at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4899) at org.apache.openjpa.ant.PCEnhancerTask.executeOn(PCEnhancerTask.java:89) at org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:171) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:613) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1189) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:416) at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:613) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1189) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:416) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:613) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:118) at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:98) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:613) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:613) at org.apache.openjpa.enhance.AsmAdaptor.toJava7ByteArray(AsmAdaptor.java:152) ... 63 more Caused by: java.lang.ClassFormatError: JVMCFRE113 unexpected EOF; class=org/apache/openjpa/persistence/datacache/CacheTest, offset=0 at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:286) at org.apache.tools.ant.AntClassLoader.defineClassFromData(AntClassLoader.java:1146) at org.apache.tools.ant.AntClassLoader.getClassFromStream(AntClassLoader.java:1324) at org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1388) at org.apache.tools.ant.AntClassLoader.findClass(AntClassLoader.java:1341) at org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:1088) at java.lang.ClassLoader.loadClass(ClassLoader.java:660) at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:286) at org.apache.tools.ant.AntClassLoader.defineClassFromData(AntClassLoader.java:1146) at org.apache.tools.ant.AntClassLoader.getClassFromStream(AntClassLoader.java:1324) at org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1388) at org.apache.tools.ant.AntClassLoader.findClass(AntClassLoader.java:1341) at org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:1088) at java.lang.ClassLoader.loadClass(ClassLoader.java:660) at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:176) at org.objectweb.asm.ClassWriter.getCommonSuperClass(Unknown Source) at org.objectweb.asm.ClassWriter.a(Unknown Source) at org.objectweb.asm.Frame.a(Unknown Source) at org.objectweb.asm.Frame.a(Unknown Source) at org.objectweb.asm.MethodWriter.visitMaxs(Unknown Source) at org.objectweb.asm.ClassReader.accept(Unknown Source) at org.objectweb.asm.ClassReader.accept(Unknown Source) ... 67 more [INFO] ------------------------------------------------------------------------
          Hide
          Kevin Sutter added a comment -

          As usual, these type of updates are not as easy as first envisioned... The changes that were put in for OpenJPA-2171 are causing some issues. The first one is due to the fact that ASM 4.0 changed the ClassVisitor from an Interface to an Abstract Class. This affects the reflective signature for the ClassReader.accept method. That issue was pretty easy to resolve. But, now I'm hitting some problems while our JUnit bucket attempts to enhance the various classes, specifically the CacheTest.java class. I'm trying to narrow this one down, but it's taking more time than I expected. May need some assistance with this since it seems directly related to the changes introduced by OpenJPA-2171, and personally I'm skeptical about those changes...

          Show
          Kevin Sutter added a comment - As usual, these type of updates are not as easy as first envisioned... The changes that were put in for OpenJPA-2171 are causing some issues. The first one is due to the fact that ASM 4.0 changed the ClassVisitor from an Interface to an Abstract Class. This affects the reflective signature for the ClassReader.accept method. That issue was pretty easy to resolve. But, now I'm hitting some problems while our JUnit bucket attempts to enhance the various classes, specifically the CacheTest.java class. I'm trying to narrow this one down, but it's taking more time than I expected. May need some assistance with this since it seems directly related to the changes introduced by OpenJPA-2171, and personally I'm skeptical about those changes...

            People

            • Assignee:
              Mark Struberg
              Reporter:
              Kevin Sutter
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development