Vita Rara: A Life Uncommon

JPA

Integration Testing Struts 2, Spring, and Hibernate JPA


Categories: | | | |

Last night with the help of loraxorg on the Spring Forums I got integration testing working under Maven 2 with Struts 2, Spring, and Hibernate JPA working. This was failing priorly due to a transient dependency in Maven 2 to an old version of Xerces. (See the Spring Forum thread for the solution.)

I have not done a lot of test driven development in the past, and personally I don't really get a lot of value out of isolated Unit tests. Integration testing on the other hand I like. Real data, real connections, real functionality, and at the moment for me real failures. I'd rather know now though.

Getting a Transactional EntityManager in a JpaDaoSupport Derived DAO


Categories: | |

In Quadran my Data Access Objects (DAO) are descendants of JpaDaoSupport. JpaDaoSupport provides nice one liner convenience methods for finding entities and such. Sometimes though I find I need to actually get a handle to a JPA EntityManager. If you do this, and you are using Spring's transaction support it is important that you get the EntityManager in the proper way. Otherwise you will get an EntityManager that is not bound to the transaction, and will not be closed when your transaction completes and commit its changes, or close the session.

When I first tried getting an EntityManager I used the following code:

Web Page Data Models: Where do they go? Part II


Categories: | |

Well, I finally decided where they go. At least for the Quadran project. My package structure looks like this:

Maven Jetty Plugin Logging


Categories: | | |

I've gotten Maven, Jetty, Spring, and JPA playing well together! I've ecstatic. Bye, bye JBoss. I don't know that I'll never run JBoss for development again, but I don't think it will be common.

Anyway, upon getting the Jetty Maven Plugin working (mvn jetty:run) it was logging too much debug information. Hitting one page ran out a 10,000 line buffer on my terminal. There was a simple quick fix though. Add a few properties to the plugin configuration in your POM file and voila, reasonable logging.

Kicking the JBoss Habit: JBoss, JPA and Spring? Or Spring and JPA?


Categories: | | | | | | |

Hi, my name's Mark and I'm a JBoss user.

Ok now everyone.... "Hi Mark."

I have been a JBoss user for many many years. It all started with the seductive siren of Enterprise Java Beans. I still have a deployed application running on 2.4.3, or something like that. (Behind a firewall, thank heavens.) Well, today I took a few more solid steps toward kicking the JBoss habit.

If you've followed this blog you'll remember that I'm working on an ERP application for a client, Quadran. Yesterday I fought with query issues and JSP reloads for hours. With JBoss it's compile, package, re-deploy, wait. Change a few characters, compile, package, re-deploy and wait! It finally got to me.

JBoss 4, EJB 3 Entities (JPA), and Spring


Categories: | | | | |

Over the last week or so I have been working on getting JBoss, JPA and Spring working together. When I wrote my previous entry I thought I had everything working. Well, up to that point I had not tried to save a record to the database. When I tried to do that nothing happened. This lead to a long debugging process that felt more like a hopeless goose chase at times. With the help of Costin Leau on the Spring forum I finally got it working, but it was quite the trial. Not many people have attempted to get this combination working. One of the things that complicated my setup is that my data access objects are a descendant of the JpaDaoSupport class provided in the Spring framework.

JBoss 4, JPA, @PrePersist and Primary Key Generation


Categories: | |

JBoss 4, JPA, @PrePersist and Primary Key Generation

In a past project I started using globally unique ID's (GUID) using XDoclet. I really like this methodology and planned on using it in Quadran.

So, I wrote my classes and was generating the ID's in the persist method of my data access objects (DAO). This didn't work very well, because when my persist would cascade the dependent objects did not have their ID's set, and Hibernate, which is JBoss uses to implement JPA, would throw an exception.

So, to work around this I started traversing the graph of objects in my business classes and setting the ID's before I handed them to the DAO's to be persisted. This was ugly, so I went in search of a better solution.

Quadran Update


Categories: | | | | |

This has been a very frustrating week. All in all I worked on working. I'm fried. I'm going for ice cream.

Got JBoss, Java Persistance API, Spring and Webwork Playing Nice

Over the past few weeks I've coded the data layer of Quadran using EJB3 (JPA) and making data access object that subclass from Springs JpaDaoSupport class. Coding all of this and getting it deployed on JBoss was fairly straight forward. The interesting part came when I tried to instantiate the DAO's from Spring and inject the EntityManager instance. That was fun. Stay tuned for a HOWTO in the near future.

I also got WebWork mixed into this all. That was actually quite easy. Getting JBoss and Spring to play nicely was the hard part.

Frustrating Days in Quadran Land


Categories: | | | | | |

The past week or so has been one of frustration. It seems like I have been working on working. I've been setting up Spring, and WebWork, creating the skeleton of WebWork action classes. All in all a lot of busy work.

In the course of creating the JPA implementation of our data layer I used the JpaDaoSupport from the Spring framework. This caused some boot strapping issues when I went to get all of this running under JBoss 4.0.4.GA. The persistence archive deployed perfectly, but it was bear from that point out getting the DAO's to work. I think I have it figured out, and will post a HOWTO once I have it all working.

Syndicate content