Today, we attended the Sun Tech Days Conference at the Makati Shangrila. Aside from the great food and freebies, I enjoyed the whole experience. There were several things I learned during the second day of the 3-day conference. Here’s to recap what I learned and observed:

• Java 6 has some nice features including Scripting Language Support (JSR 223) and Web Service Integration. I agree that these 2 features are very common and should be part of the standard Java. I’m not sure about JDBC 4.0; with the success of JPA, JDBC might not be that useful anymore.
• Grails is cool, but not necessarily great. I think it still needs improvement to be able to compete in the enterprise, if at all possible. My main concern with template codes is “customizability”. But it’s still cool.
• Sun admitted their problems with Java 6, such as slow start-up and large codebase. I think this is a good sign for the future of Java.
• Netbeans has improved since I switched to Eclipse three years ago. It supports a ton of platforms/frameworks and has a lot of productivity tools. I believe Netbeans is probably worth revisiting.
• Half of the conference attendees are going to the Enterprise track, which means there is more demand for web applications development rather than desktop (Swing, SWT) or system administration.
• The “new” technologies that the speakers discussed were the same technologies two years ago. We have been already using these technologies (such as Ajaz, JPA, and ESB) in our projects. Either Sun didn’t do a good job in looking for resource persons, or Ideyatech is just updated with the latest technology! (The latter is most probably true… hehe) Anything else new?
• Open-source is confusing - everyone else wanted to be the best platform/framework, and developers are confused which one to use. Even Sun promotes several conflicting/competing technologies - Seam vs. Grails vs. JSF, JDBC vs. JPA, GlassFish vs. JWS. With the myriad of platforms available, which one works best?

Has anyone ever tried looking at OSWorkflow recently? It is unfortunate that this OpenSymphony project has been shelved. However, I found value in this lightweight workflow tool — for one, being lightweight makes it simple and easy to work with, plus, integration with Spring and Hibernate is readily available.

However, since OSWorkflow stopped development, there had been no support for JPA-based applications anymore. Fortunate for those interested in making JPA work on OSWorkflow via Spring, I was able to tweak some of the OSWorkflow classes and integrate it with JPA Session.

The primary problem in integrating OSWorkflow with JPA is the Session. The original session used by OSWorkflow (SpringHibernateOSWorkflowStore) is a sessionFactory injected via Spring. Since JPA uses EntityManager, the sessionFactory and EntityManager are on different transactions.

The solution is to extend AbstractHibernateWorkflowStore and use session from EntityManager. Here’s the code:

public class JPAHibernateWorkflowStore extends AbstractHibernateWorkflowStore {
    @PersistenceContext
    private EntityManager em;

	@Override
	protected Object execute(InternalCallback action) throws StoreException {
        try {
    		return action.doInHibernate((Session)em.getDelegate());
        } catch (StoreException e) {
            throw new RuntimeException(e);
        }
	}

	public void init(Map arg0) throws StoreException {
		// TODO Auto-generated method stub
	}

	/**
	 * @param em the em to set
	 */
	public void setEntityManager(EntityManager em) {
		this.em = em;
	}
}

Afterwards, use JPAHibernateWorkflowStore instead of SpringHibernateWorkflowStore as your workflow store. You will also need to copy HibernateCurrentStep.hbm.xml, HibernateHistoryStep.hbm.xml and HibernateWorkflowEntry.hbm.xml (under com.opensymphony.workflow.spi.hibernate3) to META-INF (along with persistence.xml). This will ensure that hbm mappings are recognized by the EntityManager.

Well, that’s basically it. If you are having a hard time following my instructions, try getting the standard SpringHibernateWorkflowStore to work first. Afterwards, change implementation to JPA-based approach.

Ciao!