openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OPENJPA-2240) JVMVRFY012 when using openjpa together with hyperjaxb3
Date Fri, 31 Aug 2012 21:00:07 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13446369#comment-13446369
] 

Kevin Sutter commented on OPENJPA-2240:
---------------------------------------

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.
                
> JVMVRFY012 when using openjpa together with hyperjaxb3
> ------------------------------------------------------
>
>                 Key: OPENJPA-2240
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-2240
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: Enhance
>    Affects Versions: 2.2.0
>         Environment: IBM-JDK, SUN-JDK
>            Reporter: Piotr Klimczak
>            Priority: Critical
>              Labels: enhancement, hyperjaxb3, jpa, stubs, xsd
>         Attachments: mvn.out, OpenJpa2240BugTestProject_v1.1.tar.gz
>
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message