Commons HTTPClient exception with JBoss

[sfarrow]

Hi Antun,

I'm back again. Having some difficulty with my LPS deployment on JBoss. Specifically, if any dataset references an external HTTP datasource, I get an exception thrown. Here is a part of the stack trace:

java.lang.NoSuchMethodError: org.apache.commons.httpclient.HttpMethodBase.addRe questHeader(Ljava/lang/String;Ljava/lang/String;)V
at com.laszlosystems.utils.LZHttpUtils.proxyRequestHe aders(LZHttpUtils.java:197)
at com.laszlosystems.data.HTTPDataSource.getDataOnce( HTTPDataSource.java:218)
at com.laszlosystems.data.HTTPDataSource.getData(HTTP DataSource.java:143)
at com.laszlosystems.data.DataSource.getAsSWF(DataSou rce.java:81)
at com.laszlosystems.servlets.response.ResponseCache. respondImpl(ResponseCache.java:97)
at com.laszlosystems.servlets.response.Response.respo nd(Response.java:177)
at com.laszlosystems.servlets.LZServlet._doGet(LZServ let.java:323)
at com.laszlosystems.servlets.LZServlet.doGet(LZServl et.java:262)

Looks like a version issue with the Commons HTTPClient library, but I'm not sure how to go about resolving it.

This has occurred with both a Windows 2000 and RedHat Linux environments, but did not occur on our Mac OS/X boxes. We are running JBoss 3.2.1 (with Jetty). We have also deployed it with a standalone Jetty (4.2.10) and it works fine. Unfortunately, our client is running Linux/JBoss.

Any suggestions?

Steve

[antun]

Often these things might be caused by .jar files that ship with the LPS conflicting with the ones in the servlet container.

I did a search for commons-httpclient.jar in the v1 installation, and found:

./jakarta-tomcat-4.1.12/webapps/lps-v1/WEB-INF/lib/commons-httpclient.jar

Check to see if the same file appears somewhere in teh JBoss installation. If it does, you could try replacing the JBoss one with the LPS one (after backing it up of course!!), and seeing if that helps.

-Antun

[sfarrow]

No luck! Updating the commons-httpclient then introduced complaints about commons-logging. I added the commons-logging and commons-logging-api jars to JBoss, but still have NoClassDefFoundError exceptions raised looking for a LogFactory class.

We have reevaluated our need for JBoss versus Jetty only and for the moment we will proceed with Jetty which does not exhibit this problem. If you come across any information, please pass it on.

Perhaps you could help with a Jetty/LPS caching question. Whenever I restart Jetty, the LPS cache is lost and all LZX files must be recompiled. Any way to preserve the cache across restarts?

Thanks.

Steve

[antun]

By default the LPS does save the LPS cache between restarts. The reason you're probably not seeing this with Jetty, is because Jetty uses the /tmp dir as its default temporary directory, and this might get cleared intermittently (as a result of a cron job or maybe by Jetty itself on restart).

You might try changing the temp directory of Jetty to something more permanent. This is done when you start Jetty, by adding:

-Djava.io.tmpdir="/var/local/jetty"

... to your startup line, if /var/local/jetty is the directory you want to use as the temp one.

-Antun



Perhaps you could help with a Jetty/LPS caching question. Whenever I restart Jetty, the LPS cache is lost and all LZX files must be recompiled. Any way to preserve the cache across restarts?