jakarta ee - eclipse vs tomcat deployment - exported war (partially) fails while the project runs in eclipse

Question

I have a webapp in eclipse juno - when I hit Run on server runs fine - either inside eclipse's browser (I am on windows) or in FF.

Right click > export war > dump this into $CATALINA_HOME/webapps > all is working fine (got unpacked alright) EXCEPT

• my custom tags - I had a WEB-INFfunctions.tld file which is apparently not read. The only difference between the auto-generated eclipse server.xml (in Servers project) and the default Tomcat server.xml was the line :

  <Context docBase="ted2012" path="/ted2012" 
  reloadable="true"source="org.eclipse.jst.jee.server:ted2012"/>
  

source being a WTP specific attribute.
This I managed to solve - see my answer

• Tomcat won't get the Url correctly through - see the pics in my answer.

Questions :

1. (Unsolved) Why Tomcat does not decode the Url correctly - while eclipse does ? Where is the failure ? Do see my specific question for this for extensive details on the call stack and where exactly tomcat fails
2. Why did not tomcat see the tld in the first place while eclipse did ? Why did I have to edit the web.xml ? (worked around in my answer, should be another question)

The code is in github - in the file INSTRUCTIONS.txt there are detailed instructions to set the project up and reproduce the bug pictured in my answer below.

Tomcat 7.0.32, eclipse 4.2, java 1.7.9

Answer 1

For decoding URIs correctly, you need URIEncoding connector attribute in Tomcat:

<connector ... URIEncoding="UTF-8" ... />

See my rant https://stackoverflow.com/a/15587140/995876

So it doesn't come with normal code, you need it in the application server configuration separately or use an application server that defaults to UTF-8. There is no way to affect this from code unfortunately.

Drop the decodeRequest and never use new String/getBytes without explicit encoding argument.

---

Alternative.

If you can't edit the server connector configuration, you can fix your code by providing the encoding explicitly to new String:

public static String decodeRequest(String parameter) {
     return new String(parameter.getBytes("iso-8859-1"), "UTF-8");
}