Re: [jboss-as7-dev] Consolidated list of non-Java EE JPA and native Hibernate issues
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.