In Struts 1.3 (and probably any Struts 1.x), it is sometimes useful to have a request chain across multiple Action classes, maybe to break them up into more manageable sections. But maybe you don’t want step-2 of a multi-Action process be accessible externally. If you configure your Actions like this in your struts-config.xml, you can do just that.

<action path="/refresh" type="com.philihp.action.RefreshPartOne">
  <forward name="default" path="/refresh#2.do" />
</action>
<action path="/refresh#2" type="com.philihp.action.RefreshPartTwo">
  <forward name="default" path="/" redirect="true" />
</action>

To trigger it, have the user goto /refresh.do. Struts will call RefreshPartOne.execute(), and assuming it returns the default ActionForward, it will call RefreshPartTwo.execute().

If the user tries to call /refresh#2.do, they will get an error. The browser will strip out the fragment identifier from the URL and tell the server it wants to see /refresh, which doesn’t exist. It may be possible to carefully craft a request to the server though, and it’s up to your container (e.g. Tomcat, Glassfish) to strip out the fragment. Behavior is probably undefined because RFC 1738 says the ‘#‘ is unsafe and should never be sent in a URL. So test it out if you’re really curious.

switch(suit) {
  case "club":
  case "diamond":
    trickValue = 20;
    break;
  case "heart":
  case "spade":
    trickValue = 30;
    break;
  case "no-trump":
    trickValue = 40;
    break;
}

It’s actually just syntactic sugar. The java compiler renders this all down to int switching by pre-computing the .hashcode() of all of the labels since they have to be constants anyway (unlike languages like PHP where you can do some really neat shenanigans). Because this still renders down to primitives, Java still gets the jump table optimizations that were the whole motivation of the switch construct in the first place.

If you use Eclipse, switching on a String will still probably give you an error. It wasn’t until September 2011′s release (3.7.1) that this was implemented. There were versions of Indigo that didn’t support this, so you’ll need the latest one.

Struts 1.3 changed this behavior. Rather than all of the heavy lifting being offloaded onto the RequestProcessor object by the ActionServlet, instead there’s a chain of commands executed by a class called “ComposableRequestProcessor, and it’s configured by chain-config.xml; which is in the struts-core JAR file. If you want to extend the controller to do out-of-the-ordinary stuff, you’re supposed to copy this file to somewhere else (like /WEB-inF/custom-chain-config.xml) edit it, and configure the ActionServlet to look at it instead like this

<servlet>
 <servlet-name>action</servlet-name>
 <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
 <init-param>
  <param-name>config</param-name>
  <param-value>/WEB-INF/struts-config.xml</param-value>
 </init-param>
 <init-param>
  <param-name>chainConfig</param-name>
  <param-value>/WEB-INF/custom-chain-config.xml</param-value>
 </init-param>
</servlet>

The trouble however, is that the Struts Tiles plugin that shipped with 1.3 didn’t change from 1.2. It was written to automatically replace the default RequestProcessor and its chain of command. I’m pretty sure this was supposed to be a convenience, so that to use the Tiles plugin, all you had to do was flip a switch, and it would figure out its own hooks into Struts… because this is how the Struts Tiles plugin works; it essentially overrides and customizes the RequestProcessor so forwards goto it, rather than to some JSP file or somerthing somewhere. You can see how it’s doing this overriding by looking at the method TilesPlugin.initRequestProcessorClass; which is actually a little interesting, because it’s not mucking with any XML. But that’s all you really have to do, usually.

However, and this is why I’m posting this; if you have a custom chain-config.xml already in place that was based on the chain-config.xml in the struts-core JAR, then your ActionForwards going to Tiles layouts aren’t going to lookup correctly. For example, when Struts tries to goto the ActionForward “page.index”, we get the following exception because normally ActionForwards would goto a page like “/index.jsp”.

WARNING: Unhandled exception
java.lang.IllegalArgumentException: Path page.index does not start with a "/" character
	at org.apache.catalina.core.ApplicationContext.getRequestDispatcher(ApplicationContext.java:374)
	at org.apache.catalina.core.ApplicationContextFacade.getRequestDispatcher(ApplicationContextFacade.java:196)
	at org.apache.struts.chain.commands.servlet.PerformForward.handleAsForward(PerformForward.java:107)
	at org.apache.struts.chain.commands.servlet.PerformForward.perform(PerformForward.java:96)
	at org.apache.struts.chain.commands.AbstractPerformForward.execute(AbstractPerformForward.java:54)
	at org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommandBase.java:51)
	at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:191)
	at org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.java:305)
	at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:191)
	at org.apache.struts.chain.ComposableRequestProcessor.process(ComposableRequestProcessor.java:283)
	at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913)
	at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:449)
        ...

As far as cryptic errors go, this one is pretty far up there, and unless you actually know how Tiles works, it’s going to be a huge pain to debug. The remedy is actually to base your chain-config.xml file off of Tiles’ own chain-config.xml. And in it you can see how at the end it calls TilesPreProcessor right before it performs the forward.

The Tiles documentation indeed says you need to do this — but hardly anyone ever does, because everything will work unless you customize the request processor; and hardly any books or sites out there will tell you to do it.

In the init setup of your class that extends WebApplication, you can “mount” your pages at paths, like this:

@Override
protected void init() {
	super.init();
	mountBookmarkablePage("/search", SearchPage.class);
}

So when you goto http://somewhere.com/somecontext/search, it gives you the SearchPage class.

You can also specify a HomePage index, like this:

public Class getHomePage() {
	return IndexPage.class;
}

Then when you goto http://somewhere.com/somecontext/, it gives you the IndexPage class.

The cool subtle thing here is what happens when you do them both; i.e. you mount SearchPage to /search, and you override getHomePage to return SearchPage.class. Do this, and when you goto http://somewhere.com/somecontext/, it will redirect to http://somewhere.com/somecontext/search!

The old way of instantiating a List in Java was like this:

List strings = Arrays.asList(new String[]{"foo","bar"});

In Java 5, templates were introduced, so I had to change to doing this:

List<String> strings = Arrays.asList(new String[]{"foo","bar"});

It just occurred to me that with variable-length methods, I can simply call asList like this:

List<String> strings = Arrays.asList("foo","bar");