Re: Apache Portable Runtime not found on the java.library.path

2005-12-20 Thread Adam Constabaris

William Claxton wrote:
Running Java JDK 1.4.  After upgrading to Tomcat 5.5 I get this error.  
I have also installed the compatability upgrade for the Java Runtime.


The Apache Portable Runtime which allows optimal performance in 
production environments was not found on the java.library.path.


Any suggestion on how to resolve this?


add the following to CATALINA_OPTS:

-Djava.library.path=/path/to/lib

The path you should use is the directory that actually contains 
libtcnative-1.so


This is only documented in the BUILDING file in jni/native in the 
tomcat-native directory tree.


HTH

AC

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Apache Portable Runtime not found on the java.library.path

2005-12-20 Thread Adam Constabaris

FTP wrote:

I face the same problem with:

Tomcat 5.5.12
jdk: 1.5.06

and cannot find the library you suggest in order to include it!


APR integration isn't yet fully part of the Tomcat distribution, as far 
as I can tell (I think it's misleading of them to enable the APR 
listener on startup, because it makes you think you're supposed to use 
it).


I'm not sure how stable the Tomcat developers consider the APR 
integration, so if you're at all concerned about that, it's probably 
easier to just comment out the Listener instead.


If you want to use the APR libraries, first read 
http://tomcat.apache.org/tomcat-5.5-doc/apr.html to see if there are 
precompiled binaries for your platform (Windows only, AFAICT).  If not,


(a) install APR (http://apr.apache.org); if you use Linux, your 
distribution may ship the APR in a package.


(b) compile libtcnative-1.so by unpacking 
$TOMCAT_HOME/bin/tomcat-native.tar.gz and following (most of) the 
instructions there; NOTE if you don't need openSSL support, be warned 
that --without-ssl switch did not work for me with tomcat-native-1.1.0 
(ships with 5.5.12; 1.1.1 with 5.5.14-beta did honor that switch).


HTH

AC

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: MultipartRequest problem

2005-12-16 Thread Adam Constabaris

Franklin Phan wrote:

 I have an old servlet that I need to recompile but cannot because 
 it

 references MultipartRequest class.  The servlet imports the
 following packages:

 import java.io.*;
 import java.sql.*;
 import java.util.*;
 import javax.servlet.*;
 import javax.xml.parsers.*;
 import org.xml.sax.*;
 import org.w3c.dom.*;

snip

The servlet is part of a package in the webapp.  I use NetBeans 4.1, and 
I've linked all lib and class folders under Tomcat and under the webapp 
into the compile classpath and still fail.


No class named MultipartRequest has ever, to my knowledge, been part of 
the servlet spec proper (see, e.g. 
http://java.sun.com/products/servlet/2.2/javadoc/index.html), although I 
suppose some implementation might have tried to make such a thing 
available as a convenience (if they did it under the javax.servlet

package, that would have been a very bad idea).

I don't know how your code got the way it is, but I don't think that 
list of imports is going to find a class named MultipartRequest with any 
set of jars I know of; if you can't find that class in any of the jars 
you have available to you and the existing application is running 
without falling over, then presumably the servlet referencing the 
missing class is never getting called anyway.


Googling and a previous reply to you suggests the most likely candidate 
for the original source of the MultipartRequest is the 
com.oreilly.servlet package, which is usually packaged up as cos.jar and 
is available at http://www.servlets.com/cos/


HTH

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]