Return-Path: X-Original-To: apmail-openjpa-dev-archive@www.apache.org Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A2715D7F5 for ; Wed, 5 Sep 2012 21:03:07 +0000 (UTC) Received: (qmail 63729 invoked by uid 500); 5 Sep 2012 21:03:07 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 63623 invoked by uid 500); 5 Sep 2012 21:03:07 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 63610 invoked by uid 99); 5 Sep 2012 21:03:07 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Sep 2012 21:03:07 +0000 Date: Thu, 6 Sep 2012 08:03:07 +1100 (NCT) From: "Kevin Sutter (JIRA)" To: dev@openjpa.apache.org Message-ID: <1582618401.41249.1346878987489.JavaMail.jiratomcat@arcas> In-Reply-To: <469194747.100574.1343212414738.JavaMail.jiratomcat@issues-vm> Subject: [jira] [Commented] (OPENJPA-2240) JVMVRFY012 when using openjpa together with hyperjaxb3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/OPENJPA-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449131#comment-13449131 ] Kevin Sutter commented on OPENJPA-2240: --------------------------------------- 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. > 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, serp-1.14.1.jar, serp-1.14.1.pom > > > 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: > > @Basic > @Column(name = "DATATIMEITEM") > @Temporal(TemporalType.TIMESTAMP) > public Date getDataTimeItem() { > return XmlAdapterUtils.unmarshall(XMLGregorianCalendarAsDateTime.class, this.getDataTime()); > } > > then the XmlAdapterUtils.unmarshall looks like: > > public static BoundType unmarshall( > Class> xmlAdapterClass, > ValueType v) { > try { > final XmlAdapter xmlAdapter = getXmlAdapter(xmlAdapterClass); > return xmlAdapter.unmarshal(v); > } catch (Exception ex) { > throw new RuntimeException(ex); > } > } > > 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