The process of lamination

Friday we tried several things as we tried to figure out what was causing our .war project not to be able to see the JTA transaction manager, but we did not arrive at a solution.  Let’s see if the Lord will bless us thereto today!

Ok, Keith gave me a couple of things to try.

Messier than necessary

First, let’s get our pom file to where we want to start with it this morning.  Looking over it, I see that I have more clunkiness than I think I need.  In my dependencies section, I have:

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate</artifactId>
    <version>3.2.6.ga</version>
    <exclusions>
        <exclusion>
            <groupId>cglib</groupId>
            <artifactId>cglib</artifactId>
        </exclusion>
        <exclusion>
            <groupId>asm</groupId>
            <artifactId>asm-attrs</artifactId>
        </exclusion>
    </exclusions>
</dependency>

And then farther down, I have

<dependency>
    <groupId>asm</groupId>
    <artifactId>asm</artifactId>
</dependency>

<dependency>
    <groupId>asm</groupId>
    <artifactId>asm-attrs</artifactId>
</dependency>

So, I’m excluding asm-attrs, but then explicitly bringing in the versions of asm and asm-attrs that I have up in my dependencyManagement section.  Up there I have this:

<dependencyManagement>
    <dependencies>
        ...
        <dependency>
            <groupId>asm</groupId>
            <artifactId>asm</artifactId>
            <version>2.2.3</version>
        </dependency>

        <dependency>
            <groupId>asm</groupId>
            <artifactId>asm-attrs</artifactId>
            <version>2.2.3</version>
        </dependency>
        ...

I think I’d like to simplify this.  I shouldn’t need to exclude the asm-attrs transitive dependency from the hibernate dependency and then turn around and pull it in separately, explicitly — my dependencyManagement section should control which version of asm and asm-attrs comes in via transitive dependencies.  So, leaving asm and asm-attrs in the dependencyManagement section to force version 2.2.3 of each of those, I’ll remove the asm-attrs exclusion from my hibernate dependency, yielding this:

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate</artifactId>
    <version>3.2.6.ga</version>
    <exclusions>
        <exclusion>
            <groupId>cglib</groupId>
            <artifactId>cglib</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Now when I build the project, I see in the Referenced Libraries that I have the asm-2.2.3 and asm-attrs-2.2.3 jar files — good.  (Deploying, I still have the No JTA UserTransaction available error, but that’s as expected — I didn’t expect this to fix that.)

Pulling in more Hibernate libraries

Keith says that there are a few other Hibernate libraries that my project may need, to avoid accidentally using possibly-incompatible versions provided by JBoss.  So first of all, am I already pulling in any of these?

Looking again at my project’s Referenced Libraries, I see that hibernate-3.2.6.ga.jar is the only hibernate* jar file there.  So, I reason, putting these extra dependencies in the dependencyManagement section won’t be enough in my case.  The dependencyManagement section says, “If you need this dependency, use this version” but right now my project says “we don’t need this dependency”.  I need to assert that we do.  So I’ll add these five new items the dependencies section of my pom file:

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-annotations</artifactId>
    <version>3.3.1.GA</version>
</dependency>
<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>3.0.0.ga</version>
</dependency>
<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-search</artifactId>
    <version>3.0.0.GA</version>
</dependency>
<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>ejb3-persistence</artifactId>
    <version>1.0.1.GA</version>
</dependency>
<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-commons-annotations</artifactId>
    <version>3.0.0.ga</version>
</dependency>

Same error as before.

Checking Hibernate’s Transitive Dependencies

Ok, let’s see if it’s the Hibernate jar itself, or one of its dependencies, that’s causing the UserTransaction to not be found.  I see in the hibernate-3.2.6.ga.pom that Hibernate has these dependencies:

Required: cglib, ehcache, jta, commons-logging, asm-attrs, dom4j, antlr, asm, commons-collections

Optional: swarmcache, jboss-cache, jgroups-all, c3p0, jacc, oscache, proxool

Provided: ant

I see by glancing over the Referenced Libraries that none of the Optional libraries are being included in the .war file at the moment.  So I’m adding exclusions to the hibernate dependency to exclude all nine required libraries (plus the ant one for good measure).  I rebuild and deploy and… the UserTransaction is found.

Solution!!!

I un-excluded the dom4j, antlr, asm, commons-collections, and ant dependencies and redeployed… and again no error.

I un-excluded commons-logging and asm-attrs and redeployed…still no error.

Unexcluded ehcache…still good. That must mean it’s the jta dependency.  Let’s try unexcluding that to verify…yup.  When we don’t exclude the jta dependency, we get the blowup at deploy time!

Didn’t we try excluding that Friday??

Now I uncomment the code in the DAO class that uses the Hibernate classes and uncomment the guts of the Hibernate Spring bean file and deploy and… still it deploys ok.  Wow!

I place a message in the JMS Queue and the messagelistener picks it up, like old times.  Wooha!

Next steps

It’s been a winding road, but it sure seems like we’re close to our original goal of trying out XA.  I think what we have left is:

  • Write code to do a database write using our DAO (shouldn’t be difficult, should it? :)
  • Hook things up to the webservice call handler (I need to figure out what Keith had in mind for this)
  • We may also have to figure out that Oracle JDBC Diagnosability MBean problem (I didn’t bother configuring that in my oracle-xa-ds.xml because some class was not found, but it does put a stack trace and a SEVERE error on the JBoss console complaining about the lack of it).

Then we can try out different scenarios, such as having the messagelistener throw an exception and make sure both the message receive and the database write roll back.

Tune in next time for the stunning quasi-conclusion!

Advertisements

, , , ,

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s