It’s Only Software

This simple change in Spring 2.5.2 and above lets you remove boilerplate code that you have probably written for simple JDBC queries performed with the generics-aware SimpleJdbcTemplate (read my earlier 5 Minute Guide to… if you don’t know what this is). Change this:

new ParameterizedRowMapper<String>() {
			@Override
			public String mapRow(ResultSet rs, int rowNum) throws SQLException {
				return rs.getString("State");
			}
		}

Into this:

new ParameterizedSingleColumnRowMapper<String>()

The fully qualified class name is org.springframework.jdbc.core.simple.ParameterizedSingleColumnRowMapper. Neat! If you’re interested in where this came from, you can have a look at the JIRA issue SPR-4320.

As a frequent contributor to the Spring Framework user forums, I have noticed a common trend among people new to Spring MVC - they really don’t understand how to use JSTL and EL in their Spring-driven JSPs.

Although Spring MVC supports flexibility in choosing a view technology, in my [back of the napkin] estimate, at least 80% of the time it is paired with JSP and JSTL. Unfortunately, since JSP was pushed out about 4-5 years ago, a lot of the information that you find on the web is extremely dated, often going back to JSTL 1.0 syntax (or, gasp, using scriptlets!). In this article I’ll clear up the confusion around how to use JSTL with various app servers and webapp versions.
Continue reading “How to Reference and Use JSTL in your Web Application”

One of the most irritating limitations of plain JDBC is that queries with a variable number of parameters are notoriously painful to deal with. The most common case of this is with the IN clause, which by definition is intended to accept a variable length argument list. JDBC, for those who don’t know, does not allow variable-length bound parameters.

Having worked with Spring’s Hibernate abstraction (HibernateTemplate) for some time, I have gotten used to Spring’s value-added feature of expanding Collections bound to HQL parameters (it’s a shame that Hibernate doesn’t natively support this, AFAIK). I was pleasantly surprised to find out that Spring offers JDBC support for this feature as well. Here’s a simple set of examples…

Continue reading “Auto-Expanding Collections as JDBC Parameters with Spring SimpleJdbcTemplate”

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”

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 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]

I was recently checking out the sample applications that ship with Spring Web Flow 2.0. In order to build the examples, you have to run an ant build that involves the Ivy Dependency Manager.

I was doing this behind a proxy server which requires username/password authentication, which unfortunately isn’t documented in the Ivy FAQ.

In case anyone runs into this particular problem, here’s how I solved it. Set the following environment variable (note this is all on a single line - I’ve added line breaks for readability):

set ANT_OPTS=-Dhttp.proxyHost=myproxyhost -Dhttp.proxyPort=8080 -Dhttp.proxyUserName=myproxyusername -Dhttp.proxyPassword=myproxypassword -Dhttps.proxyHost=myproxyhost -Dhttps.proxyPort=8080

Replace as appropriate for your environment.

One of the reasons that I think Spring has become so popular in web applications is that there simply hasn’t been another widespread web application stack that (1) is free, (2) is not Java EE, and (3) doesn’t involve JSF.

Wicket (which I’ve written about in passing before) is a great component-based web framework that integrates nicely with Spring (and therefore Hibernate and/or JPA), making it a great choice for a web stack that looks like this:

• Wicket [web tier]
• Spring [transactional / business tier]
• Hibernate [data access tier]

But what other choice is there for a transactional / business layer if you (for whatever reason) don’t want to use Spring?

Fortunately, Dhanji Prasanna has been hard at work on a transactional framework for Guice called warp-persist.

Continue reading “Bleeding Edge Transactional Wicket Web Applications with Warp and Guice”

Spring 2.5 RC 2 has been released today, and in addition to the expected bug fixes, this release includes a fully updated version of the venerable Spring MVC Step-by-step tutorial (finally!).

It doesn’t seem that this update has made it to the main springframework.org site yet, so for now the new tutorial is only available as part of the Spring download “spring-framework-2.5-rc2-with-docs.zip” - look in the docs/MVC-step-by-step directory.

Reading through the tutorial, it is definitely much more up-to-date and verbose. Kudos to Thomas, Rick, and Portia on their efforts - this is much better than the Spring 1.x version of this document! Major improvements include:

• Nice screenshots of Eclipse IDE being used to build the various bits of the project.
• Use of convention over configuration in the early stages of the tutorial.
• Coverage of the form taglib introduced in Spring 2.0

Unfortunately, there’s still a couple things that I feel are lacking.

The tutorial seems to have been written without consideration for the new annotation-based configuration introduced in Spring 2.5 - indeed, there’s nary a mention of annotations (except for the ubiquitous @Override) in the entire document. I’m not sure why this is, considering that claims of easier annotation-based configuration have been common in Spring 2.5 announcements and even on the Interface21 blog.

Secondly, while it’s great that an extensive example has been built using Tomcat, in the real world, things are much more complicated. From spending a lot of time helping users in the Web section of the Spring forums, it is obvious that people have trouble setting up Spring on a variety of application servers that are commonly used in production (Weblogic, Websphere, etc.). It would be nice if the common app servers were at least given cursory mention.

Sadly, there’s still no coverage of the use of property editors and how they affect form binding. This is a common source of confusion as well, even among Spring veterans. Even a simple example of binding a Date would save a lot of confusion. Actually, expanding the form section into a couple more complex examples (including select and checkbox tags, please!) would be extremely helpful.

Finally, while it’s not strictly in the purview of Spring to document issues with JSTL, my observation is that a lot of Spring MVC newbies are at the same time first experiencing the pleasure of JSTL. There is a lot of confusion around how to declare taglib references, how webapp version affects taglib declaration, support for different versions of JSTL on different app servers, etc. It would be great if the Spring web documentation (or tutorial) listed common problems related to JSTL (vote for my bug!). This would save hours of frustration by Spring newbies, who simply don’t have the skills (yet) to debug what might be wrong when simple JSTL evaluation doesn’t work on their pages.

Anyway, it’s still nice to see some movement here from the Spring team, and I hope the tutorial continues to be improved and expanded.

While not explicitly highlighted in the Spring 2.5 “What’s New” section, this is a nice little bit to remove a few lines of XML. Spring 2.5 (with the introduction of a new “context:” namespace) takes the common use of a PropertyPlaceholderConfigurer externalizing properties and folds it from the awkward 5-line syntax into a single line.

Before (Spring 2.0 and earlier):

<bean id="propertyConfigurer"
   class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
 <property name="location">
  <value>file:${user.home}/env.properties</value>
 </property>
</bean>

After (Spring 2.5):

<context:property-placeholder location="file:${user.home}/env.properties"/>

The nit-picky will note that you will need to add in the spring-context-2.5.xsd schema reference, however you may be using that already anyway in Spring 2.5 to take advantage of some of the Java-based annotation functionality.

Enjoy!