Wilfred Thinking Aloud

Running Shale Samples

Today, I set off to get a Shale sample up and running on my laptop. Shale sounds too good to be true, so I figured that I'd better find out if is real. A couple of weeks ago I had been working on building Shale from scratch. I may have missed it at that time, but it appears that there are now nightly builds available. So I decided to give it a go and look at a nightly build instead.

You may already have been aware of it, but Shale comes with a sample application, illustration most its features. This is the application that I'm going to install; it's called struts-shale-usecases.war.

In the good old hacker tradition, I decided to skip the readme (DRTFM) and - what the heck - deploy the war file included in the nightly build to a couple of J2EE servers.

Attempt 1: Sun Java System Application Server 8.1 Q2

Attempt 1, deploying it to a default installation of the Sun Java System Application Server 8.1 Q2. After deploying the war file trough the console, I enter http://localhost:8080/struts-shale-usecases/ in my browser. Nothing happens. The application server tells me that the application is not deployed. What the...?! Maybe I didn't have enough coffee this morning. Let's try that again..... Nope, it keeps telling me that it doesn't exist.

Let's look at the log files. Ah, there it is. There's a class that cannot be found:

java.lang.ClassNotFoundException: org.apache.shale.dialog.impl.DialogImpl
        at org.apache.commons.digester.Digester.createSAXException(Digester.java:2540)
        at org.apache.commons.digester.Digester.createSAXException(Digester.java:2566)
        at org.apache.commons.digester.Digester.startElement(Digester.java:1276)
        at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:485)
        at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:799)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:845)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1563)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:341)

Checking the struts-shale-usecases.war reveils that the class resides in shale-core.jar, so it does exist. Looks like a classloading problem, caused by commons-digester living somewhere else in the chain of classloaders. (And so it does: commons-digester appears to be part of appserv-rt.jar. Hmmmmmm.) Let's forget about this for a while, and try something else.

Attempt 2: Tomcat 4.1.30

That was a little disapointing. Maybe I should have read the readme. (Quickly skimming trough its content now. Nope it doesn't tell me anything about the support for SJAS8.1.) Let's try this again, but this time using Tomcat 4.1.30, which I also already had running on my system. Simply copy the war file into the webapps directory and type ./startup.sh. Typing http://localhost:8080/struts-shale-usecases/ in my browser, and - nothing, again. This time the server doesn't give me any clues at all. It just returns a blank page.

Searching the war file for some piece of content that I can try to retrieve directly - just to see if the application was actually deployed - reveils that there is a index.jsp file. So I go and type http://localhost:8080/struts-shale-usecases/index.jsp. Ah, that's better. A stack trace:

org.apache.jasper.JasperException: This absolute uri (http://java.sun.com/jsf/core) cannot be resolved in either web.xml or the jar files deployed with this application
	at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:105)
	at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:430)
	at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:154)
	at org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:159)
	at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:354)
	at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:381)
	at org.apache.jasper.compiler.Parser.parseElements(Parser.java:795)
	at org.apache.jasper.compiler.Parser.parse(Parser.java:122)

Huh? Is this an XML parser problem? I takes me a while to realize that this is the reference to the tag library. It seems to resolve this URI into a tag library descriptor. Strange. On inspection, it appears that the tag libraries are not specified in the web.xml file. Maybe this has something to do with different fallback mechansisms in JSP 1.2 and JSP 2.0. The jsf-impl.jar file does contain a .tld file, but somehow the container doesn't pick it up, or fails to interpret it correctly.

Attempt 3: Tomcat 5.0.28

Assuming that all of the above had something to do with the version of the required versions of the Servlet/JSP spec, I'm moving to Tomcat 5.0, since it supports JSP 2.0. (Stubborn as I am, I'm still refusing to read the readme, but I'm tempted to. Instead I decided to take a look at http://struts.apache.org/shale/, to see if there's anything on deployment there, and yep, there is something in the Foundation section. It appears that you can deploy Shale in a JSP 1.2 Servlet 2.3 container, as long as you modify the deployment descriptors properly.

Being the lazy guy I am, I don't want to go down that path, so Tomcat 5.0 might be the alternative that works. And it works: