Apr 24 2008

How to Reference and Use JSTL in your Web Application

Tag: development,glassfish,java,jboss,jsp,jstl,spring,tomcatpmularien @ 6:06 am

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”


Feb 19 2008

Tutorial: How to set up Tomcat 6 to work with JSTL 1.2

Tag: development,java,jsp,jstl,spring,tomcatpmularien @ 11:37 pm

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.

Updated: Mar 1, 2011

You may now download the JSTL API and implementation JARs directly from the Sun Glassfish web site. Thanks to several alert readers for pointing this out!

Simply go to dev.java.net and download the two JAR files on the page for JSTL 1.2. Copy them into your Tomcat installation’s lib directory and you should be all set!

You can also download the JSTL JAR (API and implementation in a single JAR) directly from Maven Central.

If you are using Maven, you can pick up the JSTL dependency by including the following in your project’s POM file:

<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>jstl</artifactId>
  <version>1.2</version>
</dependency>

Older Information Below (2008 Vintage)

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 as follows:
    • appserver-jstl.jar: Place 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. Note you may run into classloader issues when running on application servers other than Tomcat which supply their own (conflicting) JSTL implementations. In this case, remove this JAR from your web application, and move it into {tomcat-install}/lib.
    • javaee.jar: In the {tomcat-install}/lib folder. This will make the JSTL 1.2 libraries available to all web applications.

Note that placing javaee.jar in the app server lib directory isn’t really the best way to go about this, but Tomcat will ignore the JAR if it’s included in your webapp due to the rule in section 9.3.2 of the Servlet 2.3 spec (in fact, it will ignore any JAR file completely if it contains the class javax.servlet.Servlet). For further reference, you can see the classloader code. You will see the following error when your webapp is started up if you have javaee.jar in WEB-INF/lib (assuming appropriate logging is enabled):

INFO: validateJarFile({path-to-webapp}\WEB-INF\lib\javaee.jar) – jar not loaded. See Servlet Spec 2.3, section 9.7.2.
Offending class: javax/servlet/Servlet.class

For you Spring MVC’ers trying to get started with the latest versions of Tomcat and JSTL, hopefully this helps you!


Feb 05 2008

Tomcat 6.0.14 + JSTL 1.2_07 RI = *Boom* NullPointerException

Tag: development,eclipse,java,jsf,jstl,tomcatpmularien @ 8:39 pm

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.


Dec 11 2007

Solving Problems with International (UTF-8) Data using Hibernate, Oracle, and Tomcat

Tag: hibernate,java,oracle,tomcatpmularien @ 6:19 am

Ran into a very interesting issue the other day relating to storing NLS character data in Oracle via Hibernate, running in the Tomcat servlet container. It turns out the solution is not entirely obvious (or well-documented), so I thought I’d jot the important bits down.

NVARCHAR2 is a data type assigned to a column that is used to store NLS data, most generally multi-lingual (UTF-8 or equivalent). This differs from the typical VARCHAR2 data type, which is usually intended for storing data in the local character set (see this for a weak explanation).

In theory you should not have to do anything different in your JDBC-based application to write to an NVARCHAR2 column vs a VARCHAR2 column, since String type in Java is UTF-8.

However, the evil Oracle JDBC driver rears its ugly head again (if you’ve been working with Oracle JDBC for any length of time, you know what I’m talking about ;) )!
Continue reading “Solving Problems with International (UTF-8) Data using Hibernate, Oracle, and Tomcat”


Nov 18 2007

Quick Tip: When Eclipse just won’t clean up the Tomcat Working Directory

Tag: eclipse,java,tomcatpmularien @ 8:41 pm

I use Eclipse 3.3.x and WTP 2.x for most of my web development. Recently, I’ve been using an Eclipse-managed Tomcat 6 server for running and deploying web applications.

I’ve run into the problem several times when “Clean Tomcat Work Directory…” just doesn’t work. Fortunately, you can manually find the deployment directory and blow away your deployed web application – if you know where to look.

For Eclipse-managed Tomcat installs, look in the following directory to find the Tomcat setup for your workspace:

.metadata\.plugins\org.eclipse.wst.server.core\tmp0

You’ll see the usual conf, logs, temp, webapps directories. Your web application is most likely deployed in the “wtpwebapps” directory – look for it there and remove (delete) it. Tomcat will be happy once again.

Note that the “tmp0″ designation may differ depending on how many servers you have configured in your workspace.

Further Reading

Web Tools Platform 2.0 “New & Noteworthy” discusses the use of these new WTP 2.0 features in more detail.