[jboss-as7-dev] Consolidated list of non-Java EE JPA and native Hibernate issues

[Marius Bogoevici]

Jason T. Greene wrote:
> On 6/16/11 9:35 AM, Marius Bogoevici wrote:
>> 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 think you misunderstood. I was saying the use case is actually" non 
> server integrated JPA", not "hide persistence.xml". There are other 
> ways JPA can be brought in without persistence.xml.
I probably did - I thought that you were hinting to a "suppress server 
deployment, I'll use my own PersistenceProvider but still use the Java 
EE 6 approach" which is what 2. suggests me. I know that JPA can be 
brought in even without persistence.xml, but is this going to be 
supported by our own JPA deployer, which will try to bootstrap a PU even 
in the absence of a META-INF/persistence.xml found in the deployment?

But, as a matter of fact, please note that I am more in favour of a 
general 'disable JPA' than 'hide persistence.xml' approach. It just so 
happens that the source of trouble is the presence of persistence.xml 
which triggers the bootstrap process. OTOH, as Max noted, the 'hide xyz 
file' can be used as a stop-gap measure in the more general "User 
packages crazy stuff" use case.

In what concerns me, however, either of these approaches are fine.
>> 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. 
>
> The JPA plugin mechanism is per deployment.
>
>> 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. 
>
> Ok so the use case sounds valid, we need some way to completely 
> disable any usage of JPA.
>
> 4. Application managed JPA, no server involvement 

Cool.