Created attachment 696079 [details] the attached project based on a very simple JBoss example to reproduce the issue Description of problem: I got an issue in a salesforce case [1] about an incorrect injection. [1] https://c.na7.visual.force.com/apex/Case_View?id=500A000000CRqDG&sfdc.override=1 Version-Release number of selected component (if applicable): How reproducible: To reproduce the case is required to have two PersistentUnit (PU), a Abstract class with a setter method to inject one PU and others classes inheriting the Abstract class and overriding the setter method to inject a different PU. In the runtime, the container inject twice the PU, first the correct PU and then the PU described in super class. I talked with the client (who is a Red Hat consultant) and we made the attached project based on a very simple JBoss example to reproduce the issue which happens in EAP6. I put a lot of 'println' to be very clear (even printing stacktrace to show who is calling). The most important files are: -> hibernate4Test/src/main/java/org/jboss/as/quickstart/hibernate4/data/BaseDAO.java -- The abstract class with the default PU injection -> hibernate4Test/src/main/java/org/jboss/as/quickstart/hibernate4/data/MemberRepository.java -- BaseDAO subclass -> hibernate4Test/src/main/java/org/jboss/as/quickstart/hibernate4/data/SecondaryMemberRepository.java -- BaseDAO subclass -> hibernate4Test/src/main/java/org/jboss/as/quickstart/hibernate4/data/MemberListProducer.java -- The class which inject the MemberListProducer and SecondaryMemberRepository -> hibernate4Test/src/main/resources/META-INF/persistence.xml -- We changed the configuration here to each PU have a different entity mapped Steps to Reproduce: Actual results: The EM injection occurs twice, which the last one the wrong EM. Expected results: Just one injection occurs. Additional info:
Created attachment 696080 [details] WAR containing the reproduced issue
Scott Marlow <scott.marlow> made a comment on jira AS7-6500 I deployed the standalone test attached to the bugzilla bug and in JPAAnnotationProcessor.doDeploy(), we get an unordered list of the annotations via: {code} List<AnnotationInstance> persistenceContexts = index.getAnnotations(PERSISTENCE_CONTEXT_ANNOTATION_NAME); persistenceContexts[0]=@javax.persistence.PersistenceContext(unitName = "secondary") on void org.jboss.as.quickstart.hibernate4.service.MemberRegistration.setEm(javax.persistence.EntityManager) persistenceContexts[1]=@javax.persistence.PersistenceContext(unitName = "secondary") on void org.jboss.as.quickstart.hibernate4.data.SecondaryMemberRepository.setEm(javax.persistence.EntityManager) persistenceContexts[2]=@javax.persistence.PersistenceContext(unitName = "primary") on void org.jboss.as.quickstart.hibernate4.data.MemberRepository.setEm(javax.persistence.EntityManager) persistenceContexts[3]=@javax.persistence.PersistenceContext(unitName = "primary") on void org.jboss.as.quickstart.hibernate4.data.BaseDAO.setEm(javax.persistence.EntityManager) {code}
Scott Marlow <scott.marlow> made a comment on jira AS7-6500 I deployed the standalone test attached to the bugzilla bug and in JPAAnnotationProcessor.doDeploy(), we get an unordered list of the annotations via: {code} List<AnnotationInstance> persistenceContexts = index.getAnnotations(PERSISTENCE_CONTEXT_ANNOTATION_NAME); {code} {quote} persistenceContexts[0]=@javax.persistence.PersistenceContext(unitName = "secondary") on void org.jboss.as.quickstart.hibernate4.service.MemberRegistration.setEm(javax.persistence.EntityManager) persistenceContexts[1]=@javax.persistence.PersistenceContext(unitName = "secondary") on void org.jboss.as.quickstart.hibernate4.data.SecondaryMemberRepository.setEm(javax.persistence.EntityManager) persistenceContexts[2]=@javax.persistence.PersistenceContext(unitName = "primary") on void org.jboss.as.quickstart.hibernate4.data.MemberRepository.setEm(javax.persistence.EntityManager) persistenceContexts[3]=@javax.persistence.PersistenceContext(unitName = "primary") on void org.jboss.as.quickstart.hibernate4.data.BaseDAO.setEm(javax.persistence.EntityManager) {quote}
Luan Cestari <lcestari> made a comment on jira AS7-6500 This means that it ins't Hibernate problem or are there others possibilities with Hibernate? Didn't you get the strange output deploying into EAP 6? If I'm not wrong, the ComponentDescription.mergeInjectionsForClass method inject the wrong EM.
Scott Marlow <scott.marlow> made a comment on jira AS7-6500 What is the output that I am looking for? I am using the latest AS7 sources currently and have TRACE logging enabled. My deployment output and some application output is here http://fpaste.org/G1jr/ I'll step through the ComponentDescription.mergeInjectionsForClass() next.
Luan Cestari <lcestari> made a comment on jira AS7-6500 I'm attaching my log. Line "18:21:36,608". You will see that the injection occurred twice and the second injection (the line mentioned) injects the wrong EM.
Luan Cestari <lcestari> made a comment on jira AS7-6500 Attaching log in BZ
Created attachment 696246 [details] Log with the problem (the double and wrong injection) (those exceptions were printed to show who is calling the methods)
Scott Marlow <scott.marlow> made a comment on jira AS7-6500 Luan, I see similar output, thanks for pasting your log. Regarding your question about the Hibernate (persistence provider) component, no, Hibernate is not causing the incorrect injection to be made by the container. Regarding ComponentDescription.mergeInjectionsForClass, I think the question is whether that is the right place to fix this issue for all EE deployments. I don't think this is limited to JPA, so finding a central place to resolve could be nice (instead of inside each EE deployment processor).
Stuart Douglas <stuart.w.douglas> made a comment on jira AS7-6500 This is a general EE compliance issue, it is not specific to persistence contexts. The correct way to solve it is to keep track of methods in ComponentDescription.mergeInjectionsForClass(), making sure that you take things like method visibility into account.
Stuart Douglas <stuart.w.douglas> made a comment on jira AS7-6500 I already had a potential solution to this locally from when I looked into the support email yesterday. I have added a test case and it appears to work so I have submitted a PR.
Stuart Douglas <stuart.w.douglas> updated the status of jira AS7-6500 to Resolved
This should not be "NEW" issue.