For example the PU is defined in ear/lib and in ear/war1, but not in ear/war2. But war2 uses the PU via JNDI injection.

I think we would not name the EntityManagerFactory bean in each of the duplicate persistence units.  Unless we use a more unique name but I'm not yet convinced that we should use a more unique name (e.g. module archive name + persistence unit name == more unique name).

The spec has a requirement for the name of the EMF bean. So I don't know if we can not give it the expected name in *all* situations.

Perhaps we can reduce the user pain by introducing a persistence unit hint to ignore the CDI/Persistence integration for a specific persistence unit for whatever reason.  This wouldn't help with TCK testing as we are not allowed to modify the persistence.xml in Platform TCK tests.

We may need to generally give such a bean the PU name, but detect this scenario and deal with it in a carefully targeted way e.g. no name or module archive name + persistence unit name just for the ear bean when we've detected a situation where a subdeployment uses the "spec" name (I guess with the same qualifier).

https://github.com/scottmarlow/wildfly/tree/WFLY-19554_cdijpa32_do_not_set_EMF_beanname_for_duplicatePUs includes a (could be improved) duplicate persistence unit check and does not currently set the bean name if the persistence unit is duplicated.  

I think this will likely require a lot of tests in our TS. I doubt we can rely on the TCK for a lot of details as we'd be testing specific WF impl behavior.

+100

I was able to add a test for looking up the EntityManagerFactory bean using @Named but that might be the wrong approach.  I'm now thinking there are two possibilities:

- Use @Named approach to name the EntityManagerBean (see example [PersistenceIntegrationWithCDI.java#L175](https://github.com/scottmarlow/wildfly/blob/46924a4d80b81605770da274691592cdd1fc3e53/jpa/subsystem/src/main/java/org/jboss/as/jpa/beanmanager/PersistenceIntegrationWithCDI.java#L175)) which allows `@Inject @Named("pu1") EntityManagerFactory entityManagerFactoryNamedBeanReference;`.
- Generate a qualifier class (e.g. pu1) and that could be used like `@Inject pu2 EntityManagerFactory entityManagerFactoryGeneratedQualiferClassReference;`.  Unless of course there is already an application class with the persistence unit name (we might need to check for that).

The @Named approach seems like a possible option to explore.

The generate qualifier class (with persistence unit name) approach seems like a possible option to explore as well.