I have no idea what any of this means, but I know people use JPA with TorqueBox applications. Marek Goldmann put one together today. I dunno if shifting to purely annotation-based would help or hurt us. -Bob On Jun 9, 2011, at 3:37 PM, Scott Marlow wrote:

On 06/09/2011 04:16 PM, Bob McWhirter wrote: You shouldn't have to change anything. Its more of me being paranoid that I'm going to screw up the case where applications have their own hibernate jars.

On 06/09/2011 04:52 PM, Scott Marlow wrote: Yeah, it would be for the best. I've submitted https://issues.jboss.org/browse/AS7-946 with a tentative approach for this. I'm also trying something on the file exclusion thing that I mumbled about on IRC yesterday.

On Friday 10 June 2011 01:07 AM, Scott Marlow wrote: 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? 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. 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? 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 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. 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)? -Jaikiran

On 06/10/2011 06:24 AM, Scott Marlow wrote: I got it down to this set locally (probably a 7.1 change at this point): javax.persistence.api org.jboss.as.jpa org.hibernate

As per the discussion that Scott and I had on IRC earlier, I tried to summarize the current issues that we encounter outside the confines of strict Java EE usage, for non Java EE JPA and native Hibernate applications (with Spring apps being a subset of the larger Hibernate application set), as well as some possible workarounds and some possible solutions - some of these have working prototypes, for some others we need to decide the direction in which we want to go (e.g. fail-fast vs. more precise validation vs. runtime failures and so on). It would be ideal if we could address some of these issues pre-7.0, if not, then at least we should have a working plan for 7.1. http://community.jboss.org/thread/168089

On 06/16/2011 04:02 AM, Max Rydahl Andersen wrote: Sounds to me like AS7 should ignore persistence.xml definitions that have PersistenceUnitTransactionType of RESOURCE_LOCAL. I think we currently just pass the PU definition to Hibernate, which is wrong. I created AS7-1034 for this change. Max, do you have a simple test case archive (representative of the typical Hibernate 3 native JPA app) that you could attach to AS7-1034?

On 06/16/2011 08:18 AM, Scott Marlow wrote: We previously could work around issues like this via jboss-ignore.txt. That could help here or perhaps something specific to JPA would be better.

Max Rydahl Andersen wrote: Well, Java EE JPA1 works ootb. Spring + Hibernate3 needs to package their own jars - this affects mostly users that used the Hibernate 3 version packaged on the server. IMO there is is also an option to have a Hibernate 3 module.

On 6/16/11 8:53 AM, Marius Bogoevici wrote: Theres some discussion on IRC about the JPA issues. Stuart has a patch that prevents "non EE components" from acting on JPA annotations. We should definitely fix that bit (which will allow spring to work): https://issues.jboss.org/browse/AS7-1031 -- Jason T. Greene JBoss, a division of Red Hat

On 6/16/11 9:00 AM, Marius Bogoevici wrote: I have nothing against an ignore mechanism, but if we want JPA plugability the proper mechanism for that is the spec described JPA provider mechanism which will be in 7.1. -- Jason T. Greene JBoss, a division of Red Hat

Jason T. Greene wrote: Right. The ignore mechanism is much more limited and in the case of Spring apps serves a different purpose (give total control of PU creation to the application itself, the server becomes completely agnostic of the fact that there even is a PU). The nice thing about ignore is that it can help if people package things which would conflict with the server. You'd better not do that to begin with, but sometimes this is how migrations start.

On 6/16/11 9:20 AM, Marius Bogoevici wrote: 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.)? -- Jason T. Greene JBoss, a division of Red Hat

On 6/16/11 9:35 AM, Marius Bogoevici wrote: 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. The JPA plugin mechanism is per deployment. 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 -- Jason T. Greene JBoss, a division of Red Hat

<snip/> On 06/16/2011 10:43 AM, Jason T. Greene wrote: Perhaps we could do this via jboss-deployment-descriptor.xml We could add a <ignore-persistence-units/> (or a more aptly named element) on an individual deployment/subdeployment.

On 08/30/2011 10:52 AM, Scott Marlow wrote: https://issues.jboss.org/browse/AS7-1128 I started prototyping something a while ago then it couldn't make it to 7.0 so I slacked it off. Need to bring back though - I can get back to this next week, unless anyone wants to take over beforehand. One issue that I have encountered for a generic implementation was that deployment processors read files directly from VFS, so we cannot easily incorporate the information from jboss-ignore.txt in the deployment process (as it was the case with the MC-based deployers, where Ales added the jboss-ignore.txt processing into one of the superclasses). So, I'm wondering what is the best way of handling this: a) Adding an intermediate DeploymentResources object that sits on top of VFS and incorporates the filtering information from jboss-ignore.txt . Deployment processors would use DeploymentResources to get a filtered view of the deployment resources instead of using VFS directly. b) Using jboss-deployment-structure.xml for dedicated deployment instructions (<ignore-jpa/>) c)? My preferred alternative would be a), perhaps incorporating filtering rules in jboss-deployment-structure.xml. Thoughts?

On 08/30/2011 11:41 AM, Jason T. Greene wrote: Surely, you would need to know what you disabled. The one use case that I can think of is to tell the server to ignore persistence.xml (or suppress PU deployment). There may be some other cases, like legacy projects which happen to have a beans.xml file in the wrong place (but aren't necessarily CDI deployments). It could become useful if future versions of Java EE start adding configuration files which are likely to break current deployments. As I said, I believe that there is always room to create specific instructions for specific types of deployments instead of blocking out files outright - the problem is that each type of 'disable xyz' action would need to be implemented separately. Not sure if that is an issue. I never had classloader exclusion in mind (and wouldn't that be part of resource filtering?). The intent simply was to leave the files on the classpath (if any part of the deployment wishes to use them) but tell the deployers not to use them.