It was bugging me that it took an extra day to find out that of all the possible dependency conflicts, the jta library was the one causing the deployment problem. It bugged me for two reasons: Not only is the jta library the “obvious” cause (hmm, we can’t instantiate a JtaSomethingSomething class… I wonder if it could be the jta library that’s causing a conflict?) — but also because the jta library was my first guess. I wanted to find out, why did I abandon that guess and try everything else?
Two Flaws in my Approach
There were two aspects of my approach that led to me not recognizing that the jta library was causing the issue:
- My practice was to search only the
server\default\deploydirectory for duplicates, not realizing (well, at some level I realized it, but it didn’t dawn on me as important) that JBoss has many things that it deploys out of the
server\default\libdirectory, and these can also cause conflicts.
- I was blindly searching for classes containing the string “jta”, I guess because when the connection to the JTA connection factory worked the message in the log mentioned a JtaTransactionManager. But in the end, the classes that were conflicting did not have the Jta in their names — they had javax.transaction. Suspecting the jta library, if I had opened up this library in the Referenced Libraries in Eclipse, I would have seen that the classes were all in the javax.transaction and javax.transaction.xa packages, and realized I should search for this string instead.
Sure enough, if I expand my JarSearch search to the whole
server\default tree (and don’t mark the jta library as provided in my .war project), I see this in JarSearch’s output:
Live and learn!