No persistence units are defined on EAR level. In each module I got EJBs that declare EntityManager references using @PersistenceContext annotations with no attributes (particulary, without unitName attr).

As I understood, code that insures this behaviour, resides in org.jboss.as.jpa.container.PersistenceUnitSearch:

PersistenceUnitsInApplication persistenceUnitsInApplication = DeploymentUtils.getTopDeploymentUnit(deploymentUnit).getAttachment(PersistenceUnitsInApplication.PERSISTENCE_UNITS_IN_APPLICATION);
if (persistenceUnitsInApplication.getCount() > 1) {
// AS7-2275 no unitName and there is more than one persistence unit;
throw MESSAGES.noPUnitNameSpecifiedAndMultiplePersistenceUnits(persistenceUnitsInApplication.getCount(),DeploymentUtils.getTopDeploymentUnit(deploymentUnit));
}

When referencing a persistence unit using the unitName annotation element or persistence-
unit-name deployment descriptor element, the visibility scope of the persistence unit is
determined by its point of definition:
A persistence unit that is defined at the level of an EJB-JAR, WAR, or application client jar is
scoped to that EJB-JAR, WAR, or application jar respectively and is visible to the components
defined in that jar or war.

So, why should we take into account irrelevant persistence units (declared in other modules of EAR) while the specification clearly says otherwise? I guess, fixing it would be the "one small step" towards suggested "default persistence unit" enhancement

(BTW, Oracle's OC4J supports such issue by default; it can be configured in AS-specific deployment descriptor orion-ejb-jar.xml. Maybe JBoss should introduce some JPA AS-specific descriptor too?)

Can you hack together a test ear that represents this and attach it. I think your right that there are cases that aren't ambiguous that are reported as if they are. I think a new jira could be created for this.

Some possible situations that could be handled differently (including yours):

Taking into account where the persistence unit is referenced from, if there is only one unnamed pu definition that is local to the point of reference, that should be legal (even if there are other non-local unnamed persistence unit definitions).

Including multiple unnamed pu definitions at the local level and referencing either one, would still be an error.

Including multiple unnamed pu definitions at the non-local level and needing to pick one of them (no local unnamed pu), would still be an error.

Thanks for your reply. I've created an issue (AS7-4710) on this with test EAR project attached.

As for the cases you adduced: I believe, as per the spec, we can't have unnamed PU definition(s): "A persistence unit must have a name.", only references ("expression of a dependency" without unit name specified).