Sorry if this is posted somewhere on the forum. I searched for 2 days and have found a lot of posts on the topic, but I feel some of it is outdated.

I was wondering as per the newest 'production' release of Hibernate what is 'A' suggested architecture for a production level j2ee application.

I saw some posts about using Session Beans, HibernateSession w/ThreadLocal, HibernatePlugin for Struts, and 'Open Session in View' Filter for Persistent class... which now has my brain running in circles. :-( The 'architectures' page (http://www.hibernate.org/36.html) has a lot of older and out dated stuff on it. Would be nice to do a neat little 'suggested architectures' page; Gavin!! :)

I 'think' I have an idea what to do but I wanted to get some feedback.

A little background:

We are creating a Websphere 5.02 Portal Application using WSAD5.1 and the new Struts;for portal; websphere hack; along with Hibernate - of course. We will also have a Web Services/xml integration component that mimics our UI somewhat.

After reading everthing here is what I came up with; please comment!! I am VERY open to suggestions; but have to finalize this VERY soon.

PLAN:

Generating POJOs from MS SQL Server database.
Each will extend 'Persistent' which implements Lifecycle, Validatable, Serializable. The 'Persistent' base class will also utilize the 'HibernateSession' (threadlocal pattern - using JNDI lookup) when accessing 'session'.

We are using Stateless Session Beans for Transaction management and configuring similar to: http://www.hibernate.org/173.html

We are using DAO pattern for getting lists of objects, find by ID and other similarly complicated types of queries.

A few more notes:

Planning on using a HibernatePlugin (struts) http://www.hibernate.org/105.html to initalize the JNDI reference to our Hibernate SessionFactory. As well, we will have our HibernateSession lazily do the same thing. The struts plugin will initalize the JNDI session factory at project start, otherwise the first call to the HibernateSession factory will take care of it. (important in the case of Web Services integration since Struts will be applicable.)

We will override each of the methods in 'Persistent' class dealing with 'session' to have 2 forms.
i) taking a Session as parameter (in case we want to share one we already have)
ii) using the Thread local version that already exists (or getting from JNDI as necessary)

Our session beans will utilize the HibernateSession (threadlocal) pattern as well. (HibernateSession; or a subclass); will be the only way to get a hiberate session factory.) We will be initalizing a transient HibernateSession variable in the Stateless SB at ejbCreate.


Couldn't find clear instructions on Session Bean / DAO best practices. So I hope this comes close.


p.s.


I noticed a post at: http://www.hibernate.org/43.html where they talk about Struts and session per view. I was unsure if this was a 'better' way to approach this. I've decided against it so far.





Please comment :)


Thanks

Troy

I thought I might get some feedback on my plan for the UI side of things.

As noted above I am using struts w/websphere portal 5.

Instead of reinventing the wheel... and creating a whole bunch of StrutsForm Beans (that are basically the same as Hibernate Pojos generated with middlegen) I was planning on just having the 'Persistent' base class extend struts.ValidatorForm. Then I would simply create StrutsForm wrappers which either wrap or extend from the hibernate POJOs.
This allows me to initalize compound objects (to eliminate null pointer exceptions that Struts dot notation doesn't handle very well. And also allow me to create specialized struts specific get/setters for dates and such.

I just duplicate the base hib pojo's Mapping xml for each of the wrappers.
Note: I tried to do 'subclass' but I haven't got it working yet.

Sample formbean wrapper:



public class StaffingOrderWrapper extends StaffingOrder {


private String actionFlag = null;


/**
* Employee constructor comment.
* To prevent NPE!!
*/
public JobOffer() {
super();
setOrderStatus(new OrderStatus());
setOrderType(new OrderType());
}


public String getStrutsRequiredResponseDate(){
java.util.Date dt = getRequiredResponseDate();
StrutsDate sDt = null;
if(dt != null) sDt = new StrutsDate(dt.toString());
else return null;
return sDt.toString();
}

public void setStrutsRequiredResponseDate(String date){
if(StringTools.isEmpty(date)){
setRequiredResponseDate(null);
return;
}
try{
Date dt = new Date(date);
setRequiredResponseDate(dt);
}
catch(Exception e){
e.printStackTrace();
}
}


/**
* Returns the actionFlag.
* @return String
*/
public String getActionFlag() {
return actionFlag;
}

/**
* Sets the actionFlag.
* @param actionFlag The actionFlag to set
*/
public void setActionFlag(String actionFlag) {
this.actionFlag = actionFlag;
}

}

This make it VERY easy to create a new object.. and to update you simply have an action that does something like the following:

StaffingOrder staffingOrder = staffing.findJobOffer(staffingOrderForm.getId());

// use bean mapper

PropertyUtils.copyProperties(staffingOrderForm, staffingOrder);

Got milk?

Just a bit more for review:


I mentioned above that we are going to have a web services integration into our system. We are using Castor XML for marshalling and unmarsharlling.

I used the concept of a Wrapper (actually not really wrapping as much as extending) on the hibernate POJO's by extended the 'very busy' persistent class to implement Marshalable / Validatable. Now with very limited code I can marshal and unmarshal all the hib objects to/from xml. As well as do very detailed validation using the classes generated by a 'hacked' version of Castor XML and my xml schema.

There is more to this.. but that is the jist of it!