Generating a Tomcat PID file on the fly

I needed to use jsvc to stop tomcat processes, something that required a PID file containing the Process ID of the tomcat being stopped. My first alternative was to use jsvc to start Tomcat and specify the PID file to generate. Looking at the myriad of command line options that jsvc needed, I decided to stick to the provided startup.sh.

This left me with the option of generating the PID file after Tomcat had been started normally. For this, I used the lsof command of which I found an excellent reference. This is the command I used:

lsof -t -l -a -i TCP:$1 -a -c java > $tmp_file && /usr/local/bin/jsvc -stop -pidfile $tmp_file org.apache.catalina.startup.Bootstrap

The line above consists of two commands, one where lsof writes Tomcats PID into a file and the other where jsvc uses that file to shutdown Tomcat. Here is a break down of the options to lsof.

-t output the PID only
-l show ports that are in listening mode
-a and (this enables a boolean relation to be constructed between options)
-i TCP:$1 show a process with an open TCP port held in the shell input variable
-a and
-c java show processes with the name java

Invalid column type in Pentaho

A java.sql.SQLException: Invalid column type error in pentaho had broken a previously functioning report upon the introduction of changes.

On close inspection, I traced the problem to a newly introduced a parameter in an SQL statement. The parameter was supplying data for use in a SQL IN(...) clause. When a variable of type string-list was supplied, the report worked. The exception above was thrown when a variable of type string was supplied.

To resolve the problem, I created a Java ArrayList to hold the single value and hence ensure that the variable supplied was always a list.

Setting up CAS Java client

I started my journey by creating a new web project in eclipse and configured the web xml according to the CAS Java Client procedure. I basically pointed to an apache2 load balancer for a tomcat cluster where the CAS deployment was running.

I immediately ran into problems with the following error:

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

This error occured because the certificate being referenced was not in my JRE's keystore. I was able to resolve following the procedure at dreamingthings blog.

I was not thru yet. I then got this error:

javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names present

This error arose since I was using the IP address of the server in the CAS authentication URL. While I had used the IP for the Common Name (CN) entry while generating the certificate, this sun forum answer by user ejp discourages that.

I finally regenerated the self signed certificate, making sure that I used the hostname for the CN entry. There were no more errors after that :)

My next post should be on getting ZK to show the CAS username saved in the session.