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.
I've been working on Quadran a lot, and I'm creating pages for editing lists of entities. The CRUD example from the Struts 2 Showcase application does this in a very simple manner. It recreates all of the entities every time you update the list. That's fine for an example but unusable in real life.
In real life we have to present entities from our database and then put the values back into the same entities, and update our database. We can't just re-create them.
So, we'll start with a simple domain object and assume that we're using something like JPA or Hibernate to persist it via a Data Access Object (DAO), and that it contains a property called "id".
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
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.
This has been a very frustrating week. All in all I worked on working. I'm fried. I'm going for ice cream.
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.
My experiment with Eclipse isn't going very well. I did an upgrade to 3.2, which apparently hopelessly corrupted my workspace, or at least that's all I can conclude based on the evidence. I say that because I'm obviously not an Eclipse expert. My diagnosis is based on the fact that a deletion of the workspace and a re-import of the project I was working on from the file system fixed the issue.
Today, Eclipse ran out of memory and has somehow corrupted its environment such that the Java Editor is hopelessly confused, and has placed error warnings, x's, along in a seemingly random pattern in almost all of my files.
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.
More work on the data layer of Quadran. I think to myself there needs to be an easier way. I'm making every attempt to future proof the system by using interfaces, and then implementations of those. I'm also using the Data Access Object pattern, with interfaces and implementations. Unfortunately this leads to lots and lots of class files:
Eclipse has made it easier to generate the implementation classes, but it is still slow going. Once this is done th
Yesterday I decided that it was time to check out Eclipse. My development environment for years has consisted of screen, vi, and ant. I have evolved what I feel felt was an efficient system. But, as with all new beginnings it was time to take a look around and see what was out there. The obvious thing to look at was Eclipse.
I tried Eclipse some time ago, in the 2.1 era if I recall. It just wasn't stable on Mac OS X at that time and really put me off of it. My old environment was rock solid. It never quit on me and I could log in remotely, do a 'screen -dr' and have my environment right there.
I spent the better part of the weekend with "WebWork in Action" by Partick Lightbody and Jason Carreira. I did this because WebWork 2.3 == Struts 2. I wanted to come up to speed on this to make sure that I was not leaving something behind. Originally it was my plan to implement Quadran with JSF, but I'm unsure of that plan. It's a very large change for us as an organization, therefore I'm taking a more detailed survey of the landscape to see where the web framework world is.
As I've said in the past we have been a Struts 1.2 house for some time now. I do feel though that Struts 1 has run its course and that basing a new project on it would be short sighted, although I'm sure it would work, as Struts 1 is a proven framework. Therefore the evaluation of the options.