At the risk of demonstrating a lack of adequate context to contribute to the discussion...
One preference expressed at our shop is to eliminate the notion of "defaulting" to an EntityManager. That is, pursue an API that provides explicit readability as to which EntityManager/persistenceUnitName is being invoked. In addition, the API should enable multiple alternative EntityManagers during JUnit testing. Here is the type of testing use case typical in a large shop: 1. A standard JUnit tests uses H2 as an embedded database. 2. A 'special case' Stored Procedure test uses the application SQL Server database (DEV instance). 3. A 'special case' View test accesses a legacy DB2 database. In this scenario items #1 and #2 require at least one alternatve and #3 requires a unique persitenceUnitName. And of course there are additional scenarios where more than one alternative is required. So perhaps for some, the idea of an API providing "magic" defaulting is less attractive than explicit in-line readability. _Marvin -----Original Message----- From: Thomas Hug (JIRA) [mailto:j...@apache.org] Sent: Friday, January 22, 2016 6:50 AM To: deltaspike-...@incubator.apache.org Subject: [jira] [Commented] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers > When an application uses multiple {{EntityManager}}'s, there must be a way to > specify which one(s) should be used
