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). > > > > Does anyone had similar Problems, and can someone give me a tip for > where to > > put JDBC Driver packages inside a Webapp? (WEB-INF/lib/ I thought, > but....) > > > > thx. and regards > > roman