On 06/10/2011 03:13 AM, Jaikiran Pai wrote:
On Friday 10 June 2011 01:07 AM, Scott Marlow wrote:
>
> This is wrong I think. We probably only need to look for the presence
> of @PersistenceUnit @PersistenceContext and same in deployment
> descriptors (which we currently also do).
In earlier versions of JBoss AS, we used to (optionally) bind the
EntityManager and the EntityManagerFactory to a global JNDI name within
the server. This was a JBoss specific feature (@see
jboss.entity.manager.jndi.name and
jboss.entity.manager.factory.jndi.name in Table 3.1 here
http://docs.jboss.org/ejb3/docs/reference/1.0.7/html/entityconfig.html).
Do we still do this in AS7 or do we plan to do this? Probably allow them
to bind to java:jboss/ namespace?
We already support some other global abilities to reference PUs in other
applications (). I'm not against adding support for the
jboss.entity.manager.jndi.name + jboss.entity.manager.factory.jndi.name
extension into AS 7.x.
The reason I ask this is because if we introduce this feature, then just
relying on @PersistenceUnit and @PersistenceContext annotations won't be
enough, since users might lookup the EntityManagerFactory/EntityManager
via JNDI and in such cases too we will require the JPA module
dependencies to be added implicitly.
It would be nice if users had the ability to explicitly mark a
deployment as an EE JPA deployment or not a EE JPA deployment.
>
> I don't want to inject the JPA dependencies just because there is
> persistence unit definition (we can still parse it and have it available
> for use).
>
> This might help us deploy native Hibernate applications that don't use
> EE JPA.
I haven't looked at the code related to this (yet), but I'm curious
about how this works and whether this implicit Hibernate dependencies is
going to cause any issues. So:
1) When we say, we are adding implicit JPA dependencies to the
deployment, what exact modules are we adding? JPA spec API module
(javax.persistence.* classes) is fine. Are we adding Hibernate module as
a dependency too?
In JPADependencyProcessor, we are currently adding modules:
javax.persistence.api
javaee.api
org.jboss.as.jpa
org.hibernate
org.javassist
org.jboss.as.naming
We might not need all of these any more (javassist + naming especially).
2) If we are adding a implicit Hibernate dependency, then, is there an
(easy) way for users to specify that this implicit Hibernate dependency
*not* be added? That way, users can package their own version of
We should introduce a way for that to be expressed. We currently don't
have an easy way for users to specify that. It might be as easy as
detecting that a persistence provider is already packaged with the app.
I'd like a way to:
- Choose which persistence provider to use for deployment.
- use something like jboss-ignore.txt (used in earlier releases) to
ignore the provider jar in a deployment
- Perhaps adding extensions for provider version tags.
- Add a provider toolkit, that allows additional metadata/tooling for
using the provider on AS7+. One question is whether the SPI for this
belongs in the AS7 project (obvious advantages to that) or should be
external.
Hibernate within their deployments. Note that this is probably going
to
be pretty common question from users, because in AS7 we are shipping
Hibernate 4.x version which isn't yet used by many applications.
Hibernate 3.x is the stable version, so I believe users would want to
package that version in their app and use it.
Either package it or share it as a top level deployment. I looked at
this a bit but pushed it off to 7.1 as it didn't seem to be a priority
for AS 7.0.
3) If we are adding a implicit Hibernate dependency, then, is there an
(easy) way for users to use a different JPA provider (like EclipseLink)?
Not yet but I want to get there soon. We do keep a
(PersistenceProviderResolver) global list of providers that could be
made more dynamic (to at least support providers that are top level
deployments). We will need to introduce a persistence.xml version tag
property, to uniquely identify different instances of the same provider
class.
-Jaikiran
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev