On 26/01/2012 17:55, Kevin Sutter wrote: > Hi Francesco, > I'm not an expert with Glassfish, so I don't know if there any specific > steps to override the EclipseLink implementation. I was only making an > assumption. Maybe not an accurate assumption... > > Is your persistence.xml specifying the openjpa persistence provider? You > are definitely getting into the openjpa code base, so your configuration > must be pretty close. > > But, getting a Stack Overflow error on a simple merge operation is kind of > indicating somebody or something is confused. One of the uses of the > PersistenceUtil is used to help figure out if a given Entity instance is > being managed by a given provider. Maybe EclipseLink and OpenJPA are > fighting over management of the merged entities. > > Any additional debugging data would be good information. Good luck.
Hi all, after some deeper investigation (including good old live debugging) and many unsuccessful attempts, I ended up by locating the problem in a bidirectional @ManyToMany relationship. It turned out that one side of such relationship was the Entity bean subjected to the StackOverflow error. So I refactored my source code by removing the "offending" side of the relationship and adding a method on the corresponding DAO with purpose of providing the same information of the removed collection (i.e. side of relationship). After this, some more tests were succeeding: in order to make everything work (yes, I finally succeeded :-P) I had to transform all bidirectional @ManyToMany relationships as reported above. Now everything is working on Glassfish. ..and you know what? Also H2 performance has *greatly* improved (see [1]). Any clever comment on this? I am not sure to understand why I solved :-S Regards. [1] http://openjpa.208410.n2.nabble.com/H2-poor-performance-td7220259.html > 2012/1/26 Francesco Chicchiriccò <[email protected]> > >> On 26/01/2012 17:18, Kevin Sutter wrote: >>> Hi, >>> Glassfish ships with EclipseLink (another JPA provider) by default. If you >>> are attempting to use an alternate JPA provider (ie. OpenJPA), then have >>> you properly disabled or overloaded the EclipseLink impl with the >>> OpenJPAimpl? >> Hi Kevin, >> nice question: how am I supposed to perform such task? >> >> Anyway, I did the same in the past for Hibernate and the steps reported >> below were enough. >> >> With current setup I have the following results: >> >> Tests run: 133, Failures: 6, Errors: 2, Skipped: 0 >> >> This means that only some things are not working: I'll give them a >> closer look. >> >> Regards. >> >>> 2012/1/26 Francesco Chicchiriccò <[email protected]> >>> >>>> Hi all, >>>> I am trying to deploy my openjpa-based webapp to Glassfish 3.1.1 >>>> >>>> A bare deploy of the same WAR working with Tomcat 7 simply fails. >>>> >>>> What I've done so far: >>>> >>>> 1. added WEB-INF/glassfish-web.xml like as follows: >>>> >>>> <glassfish-web-app> >>>> <context-root>/syncope</context-root> >>>> <resource-ref> >>>> <res-ref-name>jdbc/syncopeDataSource</res-ref-name> >>>> <jndi-name>jdbc/syncopeDataSource</jndi-name> >>>> </resource-ref> >>>> <class-loader delegate="false"/> >>>> </glassfish-web-app> >>>> >>>> The relevant stuff here is the delegating class-loader stuff, needed for >>>> letting Spring do its job. >>>> >>>> 2. added a property in persistence.xml in order to avoid to trigger >>>> EclipseLink's weaver, embedded in Glassfish (I am using build-time >>>> enhancement via openjpa-maven.plugin): >>>> >>>> <property name="eclipselink.weaving" value="false"/> >>>> >>>> >>>> With the settings above, many things in the application seem to work: >>>> unfortunately, when it comes to merge an entity, the following error is >>>> thrown: >>>> >>>> java.lang.StackOverflowError >>>> at >>>> >>>> >> org.apache.openjpa.kernel.TransferFieldManager.storeObjectField(TransferFieldManager.java:115) >>>> at >>>> >>>> >> org.apache.openjpa.kernel.StateManagerImpl.providedObjectField(StateManagerImpl.java:2166) >>>> at >>>> >>>> >> org.syncope.core.persistence.beans.SchemaMapping.pcProvideField(SchemaMapping.java) >>>> at >>>> >>>> >> org.apache.openjpa.kernel.StateManagerImpl.provideField(StateManagerImpl.java:3163) >>>> at >>>> >>>> >> org.apache.openjpa.kernel.StateManagerImpl.fetchObjectField(StateManagerImpl.java:2392) >>>> at >>>> >>>> >> org.apache.openjpa.kernel.StateManagerImpl.fetchField(StateManagerImpl.java:872) >>>> at >>>> >>>> >> org.apache.openjpa.persistence.OpenJPAPersistenceUtil.isLoadedField(OpenJPAPersistenceUtil.java:200) >>>> at >>>> >>>> >> org.apache.openjpa.persistence.OpenJPAPersistenceUtil.isLoaded(OpenJPAPersistenceUtil.java:161) >>>> at >>>> >>>> >> org.apache.openjpa.persistence.OpenJPAPersistenceUtil.isLoadedArray(OpenJPAPersistenceUtil.java:265) >>>> at >>>> >>>> >> org.apache.openjpa.persistence.OpenJPAPersistenceUtil.isLoadedCollection(OpenJPAPersistenceUtil.java:242) >>>> at >>>> >>>> >> org.apache.openjpa.persistence.OpenJPAPersistenceUtil.isLoadedField(OpenJPAPersistenceUtil.java:212) >>>> at >>>> >>>> >> org.apache.openjpa.persistence.OpenJPAPersistenceUtil.isLoaded(OpenJPAPersistenceUtil.java:161) >>>> at >>>> >>>> >> org.apache.openjpa.persistence.OpenJPAPersistenceUtil.isLoadedArray(OpenJPAPersistenceUtil.java:265) >>>> at >>>> >>>> >> org.apache.openjpa.persistence.OpenJPAPersistenceUtil.isLoadedCollection(OpenJPAPersistenceUtil.java:242) >>>> at >>>> >>>> >> org.apache.openjpa.persistence.OpenJPAPersistenceUtil.isLoadedField(OpenJPAPersistenceUtil.java:212) >>>> ... >>>> >>>> Any hint? >>>> >>>> TIA. >>>> Regards. -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
