It’s Only Software

If you have done Websphere Portal 5.1 development, you have probably seen this error (among many others) at some point in your development lifecycle:

EJPPG0003E: ServletContext lookup for /.MyPortalApp returned the portal context. It has to be a different one.

Let me tell you that this error can be caused by about a hundred different things. If the issue is actually a context issue, you can follow Jamie Mcllroy’s great instructions to try to resolve context root-type problems.

But let’s say you do that, and you’re still getting the error - what then? (I’m assuming, by the way, that you are running inside RAD with the Websphere Portal UTE.)

As near as I can figure out, this error is thrown when you try to access a portlet and the backing application (usually a WAR within an EAR) doesn’t initialize itself properly. If you read into this, it basically means this error can be caused by a wide variety of issues with the underlying application.

First, make sure that you have console logging enabled in your server configuration. To do this, open your server configuration, click on the “Portal” tab (far right), and ensure the “Enable console logging” box is checked.

Next, when you attempt to access your portlet, you should (hopefully!) see an error appear in the console log. If you do, have a look at it, and hopefully it will be obvious what’s wrong.

If it’s not obvious, or if you get the infamous PortletExeption, you may have to enlist the help of a debugger. I would suggest the following steps:

1. Restart the server in Debug mode
2. When the server starts up, set a Java Exception Breakpoint for Throwable
3. Attempt to hit the offending servlet or portlet

If the servlet is throwing an error that ends up being reported as EJPPG0003E, you’ll see the debugger stop at the exception in question. I personally have seen this error caused by various JSF configuration errors (with portlets using JSF), and classloader issues (missing MANIFEST.MF entries, classloader configuration issues, PARENT_LAST vs PARENT_FIRST, etc).

Hope this helps someone! If you have any other suggestions for diagnosing this error, please share!

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”

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]

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.

Recently, while working on a customer’s older EJB 2-based system, I was going a bit nutty having to run a 1-2 minute ant build to execute various code generation tasks (anyone have fond memories of ejbgen like I do? )

I was able to get Eclipse set up to be happy with the relatively complex build structure, and happily discovered the “Ant Builder” capability of Eclipse, which allows ant build tasks to be inserted into the Eclipse build process. Tying this external build process into the IDE helped improve my efficiency while working on this complex project. I’ll go over here briefly how you can use this feature through an illustrative example.
Continue reading “Quick Tip: Using “Ant Builder” to customize Eclipse builds using ant scripts”

A month ago, I posted about using inline SVG to simulate the Web 2.0 “shiny floor technique” (SFT) for a mirrored reflection effect on page headings. I have not had time to perfect it, but I figured I’d publish it and see if people are interested in enhancing the technique. Note that this has only been tested thus far on 2 browsers that natively support inline SVG, Firefox 2 and Safari.

Demo Page

For those not running one of the aforementioned browsers, here’s what it looks like:

There are several reasons why this is currently impractical for real-world use (although I’d like to change this):

• This technique will only work if the page is served up as XHTML (content-type application/xhtml+xml, aka “true XHTML”). Since some browsers do not like proper XHTML, this will prevent a large percentage of your audience from seeing this technique in action.
• Currently, the inline SVG is embedded in the page.
• The demonstration of this does not use true headings (h1, etc.)
• The text “SWOOSH” is repeated twice in the page - once in the heading and once in the SVG.

The latter three will be changed in the next published iteration of this technique. In the next iteration, I plan on adding Javascript so that this effect can be added unobtrusively on top of headings on an existing page. This will also allow the effect to degrade gracefully on browsers that do not support inline SVG.

Based on the way that inline SVG is implemented in current browsers (requiring support in the render engine of XML namespaces), I’m not sure whether the requirement of serving the content as true XHTML is a technical hurdle that can be overcome.

As far as I’ve been able to research, this is the first time anything has been published that uses SVG for this type of effect, using only plain text. Prior examples of the SFT have required Photoshop, required Flash, or only work on images.

I’m excited to take it to the next level (as noted above) and hopefully provide something that people find useful.

In my [admittedly] limited 3 years of using Hibernate, I’ve found that a lot of folks are confused about what loggers to use when trying to debug Hibernate issues.

These people (myself included, on occasion) will end up opening the floodgates and doing something like this (log4j) syntax:
<logger name="org.hibernate"> <level value="DEBUG"> </level> </logger>

While this (obviously) works, Hibernate is nothing if not verbose in its logging, and this will easily generate megabytes of Hibernate logs.

Hibernate uses the standard logging pattern of naming loggers after the classes they’re enclosed in, as suggested by Sun itself. So if you’re familiar with the Hibernate code, it can be fairly easy to pick out the right package qualifier in your logging configuration to get logging where you want it.

Unfortunately, many/most developers aren’t familiar enough with the Hibernate source code to know these things off the top of their heads.

Thankfully, the Hibernate folks have kindly documented some logging settings, including logging of SQL (which is the simple shortcut org.hibernate.SQL.

I have a couple more useful loggers to add to the list:

• org.hibernate.engine.query.HQLQueryPlan - which will display the source of any HQL query executed prior to execution and parameter binding
• org.hibernate.engine.QueryParameters - will display the name / value pairs of query parameters bound to HQL queries

I’ll plan on updating this post with additional information as I run across it.