Skip to content
accelerando

Tag Archives: Tomcat

Different day, same shit, today: Java 5 on Oracle Enterprise Linux 5

19-Jan-09

Worlds collide: Oracle and Sun JDK. Perfect start to ruin a not so bad Monday morning.

Background: Need to have a Tomcat Server deployed on a Oracle Enterprise Linux 5 system.

I was happy, when i saw a tomcat5 package in the repositories. Great, i thought. All i need. Well. Not.

Under Windows you’ll get between one and ten JVM versions installed with on Oracle product (slight exaggerated), within the OEL5 there was only one ancient 1.4.2 JDK. *sigh* Did i mention that the application that is supposed to run on that thing uses a buttload of Java 5 features?

“yum search java-”… No Java 5. WtF?

There is no Java 5.

Again, do it yourself:

This is a nice entry that describes howto build rpms for the “official” Sun Java 5 jdk.

I used the following steps to build my rpms:

  • Downloaded this rpm
  • Downloaded jdk-1_5_0_15-linux-i586.bin from the Sun JDK archive page
  • Put the later one into /usr/src/redhat/SOURCES/
  • Built the rpms with rpmbuild –rebuild java-1.5.0-sun-1.5.0.15-1jpp.nosrc.rpm. If rpmbuild is not installed, it’s hidden in the package rpm-build, not rpmbuild.
  • Installed missing libXp
  • Installed the rpms:
    rpm -Uvh /usr/src/redhat/RPMS/i586/java-1.5.0-sun-1.5.0.15-1jpp.i586.rpm
    rpm -Uvh /usr/src/redhat/RPMS/i586/java-1.5.0-sun-devel-1.5.0.15-1jpp.i586.rpm
    rpm -Uvh /usr/src/redhat/RPMS/i586/java-1.5.0-sun-src-1.5.0.15-1jpp.i586.rpm
    rpm -Uvh /usr/src/redhat/RPMS/i586/java-1.5.0-sun-demo-1.5.0.15-1jpp.i586.rpm
    rpm -Uvh /usr/src/redhat/RPMS/i586/java-1.5.0-sun-plugin-1.5.0.15-1jpp.i586.rpm
    rpm -Uvh /usr/src/redhat/RPMS/i586/java-1.5.0-sun-fonts-1.5.0.15-1jpp.i586.rpm
    rpm -Uvh /usr/src/redhat/RPMS/i586/java-1.5.0-sun-alsa-1.5.0.15-1jpp.i586.rpm
    rpm -Uvh /usr/src/redhat/RPMS/i586/java-1.5.0-sun-jdbc-1.5.0.15-1jpp.i586.rpm
  • Last step: Choose the right java version with alternatives –config java

After that, everything could be fine. Well, it wasn’t:

sun.misc.InvalidJarIndexException: Invalid index

Jehova! Finally not a NPE but something new, at least to me. Sometimes i wonder why i always run into bugs like these.

Some script changes and repackages all jar files in some weird ways so that a standard JDK has funny problems.

My solution to it: Reindex everything in /usr/share/java after you’ve chosen your newly installed java with the following command:

find /usr/share/java/ -iname "jakarta*commons*.jar" -exec jar -i {} \;

I opted to reindex only the jakarta commons files, that got Tomcat up and running with Java 5.

One last note: The /usr/bin/dtomcat5 is broken imho, at least when run from /etc/init.d/tomcat5. In ignores /etc/tomcat5/tomcat5.conf and therefore cannot stop Tomcat.

My solution: Replace

if [ -z "$CATALINA_HOME" ]; then
    TOMCAT_CFG="/etc/tomcat5/tomcat5.conf"
fi

(in line 55 on my setup) with

if [ -z "$CATALINA_HOME" ]; then
    TOMCAT_CFG="/etc/tomcat5/tomcat5.conf"
    [ -r "$TOMCAT_CFG" ] && . "${TOMCAT_CFG}"
fi

and remove

if [ -z "$CATALINA_HOME" ]; then
    [ -r "$TOMCAT_CFG" ] && . "${TOMCAT_CFG}"
fi

(in line 105 on my setup).

I wonder why simple things like these always are a pain in the ass. Stupid nuisances that keeps people from getting their work done. *sigh* Not a good start for the week.

Kaputte UTF-8 Daten im Servlet

05-Oct-06

Beruflich habe ich gerade mit einer Webanwendung zu tun, die mit Spring realisiert ist. Spring macht ähnlich viel Spaß wie Ruby und ist bis jetzt das erste J2EE Framework, dass mir von Anfang zusagte und es auch schaffte, mich zu begeistern.

Die Webanwendung ist komplett UTF-8 basiert. Soweit so gut. Leider mußte ich feststellen, dass Eingaben per form nicht so ankamen, wie ich mir das vorgestellt hatte, irgendwo ging das Characterset verloren.

Ich nutze zur Zeit Java 1.5.0.8, Apache Tomcat 5.5.17, Spring 1.2.8 sowie Hibernate 3.1.x. Irgendwo im Zusammenspiel der ersten drei Komponenten trat der Fehler auf, obwohl ich in allen beteiligten JSP Dateien den Content Type angegeben habe. Ich habe mir jetzt mit folgenden Filter beholfen, der dafür sorgt, dass UTF-8 auch als solches ankommt:

package filter;
 
import java.io.IOException;
 
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
 
public class CharsetFilter implements Filter {
	FilterConfig config;
	String encoding = "UTF-8";
 
	/**
	 * @see javax.servlet.Filter#destroy()
	 */
	public void destroy() {
	}
 
	/**
	 * Sets the character encoding on the request
	 * @see javax.servlet.Filter#doFilter(javax.servlet.Servle tRequest, javax.servlet.ServletResponse, javax.servlet.FilterChain)
	 */
	public void doFilter(ServletRequest request, ServletResponse response,
			FilterChain chain) throws IOException, ServletException {
		request.setCharacterEncoding(encoding);
		chain.doFilter(request, response);
	}
 
	/**
	 * @see javax.servlet.Filter#init(javax.servlet.FilterConf ig)
	 */
	public void init(FilterConfig config) throws ServletException {
		this.config = config;
		this.encoding = config.getInitParameter("requestEncoding");
	}
}

Der Filter kann im web.xml einfach konfiguriert werden:

<filter>
	<filter-name>
		charsetFilter
	</filter-name>
	<filter-class>
		filter.CharsetFilter
	</filter-class>
	<init-param>
		<param-name>requestEncoding</param-name>
		<param-value>UTF-8</param-value>
	</init-param>
</filter>
 
<filter-mapping>
	<filter-name>charsetFilter</filter-name>
	<url-pattern>/app/html/*</url-pattern>
</filter-mapping>
Close
E-mail It