OpenJPA
  1. OpenJPA
  2. OPENJPA-2240

JVMVRFY012 when using openjpa together with hyperjaxb3

    Details

      Description

      We are facing a problem with class enhancing generated by hyperjaxb3.

      "Caused by: java.lang.VerifyError: JVMVRFY012 stack shape inconsistent; class=foo/Bar, metoda=pcgetDataTimeItem()Ljava/util/Date;, pc=7"

      The problem occurs on every usage of non JPA compatible type like XMLGregorianCalendar.
      For those types, the hyperjaxb3 plugin creates a kind of "proxy" setter/getter that uses JPA capable type.

      Example of such proxy getter/setter:
      <code>
      @Basic
      @Column(name = "DATATIMEITEM")
      @Temporal(TemporalType.TIMESTAMP)
      public Date getDataTimeItem()

      { return XmlAdapterUtils.unmarshall(XMLGregorianCalendarAsDateTime.class, this.getDataTime()); }

      </code>

      then the XmlAdapterUtils.unmarshall looks like:

      <code>
      public static <ValueType, BoundType> BoundType unmarshall(
      Class<? extends XmlAdapter<ValueType, BoundType>> xmlAdapterClass,
      ValueType v) {
      try

      { final XmlAdapter<ValueType, BoundType> xmlAdapter = getXmlAdapter(xmlAdapterClass); return xmlAdapter.unmarshal(v); }

      catch (Exception ex)

      { throw new RuntimeException(ex); }

      }
      </code>

      I have found that the problem occurs only because of the type of XmlAdapterUtils.unmarshall method. The problem is that it's 1st type is a "Class". Changing the 1st type from Class type to any other like Object solves the problem but it is not a solution.

      I think the problem is somewhere in serp project as after the enhancment process of classes containing non JPA capable XSD types, each call of that class generates the JVMVRFY012 exception- even during junit tests.

      Please note, that this bug is a blocker for my project.

      1. mvn.out
        2 kB
        Kevin Sutter
      2. OpenJpa2240BugTestProject_v1.1.tar.gz
        4 kB
        Piotr Klimczak
      3. serp-1.14.1.jar
        202 kB
        Kevin Sutter
      4. serp-1.14.1.pom
        4 kB
        Kevin Sutter

        Issue Links

          Activity

          Hide
          Kevin Sutter added a comment -

          For future reference, I have documented how to update Serp in Maven Central as part of this JIRA: http://openjpa.apache.org/publishing-serp-to-maven-central-repository.html

          Show
          Kevin Sutter added a comment - For future reference, I have documented how to update Serp in Maven Central as part of this JIRA: http://openjpa.apache.org/publishing-serp-to-maven-central-repository.html
          Hide
          Kevin Sutter added a comment -

          Piotr,
          I have figured out a way to update Maven Central with the updated Serp. I will be fixing this dependency in OpenJPA Trunk (2.3.0-SNAPSHOT). I have pinged the owners of the service branches (2.0.x, 2.1.x, and 2.2.x) that this issue also applies to those releases. The tricky part is the updating of a dependency in a service stream and how that dependency update may affect other unrelated processing. Basically, it will require additional testing – more than the basic JUnit bucket that I will be using before integrating the change into Trunk.

          If Trunk (2.3.0-SNAPSHOT) will work for you, then great, we're done. If you require this change in a service stream (ie. 2.2.x), please indicate which one so that the appropriate changes, decisions, and testing can be done. Thank you.

          Show
          Kevin Sutter added a comment - Piotr, I have figured out a way to update Maven Central with the updated Serp. I will be fixing this dependency in OpenJPA Trunk (2.3.0-SNAPSHOT). I have pinged the owners of the service branches (2.0.x, 2.1.x, and 2.2.x) that this issue also applies to those releases. The tricky part is the updating of a dependency in a service stream and how that dependency update may affect other unrelated processing. Basically, it will require additional testing – more than the basic JUnit bucket that I will be using before integrating the change into Trunk. If Trunk (2.3.0-SNAPSHOT) will work for you, then great, we're done. If you require this change in a service stream (ie. 2.2.x), please indicate which one so that the appropriate changes, decisions, and testing can be done. Thank you.
          Hide
          Piotr Klimczak added a comment -

          Hi Kevin!

          I am very happy to hear the problem is solved! THANKS!

          Now i have to wait for serp to be available in public repo. Unfortunately due to security reasons I cannot use other repos than public ones so i have to wait.
          Do you know which version of openjpa will fix the problem (public available version) and when it will be available?

          Once again thanks...
          Piotr

          Show
          Piotr Klimczak added a comment - Hi Kevin! I am very happy to hear the problem is solved! THANKS! Now i have to wait for serp to be available in public repo. Unfortunately due to security reasons I cannot use other repos than public ones so i have to wait. Do you know which version of openjpa will fix the problem (public available version) and when it will be available? Once again thanks... Piotr
          Hide
          Kevin Sutter added a comment -

          Serp 1.14.1 jar and pom until we figure out how to publish these to the maven repo...

          Show
          Kevin Sutter added a comment - Serp 1.14.1 jar and pom until we figure out how to publish these to the maven repo...
          Hide
          Kevin Sutter added a comment -

          Piotr, I found an even easier solution (I hope)... As I was checking into the updating of the Serp code, I noticed there was a later version of Serp (1.14.1) that stated, "Fix class constant copying bug." Sounds familiar, huh? So, I re-built a local copy of OpenJPA 2.2.0 and a local copy of Serp 1.14.1. Tried your test project and all is working. I also verified that all of the JUnits are also working. The problem is that this version of Serp is not in the Maven Central repo... And, I'm not exactly sure how to get it there... It's a SourceForge project. If anybody has any insights on how to get it published to the maven repo, let me know. Otherwise, I'll dig into it further this weekend.

          In the mean time, I'll upload a copy of the Serp 1.14.1 jar and pom in case you want to install it into your local repo and try some testing. Thanks.

          Show
          Kevin Sutter added a comment - Piotr, I found an even easier solution (I hope)... As I was checking into the updating of the Serp code, I noticed there was a later version of Serp (1.14.1) that stated, "Fix class constant copying bug." Sounds familiar, huh? So, I re-built a local copy of OpenJPA 2.2.0 and a local copy of Serp 1.14.1. Tried your test project and all is working. I also verified that all of the JUnits are also working. The problem is that this version of Serp is not in the Maven Central repo... And, I'm not exactly sure how to get it there... It's a SourceForge project. If anybody has any insights on how to get it published to the maven repo, let me know. Otherwise, I'll dig into it further this weekend. In the mean time, I'll upload a copy of the Serp 1.14.1 jar and pom in case you want to install it into your local repo and try some testing. Thanks.
          Hide
          Kevin Sutter added a comment -

          Piotr, I have found the problem. It's in the Serp enhancement code. It looks like Serp never expected a Class constant to be loaded via an ldc operation. In the second edition of the JVM, the ldc was limited to loading int, long, float, double, and String. Sometime later, this was expanded to allow loading of Class objects from the constant pool. Serp was never updated to allow for this.

          Your Page.class required the loading of a Class constant for that first parameter to the unmarshall() method. When we used Serp to create the pcgetLastMod() method, the code that was transferred over from the original getLastMod() method didn't transfer correctly because this loading of Class constants was not recognized properly.

          I have done a quick patch in my own environment and I can now load your enhanced Page.class. I'm going to try our Junit bucket to see what I am going to break with this type of change. And, then I need to figure out how to get a fix into the Serp code. It's been so solid for so many years that nobody has had to update it. As soon as I get something I am comfortable with, I'll post a patch so that you might try it out in your environment as well.

          Show
          Kevin Sutter added a comment - Piotr, I have found the problem. It's in the Serp enhancement code. It looks like Serp never expected a Class constant to be loaded via an ldc operation. In the second edition of the JVM, the ldc was limited to loading int, long, float, double, and String. Sometime later, this was expanded to allow loading of Class objects from the constant pool. Serp was never updated to allow for this. Your Page.class required the loading of a Class constant for that first parameter to the unmarshall() method. When we used Serp to create the pcgetLastMod() method, the code that was transferred over from the original getLastMod() method didn't transfer correctly because this loading of Class constants was not recognized properly. I have done a quick patch in my own environment and I can now load your enhanced Page.class. I'm going to try our Junit bucket to see what I am going to break with this type of change. And, then I need to figure out how to get a fix into the Serp code. It's been so solid for so many years that nobody has had to update it. As soon as I get something I am comfortable with, I'll post a patch so that you might try it out in your environment as well.
          Hide
          Kevin Sutter added a comment -

          Piotr, I have now reproduced the problem. Good news! I did end up changing the errant outputDirectory to the generatedSourcesDirectory in the pom.xml. I'll now take a closer look at the VerifyError. Thanks for the sample project.

          Show
          Kevin Sutter added a comment - Piotr, I have now reproduced the problem. Good news! I did end up changing the errant outputDirectory to the generatedSourcesDirectory in the pom.xml. I'll now take a closer look at the VerifyError. Thanks for the sample project.
          Hide
          Piotr Klimczak added a comment - - edited

          I am using maven 3.0.4.
          I have reuploaded the project with one small fix- added spring-context dep. to jaxb plugin which fixes possible ClassNotFoundException during stubs generation.

          According to outputDirectory- yes, it is not docummented, but it works in older versions of maven and is extremely helpful (2.0.2 for example). In newer version 2.2+ there is a generatedSourcesDirectory which is doing same thing as outputDirectory in older versions.
          So you can comment this line if you want or change it to "generatedSourcesDirectory" (if you are using newer compiler plugin), as it is responsible only for overriding the output directory of entities metamodel sources, to let them be easily accessible by eclipse (in target/jaxws as all other stubs).

          Greetings,
          Piotr Klimczak

          Show
          Piotr Klimczak added a comment - - edited I am using maven 3.0.4. I have reuploaded the project with one small fix- added spring-context dep. to jaxb plugin which fixes possible ClassNotFoundException during stubs generation. According to outputDirectory- yes, it is not docummented, but it works in older versions of maven and is extremely helpful (2.0.2 for example). In newer version 2.2+ there is a generatedSourcesDirectory which is doing same thing as outputDirectory in older versions. So you can comment this line if you want or change it to "generatedSourcesDirectory" (if you are using newer compiler plugin), as it is responsible only for overriding the output directory of entities metamodel sources, to let them be easily accessible by eclipse (in target/jaxws as all other stubs). Greetings, Piotr Klimczak
          Hide
          Piotr Klimczak added a comment -

          Fixed Spring dep. missing form jaxb2 plugin

          Show
          Piotr Klimczak added a comment - Fixed Spring dep. missing form jaxb2 plugin
          Hide
          Kevin Sutter added a comment -

          Piotr, As you can see by the attachment, I tried your "simple" project and I seem to be having an issue with attempting to override the output directory... I did some searching and it doesn't look like this was supposed to be overridable... But, maybe that changed in some later version of maven? Anyway, I don't have the project running yet... I can see where this is a bit more involved than what I had hoped... Running with jaxb generated entities and the XML types complicates the example just a bit... Hopefully, you have some ideas on how to quickly get the project building. Thanks.

          Show
          Kevin Sutter added a comment - Piotr, As you can see by the attachment, I tried your "simple" project and I seem to be having an issue with attempting to override the output directory... I did some searching and it doesn't look like this was supposed to be overridable... But, maybe that changed in some later version of maven? Anyway, I don't have the project running yet... I can see where this is a bit more involved than what I had hoped... Running with jaxb generated entities and the XML types complicates the example just a bit... Hopefully, you have some ideas on how to quickly get the project building. Thanks.
          Hide
          Kevin Sutter added a comment -

          My "mvn clean install" output... Can't do some of the mvn processing... Maybe due to an older version of maven?

          Show
          Kevin Sutter added a comment - My "mvn clean install" output... Can't do some of the mvn processing... Maybe due to an older version of maven?
          Hide
          Kevin Sutter added a comment -

          Thank you, Piotr, for the sample. I was out on vacation recently and just missed these updates. I will try to reproduce with your sample and, hopefully, figure out a solution quickly... Thanks.

          Show
          Kevin Sutter added a comment - Thank you, Piotr, for the sample. I was out on vacation recently and just missed these updates. I will try to reproduce with your sample and, hopefully, figure out a solution quickly... Thanks.
          Hide
          Piotr Klimczak added a comment -

          Hi Kevin!

          Thank you for your help!

          Did you succeed with bug reproduction using my example project?
          Do you want me to provide more examples? Or maybe to simplify the example?

          Greetings,
          Piotr Klimczak

          Show
          Piotr Klimczak added a comment - Hi Kevin! Thank you for your help! Did you succeed with bug reproduction using my example project? Do you want me to provide more examples? Or maybe to simplify the example? Greetings, Piotr Klimczak
          Hide
          Piotr Klimczak added a comment -

          The result of uploaded project on IBM JDK 6:

          java version "1.6.0"
          Java(TM) SE Runtime Environment (build pxa6460sr9fp2-20110625_01(SR9 FP2))
          IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr9-20110624_85526 (JIT enabled, AOT enabled)
          J9VM - 20110624_085526
          JIT - r9_20101028_17488ifx17
          GC - 20101027_AA)
          JCL - 20110530_01

          Result:
          -------------------------------------------------------------------------------
          Test set: pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest
          -------------------------------------------------------------------------------
          Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.103 sec <<< FAILURE!
          test(pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest) Time elapsed: 0.06 sec <<< ERROR!
          java.lang.VerifyError: JVMVRFY012 stack shape inconsistent; class=pl/klimczakowie/site/dev/site/domain/Page, method=pcgetLastModItem()Ljava/util/Date;, pc=7
          at java.lang.J9VMInternals.verifyImpl(Native Method)
          at java.lang.J9VMInternals.verify(J9VMInternals.java:72)
          at java.lang.J9VMInternals.initialize(J9VMInternals.java:134)
          at pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest.test(OpenJPA2240bugTest.java:34)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
          at java.lang.reflect.Method.invoke(Method.java:611)
          at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
          at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
          at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
          at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
          at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
          at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
          at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
          at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
          at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
          at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
          at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
          at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
          at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
          at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
          at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
          at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
          at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
          at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
          at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
          at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
          at java.lang.reflect.Method.invoke(Method.java:611)
          at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
          at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)

          The result of uploaded project on IBM JDK 7:

          java version "1.7.0"
          Java(TM) SE Runtime Environment (build pxa6470sr1-20120330_01(SR1))
          IBM J9 VM (build 2.6, JRE 1.7.0 Linux amd64-64 20120322_106209 (JIT enabled, AOT enabled)
          J9VM - R26_Java726_SR1_20120322_1720_B106209
          JIT - r11_20120322_22976
          GC - R26_Java726_SR1_20120322_1720_B106209
          J9CL - 20120322_106209)
          JCL - 20120322_01 based on Oracle 7u3-b05

          Result:
          -------------------------------------------------------------------------------
          Test set: pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest
          -------------------------------------------------------------------------------
          Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.089 sec <<< FAILURE!
          test(pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest) Time elapsed: 0.048 sec <<< ERROR!
          java.lang.VerifyError: JVMVRFY012 stack shape inconsistent; class=pl/klimczakowie/site/dev/site/domain/Page, method=pcgetLastModItem()Ljava/util/Date;, pc=7
          at java.lang.J9VMInternals.verifyImpl(Native Method)
          at java.lang.J9VMInternals.verify(J9VMInternals.java:85)
          at java.lang.J9VMInternals.initialize(J9VMInternals.java:162)
          at pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest.test(OpenJPA2240bugTest.java:34)
          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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
          at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
          at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
          at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
          at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
          at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
          at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
          at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
          at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
          at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
          at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
          at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
          at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
          at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
          at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
          at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
          at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
          at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
          at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
          at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
          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.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
          at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)

          Each time running #mvn clean install.

          Show
          Piotr Klimczak added a comment - The result of uploaded project on IBM JDK 6: java version "1.6.0" Java(TM) SE Runtime Environment (build pxa6460sr9fp2-20110625_01(SR9 FP2)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr9-20110624_85526 (JIT enabled, AOT enabled) J9VM - 20110624_085526 JIT - r9_20101028_17488ifx17 GC - 20101027_AA) JCL - 20110530_01 Result: ------------------------------------------------------------------------------- Test set: pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest ------------------------------------------------------------------------------- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.103 sec <<< FAILURE! test(pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest) Time elapsed: 0.06 sec <<< ERROR! java.lang.VerifyError: JVMVRFY012 stack shape inconsistent; class=pl/klimczakowie/site/dev/site/domain/Page, method=pcgetLastModItem()Ljava/util/Date;, pc=7 at java.lang.J9VMInternals.verifyImpl(Native Method) at java.lang.J9VMInternals.verify(J9VMInternals.java:72) at java.lang.J9VMInternals.initialize(J9VMInternals.java:134) at pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest.test(OpenJPA2240bugTest.java:34) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) The result of uploaded project on IBM JDK 7: java version "1.7.0" Java(TM) SE Runtime Environment (build pxa6470sr1-20120330_01(SR1)) IBM J9 VM (build 2.6, JRE 1.7.0 Linux amd64-64 20120322_106209 (JIT enabled, AOT enabled) J9VM - R26_Java726_SR1_20120322_1720_B106209 JIT - r11_20120322_22976 GC - R26_Java726_SR1_20120322_1720_B106209 J9CL - 20120322_106209) JCL - 20120322_01 based on Oracle 7u3-b05 Result: ------------------------------------------------------------------------------- Test set: pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest ------------------------------------------------------------------------------- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.089 sec <<< FAILURE! test(pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest) Time elapsed: 0.048 sec <<< ERROR! java.lang.VerifyError: JVMVRFY012 stack shape inconsistent; class=pl/klimczakowie/site/dev/site/domain/Page, method=pcgetLastModItem()Ljava/util/Date;, pc=7 at java.lang.J9VMInternals.verifyImpl(Native Method) at java.lang.J9VMInternals.verify(J9VMInternals.java:85) at java.lang.J9VMInternals.initialize(J9VMInternals.java:162) at pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest.test(OpenJPA2240bugTest.java:34) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) 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.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) Each time running #mvn clean install.
          Hide
          Piotr Klimczak added a comment - - edited

          Hi Kevin,

          Sorry for late answer- I have just returned from holidays.
          As you can see, I have uploaded simple maven project reproducing reported bug.

          The bug occurs on very simple test case that creates an instance of "Page" class which contains xsd:dateTime type as an XMLGregorianCalendar.

          I've tested it on:

          java version "1.6.0_31"
          Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
          Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)

          The result is a little different than above. Probably because of different JDK.
          -------------------------------------------------------------------------------
          Test set: pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest
          -------------------------------------------------------------------------------
          Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.079 sec <<< FAILURE!
          test(pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest) Time elapsed: 0.039 sec <<< ERROR!
          java.lang.VerifyError: (class: pl/klimczakowie/site/dev/site/domain/Page, method: pcgetLastModItem signature: ()Ljava/util/Date Incompatible argument to function
          at pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest.test(OpenJPA2240bugTest.java:34)
          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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
          at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
          at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
          at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
          at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
          at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
          at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
          at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
          at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
          at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
          at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
          at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
          at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
          at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
          at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
          at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
          at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
          at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
          at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
          at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
          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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
          at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)

          Show
          Piotr Klimczak added a comment - - edited Hi Kevin, Sorry for late answer- I have just returned from holidays. As you can see, I have uploaded simple maven project reproducing reported bug. The bug occurs on very simple test case that creates an instance of "Page" class which contains xsd:dateTime type as an XMLGregorianCalendar. I've tested it on: java version "1.6.0_31" Java(TM) SE Runtime Environment (build 1.6.0_31-b04) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode) The result is a little different than above. Probably because of different JDK. ------------------------------------------------------------------------------- Test set: pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest ------------------------------------------------------------------------------- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.079 sec <<< FAILURE! test(pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest) Time elapsed: 0.039 sec <<< ERROR! java.lang.VerifyError: (class: pl/klimczakowie/site/dev/site/domain/Page, method: pcgetLastModItem signature: ()Ljava/util/Date Incompatible argument to function at pl.klimczakowie.site.dev.site.domain.OpenJPA2240bugTest.test(OpenJPA2240bugTest.java:34) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
          Hide
          Piotr Klimczak added a comment -

          A quick simple project reproducing reported bug.

          Show
          Piotr Klimczak added a comment - A quick simple project reproducing reported bug.
          Hide
          Kevin Sutter added a comment -

          Hi Piotr,
          Still no luck with reproducing the problem. I created a separate Utility class and created this static unmarshall() method. Still works just fine.

          And, it wasn't good to hear that your problem still exists with the Java 7 build environment. That means that the ASM solution we put in place for Java 7 doesn't help in your situation either. You did re-build and re-enhance with Java 7, correct? That's where the ASM "magic" occurs is with the enhancement processing.

          Can you provide the actual Entity classes (before and after enhancement)? If you can also provide the utility classes that would allow us to load the classes to reproduce the problem, that would be great. Thanks!

          Kevin

          Show
          Kevin Sutter added a comment - Hi Piotr, Still no luck with reproducing the problem. I created a separate Utility class and created this static unmarshall() method. Still works just fine. And, it wasn't good to hear that your problem still exists with the Java 7 build environment. That means that the ASM solution we put in place for Java 7 doesn't help in your situation either. You did re-build and re-enhance with Java 7, correct? That's where the ASM "magic" occurs is with the enhancement processing. Can you provide the actual Entity classes (before and after enhancement)? If you can also provide the utility classes that would allow us to load the classes to reproduce the problem, that would be great. Thanks! Kevin
          Hide
          Piotr Klimczak added a comment - - edited

          There is very same problem on Java7.

          Caused by: java.lang.VerifyError: JVMVRFY012 niespójny kształt stosu; klasa=foo/BasicResponseData$Offilne, metoda=pcgetDataTimeItem()Ljava/util/Date;, pc=7
          at java.lang.J9VMInternals.verifyImpl(Native Method)
          at java.lang.J9VMInternals.verify(J9VMInternals.java:85)
          at java.lang.J9VMInternals.initialize(J9VMInternals.java:162)
          at java.lang.Class.forNameImpl(Native Method)
          at java.lang.Class.forName(Class.java:139)
          .......

          Tested with:
          java version "1.7.0"
          Java(TM) SE Runtime Environment (build pxa6470sr1-20120330_01(SR1))
          IBM J9 VM (build 2.6, JRE 1.7.0 Linux amd64-64 20120322_106209 (JIT enabled, AOT enabled)
          J9VM - R26_Java726_SR1_20120322_1720_B106209
          JIT - r11_20120322_22976
          GC - R26_Java726_SR1_20120322_1720_B106209
          J9CL - 20120322_106209)
          JCL - 20120322_01 based on Oracle 7u3-b05

          Show
          Piotr Klimczak added a comment - - edited There is very same problem on Java7. Caused by: java.lang.VerifyError: JVMVRFY012 niespójny kształt stosu; klasa=foo/BasicResponseData$Offilne, metoda=pcgetDataTimeItem()Ljava/util/Date;, pc=7 at java.lang.J9VMInternals.verifyImpl(Native Method) at java.lang.J9VMInternals.verify(J9VMInternals.java:85) at java.lang.J9VMInternals.initialize(J9VMInternals.java:162) at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:139) ....... Tested with: java version "1.7.0" Java(TM) SE Runtime Environment (build pxa6470sr1-20120330_01(SR1)) IBM J9 VM (build 2.6, JRE 1.7.0 Linux amd64-64 20120322_106209 (JIT enabled, AOT enabled) J9VM - R26_Java726_SR1_20120322_1720_B106209 JIT - r11_20120322_22976 GC - R26_Java726_SR1_20120322_1720_B106209 J9CL - 20120322_106209) JCL - 20120322_01 based on Oracle 7u3-b05
          Hide
          Piotr Klimczak added a comment -

          Hi Kevin!

          Thanks again for your help.

          According to your test It is possible you have no luck because the method with Class type parameter was a static method placed in different class/file.
          In my situation an entity getter calls:

          <code>
          return XmlAdapterUtils.unmarshall(XMLGregorianCalendarAsDateTime.class, this.getDataTime());
          </code>

          Please also note, the the unmarshall method was generic.

          Show
          Piotr Klimczak added a comment - Hi Kevin! Thanks again for your help. According to your test It is possible you have no luck because the method with Class type parameter was a static method placed in different class/file. In my situation an entity getter calls: <code> return XmlAdapterUtils.unmarshall(XMLGregorianCalendarAsDateTime.class, this.getDataTime()); </code> Please also note, the the unmarshall method was generic.
          Hide
          Kevin Sutter added a comment -

          I have been trying to reproduce the situation with no luck. Granted, I don't have the hyperjaxb and the associated XML libraries. But, from your description, it sounded like I should be able to reproduce the VerifyError with an extra helper getter method that called a utility method passing in a .class as the first parameter. Just something to complicate the getter method just enough to screw up the StackMapTables. But, I have had no luck. As an example, here's what I added to a simple Entity class:

          @Basic
          @Column(name = "DATATIMEITEM")
          @Temporal(TemporalType.TIMESTAMP)
          public Date getDataTimeItem()

          { // return XmlAdapterUtils.unmarshall(XMLGregorianCalendarAsDateTime.class, this.getDataTime()); return unmarshall(XMLGregorianCalendar.class, this.getDateField()); }

          private Date unmarshall(Class<XMLGregorianCalendar> class1, Date dateField2)

          { // TODO Auto-generated method stub return dateField2; }

          I tried this with Java6sr9 (my current default), Java6sr10 (your current Java), and Java7. No luck with reproducing. If you can help with narrowing down the scenario with a simpler testcase, or maybe provide the Entity classes and needed libraries to reproduce it, I'm very interested in tracking down this problem. Thanks.

          Show
          Kevin Sutter added a comment - I have been trying to reproduce the situation with no luck. Granted, I don't have the hyperjaxb and the associated XML libraries. But, from your description, it sounded like I should be able to reproduce the VerifyError with an extra helper getter method that called a utility method passing in a .class as the first parameter. Just something to complicate the getter method just enough to screw up the StackMapTables. But, I have had no luck. As an example, here's what I added to a simple Entity class: @Basic @Column(name = "DATATIMEITEM") @Temporal(TemporalType.TIMESTAMP) public Date getDataTimeItem() { // return XmlAdapterUtils.unmarshall(XMLGregorianCalendarAsDateTime.class, this.getDataTime()); return unmarshall(XMLGregorianCalendar.class, this.getDateField()); } private Date unmarshall(Class<XMLGregorianCalendar> class1, Date dateField2) { // TODO Auto-generated method stub return dateField2; } I tried this with Java6sr9 (my current default), Java6sr10 (your current Java), and Java7. No luck with reproducing. If you can help with narrowing down the scenario with a simpler testcase, or maybe provide the Entity classes and needed libraries to reproduce it, I'm very interested in tracking down this problem. Thanks.
          Hide
          Piotr Klimczak added a comment -

          No problem. Will try to reproduce the problem with IBM JDK 7 tomorrow morning.

          Piotr

          Show
          Piotr Klimczak added a comment - No problem. Will try to reproduce the problem with IBM JDK 7 tomorrow morning. Piotr
          Hide
          Kevin Sutter added a comment -

          Thanks for the info, Piotr. I was surprised to see that you are running Java 6. I hadn't seen the VerifyError with Java 6, only Java 7. In Java 7, the class verification was turned on by default. In Java 6, this class verification was supposed to be optional. Is there any chance that you running with class verification? If so, can you turn it off? Since we introduced a dependency on ASM to correct these StackMapTable errors with Java 7, is there any chance you could build/enhance with Java 7. If that helps, then maybe we can just enable ASM for Java 6 class files as well as Java 7. In the mean time, if I have time, I will try to reproduce the issue locally with your submitted entity definitions. Thanks.

          Kevin

          Show
          Kevin Sutter added a comment - Thanks for the info, Piotr. I was surprised to see that you are running Java 6. I hadn't seen the VerifyError with Java 6, only Java 7. In Java 7, the class verification was turned on by default. In Java 6, this class verification was supposed to be optional. Is there any chance that you running with class verification? If so, can you turn it off? Since we introduced a dependency on ASM to correct these StackMapTable errors with Java 7, is there any chance you could build/enhance with Java 7. If that helps, then maybe we can just enable ASM for Java 6 class files as well as Java 7. In the mean time, if I have time, I will try to reproduce the issue locally with your submitted entity definitions. Thanks. Kevin
          Hide
          Piotr Klimczak added a comment -

          As i "cannot sleep" because of that bug, i have tried to trace is as you wish.
          Unfortunately i have found nothing interesting:

          122 INFO [main] openjpa.Tool - Enhancer running on type "class pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne".
          133 TRACE [main] openjpa.MetaData - Loading metadata for "class pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne" under mode "[META]".
          133 TRACE [main] openjpa.MetaData - Parsing class "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne".
          150 TRACE [main] openjpa.MetaData - Generating default metadata for type "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne".
          151 TRACE [main] openjpa.MetaData - Using reflection for metadata generation.
          159 TRACE [main] openjpa.MetaData - Set persistence-capable superclass of "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne" to "null".
          159 TRACE [main] openjpa.MetaData - Resolving metadata for "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne@1436046744".
          160 TRACE [main] openjpa.MetaData - Resolving field "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne@1436046744.dataTimeItem".
          163 TRACE [main] openjpa.MetaData - Resolving field "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne@1436046744.hjid".
          163 TRACE [main] openjpa.MetaData - Resolving field "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne@1436046744.offlineId".
          163 TRACE [main] openjpa.MetaData - Resolving field "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne@1436046744.retry".
          164 TRACE [main] openjpa.MetaData - Preparing mapping for "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne".
          164 TRACE [main] openjpa.MetaData - Resolving mapping for "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne@1436046744".
          164 TRACE [main] openjpa.Enhance - Enhancing type "class pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne" loaded by java.net.URLClassLoader@71a371a3.
          173 WARN [main] openjpa.Enhance - Detected the following possible violations of the restrictions placed on property access persistent types:
          "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne" uses property access, but its field "offlineId" is accessed directly in method "copyTo" defined in "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne".
          "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne" uses property access, but its field "offlineId" is accessed directly in method "copyTo" defined in "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne".
          "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne" uses property access, but its field "retry" is accessed directly in method "copyTo" defined in "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne".
          "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne" uses property access, but its field "retry" is accessed directly in method "copyTo" defined in "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne".

          The class enhance is successful. The problem occurs on every each usage of this class by an app. Even during junit test case.

          If you need more debug info i will do my best to provide it.

          Greetings,
          Piotr

          Show
          Piotr Klimczak added a comment - As i "cannot sleep" because of that bug, i have tried to trace is as you wish. Unfortunately i have found nothing interesting: 122 INFO [main] openjpa.Tool - Enhancer running on type "class pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne". 133 TRACE [main] openjpa.MetaData - Loading metadata for "class pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne" under mode " [META] ". 133 TRACE [main] openjpa.MetaData - Parsing class "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne". 150 TRACE [main] openjpa.MetaData - Generating default metadata for type "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne". 151 TRACE [main] openjpa.MetaData - Using reflection for metadata generation. 159 TRACE [main] openjpa.MetaData - Set persistence-capable superclass of "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne" to "null". 159 TRACE [main] openjpa.MetaData - Resolving metadata for "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne@1436046744". 160 TRACE [main] openjpa.MetaData - Resolving field "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne@1436046744.dataTimeItem". 163 TRACE [main] openjpa.MetaData - Resolving field "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne@1436046744.hjid". 163 TRACE [main] openjpa.MetaData - Resolving field "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne@1436046744.offlineId". 163 TRACE [main] openjpa.MetaData - Resolving field "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne@1436046744.retry". 164 TRACE [main] openjpa.MetaData - Preparing mapping for "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne". 164 TRACE [main] openjpa.MetaData - Resolving mapping for "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne@1436046744". 164 TRACE [main] openjpa.Enhance - Enhancing type "class pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne" loaded by java.net.URLClassLoader@71a371a3. 173 WARN [main] openjpa.Enhance - Detected the following possible violations of the restrictions placed on property access persistent types: "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne" uses property access, but its field "offlineId" is accessed directly in method "copyTo" defined in "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne". "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne" uses property access, but its field "offlineId" is accessed directly in method "copyTo" defined in "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne". "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne" uses property access, but its field "retry" is accessed directly in method "copyTo" defined in "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne". "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne" uses property access, but its field "retry" is accessed directly in method "copyTo" defined in "pl.com.bgk.smx.kgapi.contract.basics.types.BasicResponseData$Offilne". The class enhance is successful. The problem occurs on every each usage of this class by an app. Even during junit test case. If you need more debug info i will do my best to provide it. Greetings, Piotr
          Hide
          Piotr Klimczak added a comment -

          Hi Kevin,

          Thanks for quick reply.

          I am using IBM-JDK as follows:
          java version "1.6.0"
          Java(TM) SE Runtime Environment (build pxa6460sr10-20111208_01(SR10))
          IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr10-20111207_96808 (JIT enabled, AOT enabled)
          J9VM - 20111207_096808
          JIT - r9_20111107_21307ifx1
          GC - 20110519_AA)
          JCL - 20111104_02

          I've been testing the problem with following OpenJPA versions: 2.2.0, 2.3.0-SNAPSHOT.
          I have also tried with serp 1.14.2 w/o success.

          As i said the problem disappears after removing all Class type parameters from methods invoked from enriched entities.

          I will try to provide some debug info in about 2 days as i have much different "todos" right now.

          Greetings
          Piotr Klimczak

          Show
          Piotr Klimczak added a comment - Hi Kevin, Thanks for quick reply. I am using IBM-JDK as follows: java version "1.6.0" Java(TM) SE Runtime Environment (build pxa6460sr10-20111208_01(SR10)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr10-20111207_96808 (JIT enabled, AOT enabled) J9VM - 20111207_096808 JIT - r9_20111107_21307ifx1 GC - 20110519_AA) JCL - 20111104_02 I've been testing the problem with following OpenJPA versions: 2.2.0, 2.3.0-SNAPSHOT. I have also tried with serp 1.14.2 w/o success. As i said the problem disappears after removing all Class type parameters from methods invoked from enriched entities. I will try to provide some debug info in about 2 days as i have much different "todos" right now. Greetings Piotr Klimczak
          Hide
          Kevin Sutter added a comment -

          Hmmm... The error you reported sounds identical to the Java 7 class format errors that were corrected via https://issues.apache.org/jira/browse/OPENJPA-2122 and https://issues.apache.org/jira/browse/OPENJPA-2085. But, both of these were resolved before the 2.2.0 release was cut...

          In your Environment, you mention both the IBM and Sun JDKs. What version of Java are you using? I will assume Java 7 since we never experienced the VerifyError before that. Is it possible for you to try Java 6? I'm just looking for a quick workaround for you since figuring out the necessary changes to ASM and/or Serp will take some time (if this is a new problem).

          You also mention that this affects OpenJPA 2.2.0. Can you verify that this version is actually in use in your scenario. And, have you tried to turn on Trace during the enhancement process to verify that ASM is getting invoked to "clean up" these StackMapTable issues?

          Thanks for your help in attempting to debug this problem.

          Kevin

          Show
          Kevin Sutter added a comment - Hmmm... The error you reported sounds identical to the Java 7 class format errors that were corrected via https://issues.apache.org/jira/browse/OPENJPA-2122 and https://issues.apache.org/jira/browse/OPENJPA-2085 . But, both of these were resolved before the 2.2.0 release was cut... In your Environment, you mention both the IBM and Sun JDKs. What version of Java are you using? I will assume Java 7 since we never experienced the VerifyError before that. Is it possible for you to try Java 6? I'm just looking for a quick workaround for you since figuring out the necessary changes to ASM and/or Serp will take some time (if this is a new problem). You also mention that this affects OpenJPA 2.2.0. Can you verify that this version is actually in use in your scenario. And, have you tried to turn on Trace during the enhancement process to verify that ASM is getting invoked to "clean up" these StackMapTable issues? Thanks for your help in attempting to debug this problem. Kevin

            People

            • Assignee:
              Kevin Sutter
              Reporter:
              Piotr Klimczak
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development