Hay,
yes it's necessary to compile mod_jk.so, but it's really easy. get the
Tomcat ressources and do exactly what is said in:
http://jakarta.apache.org/tomcat/jakarta-tomcat/src/doc/mod_jk-howto.html#s6
2
The build depends on OS and Apache Version so normally the distributed
binary is matching exactly one environment exapmle. (Probably not yours ;)
If you start the startup.sh (default configuration) TomCat runs standalone
and with the interface for Apache connections. (Port 8080 is standalone
Version, Port 8007 is for mod_jk connections) Therefore you can try both. If
Apache works well with your Tomcat you can remove the:
Connector className=org.apache.tomcat.service.PoolTcpConnector
Parameter name=handler
value=org.apache.tomcat.service.http.HttpConnectionHandler/
Parameter name=port
value=8080/
/Connector
Entry form $TOMCATHOME/conf/server.xml to run Tomcat not standalone anymore.
Regards.
roman
-Ursprüngliche Nachricht-
Von: Artigas, Ricardo Y. [mailto:[EMAIL PROTECTED]]
Gesendet: Montag, 7. Mai 2001 12:27
An: [EMAIL PROTECTED]
Betreff: HANDLER THREAD PROBLEM when accessing servlet
is it really necessary to recompile the mod_jk.so just so that Tomcat will
run fine with Apache?
I have Apache web server and jakarta-tomcat-3.2.1 running on red hat linux
6.
I am running tomcat using the startup.sh script (I guess this means it's
stand-alone).
I get an error while accessing a servlet in my defined context path but the
example was working well.
Error is:
HANDLER THREAD PROBLEM: java.io.IOException: Stream broken
java.io.IOException: Stream broken at
org.apache.tomcat.service.connector.AJP12RequestAdapter.readNextRequest(Ajp1
2ConnectionHandler.java:386) at
org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection
(Ajp12ConnectionHandler.java:134) at
org.apache.tomcat.service.TcpWorkerThread.run(PoolTcpEndpoint.java:366) at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:411)
at java.lang.Thread.run(Thread.java:484)
Any ideas? TIA.
:^)
A chain is only as strong as its weakest link.
Ricky Y. Artigas
Analyst/Programmer
Information Technology Division
Easycall Communications Phils., Inc.
- Easycall Internet -
418 Arayat St., Mandaluyong City 1550, Philippines
Personal WAP Site: http://www.buzzed.co.uk/mobile/?rya
Company Website: http://www.easycall.com.ph
Tel.no: (+632) 5338001 ext.6574
Mobile:(+63) 0917-8951783
Pager: 141-002955
Email: [EMAIL PROTECTED]
---
IMPORTANT NOTICE:
This message (and any attachment hereto) may contain privileged and/or
confidential information specific to EasyCall. If you are not the intended
addressee indicated in this message, you may not copy or disseminate this
message (or any attachment hereto) to anyone. Instead, please destroy this
message (and any attachment hereto), and kindly notify the sender by reply
email. Any information in this message (and any attachment thereto) that
do not relate to the official business of EasyCall shall be understood as
neither given nor endorsed by the company.
-Original Message-
From: Noel E. Lecaros [SMTP:[EMAIL PROTECTED]]
Sent: Monday, May 07, 2001 6:02 PM
To: [EMAIL PROTECTED]
Subject: Re: wired CLASSPATH behaviour
Hi, Roman
Just a thought, but have you tried RENAMING the file db2java.zip to
db2java.jar?
Regards,
Noel Lecaros
Gerteis, Roman wrote:
Hay there,
when I was deploying a application on Tomcat 3.2.1 we had some really
wired
Problems with CLASSPATH issues.
First of all this is the environment:
* apache 1.3.14
* mod_jk.so
* tomcat 3.2.1
on Redhat 6.2
JVM 1.3 (Sun distribution)
ok. So we were putting JDBC Drivers of IBM (db2java.zip) on various
places
where we should be able to put them.
1. we put it into the $TOMCAT_HOME/lib/ to be include for whole tomcat.
(did
not work)
2. we put it into the CLASSPATH environment inside the
$TOMCAT_HOME/tomcat.sh script (did not work)
3. we put it into $TOMCAT_HOME/webapps/our_app/WEB-INF/lib/ (did not
work)
4. we unpacked the zip file and put the package tree under
$TOMCAT_HOME/webapps/our_app/WEB-INF/classes/ -- YUHEE, it worked.
the depressing part of it was, that db2java.zip and the _right_ Path to
it
was shown in the CLASSPATH variable on every of the setups
(System.out.println, or shellscript ECHO). But the JDBC Driver Manager
dumped no suitable driver found.
It took me quite a lot of time to make the application run, cause there
was
no reason for the failure (If you have a package in your classpath, then
you
would suggest that it is loaded, right?).
Anyways. The whole adventure brings me to the conclusion that either the
CLASSPATH environment of Sun JDK 1.3 for Linux is not working properly
or ..
the dynamic loading of packages of TomCat is not fully reliable (which I
honestly do not believe
