Jason T. Greene wrote:
On 6/16/11 9:20 AM, Marius Bogoevici wrote:
> Jason T. Greene wrote:
>> BTW let's look at the actual use cases here, and the solutions:
>>
>> 1. Native/Direct use of hibernate (no JPA)
>> - User either bundles their version or imports one on the server
>> (perhaps creating a module if they like)
>>
>> 2. Using a JPA provider other than our Hib 4 one
>> - 7.1 = javax.persistence.spi.PersistenceProvider
>>
>> 3. Using JPA annotations in non JPA/EE applications (Spring)
>> - Stuart's patch (skip EE annotations on things we don't identify as
>> an EE component)
>>
>> Feel free to add one.'"
>
> 4. I have a META-INF/persistence.xml and I want to hide that from the
> server (I'll bootstrap the PU through
> LocalContainerEntityManagerFactoryBean).
This isn't a use case, this is an implementation approach. It sounds
like the use case is "Non server integrated local JPA"
Do you know of any existing cases where we would want this over (2.)?
I disagree
on this being an implementation approach, IMO it is a
separate use case. I don't really want to use a different
PersistenceProvider or provide my own (I am perfectly happy with what
JBoss AS7 provides), I just want the application server not to act upon
my PU definition.
Existing case: Spring applications migrated straight from Tomcat, using
RESOURCE_LOCAL transaction management (or even JTA would be possible in
the case of JBOSS). They bootstrap the PU on their own through the
LocalContainerEntityManagerFactoryBean.