On 27/01/2012 16:59, Kevin Sutter wrote: > Hi Francesco, > I'm a little slow this morning... Could you elaborate on what you changed? > It sounds like you removed the @ManyToMany annotation (or a portion of it > anyway) on the non-owning side of the relationship? And, you replaced it > with a method on your DAO (of which entity?) to satisfy the relationship? > This sounds like a bug, both functionally and performance wise. Even > though you are past your immediate concern, it would be good to understand > this so that we can get a JIRA and a fix in place. Thanks.
Of course :-) The Entitlement entity looked like [1] at first: as you can see there, there is a member collection 'roles', labeled @ManyToMany(fetch = FetchType.EAGER, mappedBy = "entitlements"). The same entity is now [2], i.e. without 'roles' filed. In addition to this, I have added a method on RoleDAO [3], findByEntitlement(Entitlement entitlement) - see implementation [4] - that basically queries the persistence context for all roles with given entitlement. In this way I have access to the same information I lost when removing 'roles' from Entitlement. I don't know if this can be a bug: consider that I had no troubles - but H2 poor performance - when deploying onto Tomcat 7. Hope this is a bit more clear now. Regards. [1] http://code.google.com/p/syncope/source/browse/ <http://code.google.com/p/syncope/source/browse/branches/0_8_X_ASL/core/src/main/java/org/syncope/core/persistence/beans/Entitlement.java?r=1421>trunk <http://code.google.com/p/syncope/source/browse/trunk/core/src/main/java/org/syncope/core/persistence/beans/Entitlement.java>/core/src/main/java/org/syncope/core/persistence/beans/Entitlement.java?r=1433 <http://code.google.com/p/syncope/source/browse/branches/0_8_X_ASL/core/src/main/java/org/syncope/core/persistence/beans/Entitlement.java?r=1421> [2] http://code.google.com/p/syncope/source/browse/trunk/core/src/main/java/org/syncope/core/persistence/beans/Entitlement.java [3] http://code.google.com/p/syncope/source/browse/trunk/core/src/main/java/org/syncope/core/persistence/dao/RoleDAO.java [4] http://code.google.com/p/syncope/source/browse/trunk/core/src/main/java/org/syncope/core/persistence/dao/impl/RoleDAOImpl.java > 2012/1/27 Francesco Chicchiriccò <[email protected]> > >> 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/
