TheServerSide.com – Comparing EJB2 to JPA – Why? I’ll tell you why.

TheServerSide.com have a question posted on their site this morning asking ‘Comparing EJB2 and JPA – why?’.

Ok so the technologies are now radically different and improved, and of course once you have seen the JPA api, there is obviously no turning back, providing you have a platform available that supports it.

These are two of the main reasons why it is important to make the comparison – the main reason – to educate developers and get them up to speed with the new EJB3.0 spec.

But surely this is such an awesome development and step forward for Enterprise Application development that any developer worth their salt will already be intimately familiar with the spec? Yes, of course it is awesome, and is how the EJB spec should have looked from day 1. The main problem I am seeing from working within my own Java developer community is that developers who will most likely be using EJB3.0 tomorrow are already entrenched in EJB2.x projects today – they are so busy working on current implementations that they have not had time yet to surface and see what is going on in the world. Yes they have heard of EJB3.0, have probably not heard of it referred to as JPA, and yes they would love to have time to read the spec and have time to prototype some apps, but they’re too busy right now.

It’s ‘the curse of the long running project’ – projects that were scoped and designed as long as 2 or even 3 years ago are still knee-deep in development implementing functionality on top of whatever technologies were chosen during the project’s inception. For 2-3 year old projects coming to a close, this is likely to be J2EE 1.3 and yes they are still using EJB2.x. If you’re lucky a long-running project may have in it’s contract the allowance to upgrade to latest API and technology releases along the way, but in most cases this is unlikely since this most likely does not buy the customer any inprovement in functionality, although may be desirable for long time maintenance.

Creating a deployable WAR file

When running ‘grails’ from the command line, the list of available targets does not list the target for creating a deployable WAR file.

‘grails war’ creates a packaged WAR file that can be deployed to a servlet container.

NoSuchMethodErrror StringUtils.isBlank() when deploying Grails WAR to JBoss 4.0.1

Deploying a Grails 0.1 WAR to JBoss 4.0.1 I get this exception:

<code>
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'grailsApplication' defined
in ServletContext resource [/WEB-INF/applicationContext.xml]: 
Initialization of bean failed; nested exception is java.lang.NoSuchMethodError: 
org.apache.commons.lang.StringUtils.isBlank(Ljava/lang/String;)Z
	org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:370)
	org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:226)
	org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:147)
	org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:269)
	org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:320)
	org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:134)
	org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:246)
	org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:184)
	org.springframework.web.context.ContextLoaderServlet.init(ContextLoaderServlet.java:83)
	javax.servlet.GenericServlet.init(GenericServlet.java:211)
</code>

This seems to be a Commons Lang jar issue, and does not occur if deploying Grails web apps to JBoss 4.0.4+

Update: This is an issue with the JBoss Unified ClassLoader when deploying to a JBoss server with other webapps including other possibly different versions of the same jars. The solution is to disable the Unified ClassLoader.

Disabling the use of the JBoss Unified Class Loader in this file:

/jboss/server/default/deploy/jbossweb-tomcat50.sar/jboss-service.xml

changing this line:

<code>
&lt;attribute name="UseJBossWebLoader"&gt;true&lt;/attribute&gt;
</code>

to

<code>
&lt;attribute name="UseJBossWebLoader"&gt;false&lt;/attribute&gt;
</code>

New Hibernate book on the way from the Hibernate team

Christian Bauer has an update on the Hibernate blog about the status on the second edition of the Hibernate in Action book. Apparently there has been so much additional material added to the book that they’re changing the name to ‘Java Persistence with Hibernate’.

The new book will cover Hibernate 3.0 features in addition to Java Persistence API features (EJB3.0 Entities).

Can;t wait to get a copy of this one, as HiA in my opinion was and still is the best Hibernate book published.