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.

data mytable;
run;

It would actually create a dataset with one row. The data step cycles through once, hits the end (run), outputs a row, then comes back and finds it has no more rows to process so it stops. To stop this one row from being output, try this instead:

data mytable;
  stop;
run;

target="_blank"

I don’t know who started these nasty rumors that “_new” would open up in a new browser. As far back as I can tell, no browser has ever recognized “_new”.

The whole point of the target dates back to when browsers used frames to split up your browser. If you had a link in a sidebar on the left, and you wanted that link to open up in the main frame to the right, you would specify “main” as the name of that frame in your frameset page, and target=”main” in your links on the sidebar. When the user would click on a link in the sidebar, the browser would say “hmm, I’m supposed to open this up in the ‘main’ frame, do I have one named that?”. If it didn’t, it would open up the link in a new window, and give that window the name of the target of the link. This is what would happen with target=”_new”; a new browser would open up with a name of “_new”.

The problem is this if you click on this first link, then read it and go “oh that’s interesting” and click on some links in it to goto further pages on it, everything seems fine. But then if you click this second link below, and then the third link, they open up in the same browser!

• Link 1 target=”_new”
• Link 2 target=”_new”
• Link 3 target=”_new”

If only they had a target of “_blank”, they would all open up in a new browser every time.

• Link 1 target=”_blank”
• Link 2 target=”_blank”
• Link 3 target=”_blank”

It’s a simple fix. Just stop using target=”_new”.

You keep using that word. I do not think it means what you think it means. – Inigo Montoya

Or just stop opening links in new browsers all together; it has been considered bad usability for over a decade now. The user will open your links up in a new window if they want to.

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-eclipse-plugin</artifactId>
  <version>2.8</version>
  <configuration>
    <wtpContextName>some/url/context</wtpContextName>
    <wtpversion>1.5</wtpversion>
  </configuration>
</plugin>

Also, I like to download sources and Javadoc, which makes navigating in Eclipse a lot easier. This can be done like this.

<plugin>
  ...
  <configuration>
    <downloadSources>true</downloadSources>
    <downloadJavadocs>true</downloadJavadocs>
  </configuration>
</plugin>

Supposing you also want your project to have JPA facets, or other additional project facets you could also add them in like this

<plugin>
  ...
  <configuration>
    <additionalProjectFacets>
      <jpt.jpa>2.0</jpt.jpa>
    </additionalProjectFacets>
  </configuration>
</plugin>

And all of these can be combined to do this

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-eclipse-plugin</artifactId>
  <version>2.8</version>
  <configuration>
    <wtpContextName>list</wtpContextName>
    <wtpversion>1.5</wtpversion>
    <downloadSources>true</downloadSources>
    <downloadJavadocs>true</downloadJavadocs>
    <additionalProjectFacets>
      <jpt.jpa>2.0</jpt.jpa>
    </additionalProjectFacets>
  </configuration>
</plugin>

To install a servlet filter in your web.xml, you’d do something like this:

<filter>
  <filter-name>jpa-filter</filter-name>
  <filter-class>com.philihp.utils.EntityManagerFilter</filter-class>
</filter>
<filter-mapping>
  <filter-name>jpa-filter</filter-name>
  <servlet-name>action</servlet-name>
</filter-mapping>

Where the filter will filter any servlet named “action” — which in this case is the name of my Struts 1.3 controller that I had defined earlier. Rather than specify a servlet-name, you’re allowed to use a url-pattern, but according to Sun, the url-pattern has to begin with a "/" slash, so the following does not work.

<filter-mapping>
  <filter-name>jpa-filter</filter-name>
  <url-pattern>/*.jsp</url-pattern>
</filter-mapping>

JSPs are essentially servlets, compiled from JSP code the first time they’re run. But you don’t have to define every JSP file in your web.xml file, because they’re already defined by the container. There’s a servlet (in tomcat, it’s the Jasper engine) mapped to /*.jsp. In the Tomcat guts, you can find it at conf/web.xml, which is the basis web.xml file; every webapp deployed in Tomcat is actually extended from this file

<servlet>
  <servlet-name>jsp</servlet-name>
  <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
</servlet>

Since JSPs are essentially running as the servlet name “jsp”, you can attach a servlet-filter to them with a filter-mapping similar to this:

<filter-mapping>
  <filter-name>jpa-filter</filter-name>
  <servlet-name>jsp</servlet-name>
</filter-mapping>

For example, if you have a date (any date. maybe the current date?), you can get the date of the first day of the next month by doing this:

data _null_;
  d = '11JUN2011'd;
  format d date9.;
  put d;
  d = intnx('month',d,1);
  put d;
run;

Which outputs

11JUN2011
01JUL2011

But to get the “Last Day” of the current month, you have to be clever. The last day of the current month is the day before the first day of the next month. SAS Dates are internally stored as a number of days since some point, so just subtract one from it.

data _null_;
  d = '11JUN2011'd;
  format d date9.;
  put d;
  d = intnx('month',d,1)-1;
  put d;
run;

Which outputs

11JUN2011
30JUN2011

I don’t think C gets enough credit. Sure, C doesn’t love you. C isn’t about love–C is about thrills. C hangs around in the bad part of town. C knows all the gang signs. C has a motorcycle, and wears the leathers everywhere, and never wears a helmet, because that would mess up C’s punked-out hair. C likes to give cops the finger and grin and speed away. Mention that you’d like something, and C will pretend to ignore you; the next day, C will bring you one, no questions asked, and toss it to you with a you-know-you-want-me smirk that makes your heart race. Where did C get it? “It fell off a truck,” C says, putting away the boltcutters. You start to feel like C doesn’t know the meaning of “private” or “protected”: what C wants, C takes. This excites you. C knows how to get you anything but safety. C will give you anything but commitment

In the end, you’ll leave C, not because you want something better, but because you can’t handle the intensity. C says “I’m gonna live fast, die young, and leave a good-looking corpse,” but you know that C can never die, not so long as C is still the fastest thing on the road.

Anonymous on 4chan

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.

Good code in perl is fine, but there’s something about bad code in perl
that’s worse than bad code in other languages, something very HP-Lovecraft-
mad-servants-of-the-elder-gods-chattering-in-the-extradimensional-
insect-language kind of bad that makes my head hurt when I have to read
it.

Jish Karoshi on comp.lang.ruby