It’s Only Software

I have noticed a trend recently among some folks in the Java world, where it is simply taken for granted that an ORM provider (usually Hibernate) will be automatically inserted in the technology stack of any new project. Quite often, this happens with little to no technical justification or analysis. If you’re reading this and nodding your head, this should be frightening to you. The reason is that if the use of an ORM isn’t required, it can cause projects (especially small ones) to have unneeded complexity. Additionally, abstraction without understanding what’s underneath can set a dangerous level of ignorance on the part of developers, who will simply collapse when the abstraction breaks and critical thinking through the abstraction is required to solve a problem.

In that spirit, I recently worked on a personal project to learn how one can write dead-simple plain old JDBC applications using only Spring Framework 2.5 without an ORM layer. Spring 2.5 has many features that provide some of the convenience of ORM libraries (simple mapping from ResultSets to Objects), some convenience above and beyond ORM libraries (mapping from ResultSets to primitives!*), and removes some of the complexity (caching, cascading, etc.). For applications with fewer tables than you have fingers on your hand, this can greatly ease development.

I’ll assume you already know how to work with Spring, and at least know (or can dredge up) the basics of JDBC. We’ll work through a simple example, mapping the ubiquitous “Person” table to a Person object, and back again through an insert operation. Hopefully this will open your mind to non-ORM solutions. I promise that in 5 minutes (or less!) you will be amazed at the things you can do with simple JDBC

Continue reading “5 Minute Guide to Spring and Simple[r!] JDBC”

Hate this dialog?

Seen here and here. Posting so I don’t forget how to remove this darned thing in the future. Since I rarely shut my machines down, I find the dummy-proof-update feature of Windows incredibly annoying.

Tomcat 6 does not ship with an implementation of JSTL. I decided to write up this quick start guide, since it’s really, really hard for new folks to know how to get started with Spring MVC (which is very often combined with JSTL) on Tomcat 6.

Sadly, Sun’s JSTL site does not even point you at the actual reference implementation of JSTL 1.2 (at least there’s no very obvious link that I have been able to find - but what good would a Sun web site be if it was easy to find what you were looking for? ).

The Apache Jakarta Taglibs project is the source of JSTL 1.0 and 1.1 reference implementations, but it is no longer maintained and will never implement JSTL 1.2.

The JSTL 1.2 reference implementation has been folded into the Glassfish application server. It seems that Sun in its infinite wisdom has decided to make the reference implementation almost impossible to find. The link to “Reference Implementation” on the JSR-052 page points you to the Sun Java EE download page (argh!)

So, how do you get this installed on Tomcat?

• Download the latest version of Glassfish V2 application server here.
• Unzip/install to a directory
• From the “lib” directory of the install, copy the appserver-jstl.jar and javaee.jar files to one of two locations:
  • In the WEB-INF/lib directory of your web application. This is preferable because you can ensure that the correct version of JSTL lives with your application. The downside is that you may run into classloader issues when running on application servers other than Tomcat which supply their own (conflicting) JSTL implementations.
  • In the {tomcat-install}/lib folder. This will make the JSTL 1.2 libraries available to all web applications. This may cause classloader issues if web applications have their own versions of these classes, and as such is not recommended (but it will work).

Be aware that there’s a nasty bug with the JSTL/JSF 1.2_07 RI that I’ve blogged here. For you Spring MVC’ers trying to get started with the latest versions of Tomcat and JSTL, hopefully this helps you!

I guess I’ve had a busy / buggy weekend noodling around with stuff. I ran into a [known] bug in the latest JSTL/JSF 1.2 Reference Implementation on Tomcat 6.0.14.

I was playing around with Spring MVC 2.5.1, and even the simplest JSP page gave me this:

java.lang.NullPointerException
	com.sun.faces.application.WebappLifecycleListener.syncSessionScopedBeans(WebappLifecycleListener.java:312)
	com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:87)
	com.sun.faces.config.ConfigureListener.requestDestroyed(ConfigureListener.java:240)
[snip]

This is interesting, because I wasn’t even using JSF!

It turns out that there’s a bug that is lightly documented in the JSTL/JSF 1.2_07 RI release notes:

There is a chance for an NPE in com.sun.faces.application.WebappLifecycleListener with some configurations (see issue 670). Take for example, installing JSF in a container such that JSF will be available to all web applications. The NPE will occur for an application that doesn’t have the FacesServlet defined within it’s web.xml.

The workaround for this issue is, within the global web.xml for the container (JBoss and Tomcat both have one) add either a FacesServlet definition (no mapping) or add the context init parameter, com.sun.faces.forceLoadConfiguration, with a value of true. NOTE: GlassFish is not affected by this issue.

This is also covered in the Mojarra bug database as bug 670, and the JBoss bug database as bug JBAS-5063.

There’s some discussion in this JBoss forum thread indicating how to solve for JBoss AS, which is a good start.

For Tomcat 6, you can add the following to context.xml:

	<Parameter name="com.sun.faces.forceLoadConfiguration" value="true"/>

One caveat here is if you’re running an Eclipse-based Tomcat instance. Eclipse-configured Tomcat doesn’t have an easily accessible context.xml. Instead, you’ll have to configure this in the global default webapp. Look in your Eclipse workspace for the server configuration (by default, Eclipse will put this in a top-level project called “Servers”).

In the web.xml you’ll find in there, add the following:

 <context-param>
  <param-name>com.sun.faces.forceLoadConfiguration</param-name>
  <param-value>true</param-value>
 </context-param>

This should not be put in your web application’s web.xml!

Once you do this, you should not receive the NullPointerException upon first access to a JSP. It looks like this bug will be fixed in the next RI release of JSF/JSTL.

I was banging my head against the wall due to this problem. Apparently there is an issue with Spring IDE 2.0.2 running on a Java 6 platform - simply put, it doesn’t work. There’s a JIRA filed on this, along with some discussion [#1], [#2]in the Spring forums. I reverted to manually installing Spring IDE 2.0.1 from the update site (unzip, then use eclipse -clean), and it worked again.

This was on a brand new Eclipse 3.3 install with no prior trace of the Spring IDE plugin

Hopefully this helps someone. The error that I saw upon startup of Eclipse was:

java.lang.NoClassDefFoundError: Could not initialize class org.springframework.core.CollectionFactory
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.<init>(DefaultSingletonBeanRegistry.java:86)
at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.<init>(FactoryBeanRegistrySupport.java:40)
at org.springframework.beans.factory.support.AbstractBeanFactory.<init>(AbstractBeanFactory.java:146)
at org.springframework.ide.eclipse.beans.core.DefaultBeanDefinitionRegistry.<init>(DefaultBeanDefinitionRegistry.java:72)
at org.springframework.ide.eclipse.beans.core.internal.model.BeansConfig.readConfig(BeansConfig.java:707)
[snip]