JTA no longer transitively provided (HHH-10178) causes problems for apps not using JTA
Description
Attachments
- 03 Jan 2016, 02:27 AM
caused by
Activity
Steve Ebersole January 8, 2016 at 2:50 PM
I think simply reverting https://hibernate.atlassian.net/browse/HHH-10178#icft=HHH-10178 is going to be the best option here.
I had looked into possibly using javax.transaction:jta instead of org.apache.geronimo.specs:geronimo-jta_1.1_spec. Both are licensed under CDDL so licensing would not be a concern. However, javax.transaction:jta does not define any OSGi metadata where as org.apache.geronimo.specs:geronimo-jta_1.1_spec does. Thus moving to javax.transaction:jta would require a "wrap" instruction in our OSGi support; wrap instructions should be avoided.
Steve Ebersole January 8, 2016 at 2:23 PMEdited
First, let's not call these implementations 🙂 I think that's partially where this confusion that these JARs are more that just the spec JARs.
Licensing is definitely an argument to consider. I did some digging and the javax.transaction:jta artifact is licensed under CDDL.
Other than licensing, none of these apply to JTA. Yes, the "availability" angle is certainly valid as a spec is going through approval and even for a short time afterwards. But JTA 1.1 was released in 2006 😉
Emmanuel Bernard January 7, 2016 at 4:42 PM
JBoss projects moved to JBoss owned implementations for a few reasons. I can remember the following:
being able to fix bugs for users and customers
licensing is a bit unclear on the javax.* (they were not under an OSS license, don't know now) so we wrote our own
during Java EE implementation cycles, Oracle is late in releasing intermediary artefacts so we rolled our own
some JAR have specific code to prefer the container impl as opposed to the first one found, so controlling that is nice
Steve Ebersole January 7, 2016 at 3:26 PM
@Emmanuel Bernard Yes, for sure we will need to specify JTA transitively. The question is really about (1) which JTA GAV to use and (2) how to expose it. For the second there really is not an option I believe, as this is not something Maven POMs offer an option for (recognizing that all these JTA GAVs are really just different "names" for the same artifact). For the first, this is my personal order of preference:
org.apache.geronimo.specs:geronimo-jta_1.1_spec- this is the one we have transitively "exported" for a while now. That continuity is good in terms of exclusions.javax.transaction:jta- given that there is not a valid forgotten reason we did not use that in the first place. I guess I could be argued into this being the first option too
Additionally we moved away from org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec due to bugs in their OSGi metadata. I don't see a compelling reason to go back to that one.
Emmanuel Bernard January 7, 2016 at 12:32 PM
Looking at it from afresh with no historical ties into HHH-10178, I think us having org.hibernate.Transaction#registerSynchronization(javax.transaction.Synchronization) makes it a clear cut, we need the dependency transitively.
If we remove that, we can rethink it but that's another story.
Hi,
After the upgrade to 5.0.4 (Maven environment so dependencies are OK), we started to have the following Exception at the start of our Spring context which cannot initialize the entityManagerFactory anymore:
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class fr.openwide.core.basicapp.core.config.spring.BasicApplicationCoreCommonJpaConfig: Invocation of init method failed; nested exception is java.lang.NoClassDefFoundError: javax/transaction/SystemException Caused by: java.lang.NoClassDefFoundError: javax/transaction/SystemException Caused by: java.lang.ClassNotFoundException: javax.transaction.SystemException5.0.3 works fine.
–
Guillaume