javax.servlet.jsp.JspTagException: ClassNotFoundException Error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hay TomCatters, I have some really wired behaviour on my Tomcat 3.2.1 Installation. We have some classes laying around in the deployment classes folder: $TOMCAT_HOME/webapps/APPNAME/WEB-INF/classes/ 1.) The classes are physically there. 2.) The classpath is build properly and included on startup. (see $1) and I get the ClassNotFoundException :((( the Class is loaded dynamically with: Beans.instantiate(classLoader, com.eproduction.ResourceProvider); So My question (for hours now) ...where to put the class so that the classLoader can allocate it? I have no (more) clue? ok. There is a workaround. I can put those classes under: $TOMCAT_HOME/classes then the whole thing works. But this is exactly not what I wanted. I want to pack the application and keep those helper classes in the application's classes folder under WEB-INF. Any suggestions? thx. roman SERVER.XML - - !-- The App Context -- Context path=/eJob docBase=webapps/eJob crossContext=false debug=0 reloadable=true /Context CLASSPATH: - - Classpath according to the Servlet Engine is: /usr/local/tomcat/webapps/eJob/WEB-INF/classes:/usr/local/tomcat/webap ps/eJob/WEB-INF/lib/US_export_policy.jar:/usr/local/tomcat/webapps/eJo b/WEB-INF/lib/local_policy.jar:/usr/local/tomcat/webapps/eJob/WEB-INF/ lib/jce1_2_1.jar:/usr/local/tomcat/webapps/eJob/WEB-INF/lib/ivjdab.jar :/usr/local/tomcat/webapps/eJob/WEB-INF/lib/db2java.jar:/usr/local/tom cat/webapps/eJob/WEB-INF/lib/jasper.jar:/usr/local/tomcat/webapps/eJob /WEB-INF/lib/jce.jar:/usr/local/tomcat/webapps/eJob/WEB-INF/lib/sunjce _provider.jar:/usr/local/tomcat/webapps/eJob/WEB-INF/lib/webserver.jar And errormessage: - -- Error: 500 Location: /eJob/web/ErrorMessage.jsp Internal Servlet Error: javax.servlet.ServletException: ClassNotFoundException Error : com.eproduction.ResourceProvider at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageCont extImpl.java:459) at web._0002fweb_0002fErrorMessage_0002ejspErrorMessage_jsp_0._jspService (_0002fweb_0002fErrorMessage_0002ejspErrorMessage_jsp_0.java:296) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServ let.java:177) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:31 8) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:40 4) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatch erImpl.java:194) at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java :421) at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageCont extImpl.java:446) at web._0002fweb_0002fController_0002ejspController_jsp_0._jspService(_00 02fweb_0002fController_0002ejspController_jsp_0.java:772) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServ let.java:177) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:31 8) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:40 4) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.j ava:797) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConn ection(Ajp12ConnectionHandler.java:166) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:4 16) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java: 498) at java.lang.Thread.run(Thread.java:484) Root cause: javax.servlet.jsp.JspTagException: ClassNotFoundException Error : com.eproduction.ResourceProvider at com.eproduction.LabelTag.doEndTag(LabelTag.java:70) at web._0002fweb_0002fErrorMessage_0002ejspErrorMessage_jsp_0._jspService (_0002fweb_0002fErrorMessage_0002ejspErrorMessage_jsp_0.java:283) at
AW: javax.servlet.jsp.JspTagException: ClassNotFoundException Error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hai Roger, it's not a web.xml thing or unmapped servlets or anything. I talk a about helperclasses or packages which ARE on the classpath and not accessible by the classloader somehow. Same to the packages. The loading of a Context does (at least in my case) not properly bind the ressources in WEB-INF/classes and WEB-INF/lib onto my Web-Application. hmm.m still searching. thanxs anyways. roman - -Ursprüngliche Nachricht- Von: Roger Wei [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 2. Juli 2001 01:29 An: [EMAIL PROTECTED] Betreff: Re: javax.servlet.jsp.JspTagException: ClassNotFoundException Error If you run it on windows 9x/Me, please see http://rogerwei.com/install_secret.txt - - Original Message - From: Gerteis, Roman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, July 01, 2001 6:46 PM Subject: javax.servlet.jsp.JspTagException: ClassNotFoundException Error -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hay TomCatters, I have some really wired behaviour on my Tomcat 3.2.1 Installation. We have some classes laying around in the deployment classes folder: $TOMCAT_HOME/webapps/APPNAME/WEB-INF/classes/ 1.) The classes are physically there. 2.) The classpath is build properly and included on startup. (see $1) and I get the ClassNotFoundException :((( the Class is loaded dynamically with: Beans.instantiate(classLoader, com.eproduction.ResourceProvider); So My question (for hours now) ...where to put the class so that the classLoader can allocate it? I have no (more) clue? ok. There is a workaround. I can put those classes under: $TOMCAT_HOME/classes then the whole thing works. But this is exactly not what I wanted. I want to pack the application and keep those helper classes in the application's classes folder under WEB-INF. Any suggestions? thx. roman SERVER.XML - - !-- The App Context -- Context path=/eJob docBase=webapps/eJob crossContext=false debug=0 reloadable=true /Context CLASSPATH: - - Classpath according to the Servlet Engine is: /usr/local/tomcat/webapps/eJob/WEB-INF/classes:/usr/local/tomcat/web ap ps/eJob/WEB-INF/lib/US_export_policy.jar:/usr/local/tomcat/webapps/e Jo b/WEB-INF/lib/local_policy.jar:/usr/local/tomcat/webapps/eJob/WEB-IN F/ lib/jce1_2_1.jar:/usr/local/tomcat/webapps/eJob/WEB-INF/lib/ivjdab.j ar :/usr/local/tomcat/webapps/eJob/WEB-INF/lib/db2java.jar:/usr/local/t om cat/webapps/eJob/WEB-INF/lib/jasper.jar:/usr/local/tomcat/webapps/eJ ob /WEB-INF/lib/jce.jar:/usr/local/tomcat/webapps/eJob/WEB-INF/lib/sunj ce _provider.jar:/usr/local/tomcat/webapps/eJob/WEB-INF/lib/webserver.j ar And errormessage: - -- Error: 500 Location: /eJob/web/ErrorMessage.jsp Internal Servlet Error: javax.servlet.ServletException: ClassNotFoundException Error : com.eproduction.ResourceProvider at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageCo nt extImpl.java:459) at web._0002fweb_0002fErrorMessage_0002ejspErrorMessage_jsp_0._jspServi ce (_0002fweb_0002fErrorMessage_0002ejspErrorMessage_jsp_0.java:296) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspSe rv let.java:177) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java: 31 8) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java: 40 4) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:37 2) at org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispat ch erImpl.java:194) at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.ja va :421) at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageCo nt extImpl.java:446) at web._0002fweb_0002fController_0002ejspController_jsp_0._jspService(_ 00 02fweb_0002fController_0002ejspController_jsp_0.java:772) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspSe rv let.java:177) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java: 31 8) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java: 40 4) at org.apache.tomcat.core.Handler.service(Handler.java:286
AW: anyone using DB2 with Tomcat/
Hay there, Yes we do. But DB2 is running on Linux, which does not make a big difference. What's wrong? need help? Roman Hi, Anyone using DB2 database with Linux/Tomcat applications? anandpa
AW: AW: wired CLASSPATH behaviour
Hay Benoit, this solved the Problem. JDBC Drivers are indicated in the lib-Folder (No Matter which ones) if they are .jar extended. Thanxs a lot. :)) Roman -Ursprüngliche Nachricht- Von: Benoit Jacquemont [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 7. Mai 2001 12:09 An: [EMAIL PROTECTED] Betreff: Re: AW: wired CLASSPATH behaviour Hi Roman, It is not a limitation of the classloader, but it's just about the way Tomcat works: it only appends jar files to its own classpath (which seems not to be the same classpath that you define within your system) which are in the WEB-INF/lib directory of the application. So, as jar files and zip files have the same file format (in fact jar files are zip files), you just need to rename them to make them taken into consideration by tomcat). Benoît hay Noel, no I have not tried this. I thought about, but this would mean that the classloader does not support .zip files anymore. And I have not heard about any change like this. But it's still a good idea. I will give it a try and report results. thx roman -Ursprüngliche Nachricht- Von: Noel E. Lecaros [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 7. Mai 2001 12:02 An: [EMAIL PROTECTED] Betreff: 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
AW: Virtual hosts
Hay Rainer, AFAIK you have to give every Virtual Host an entry in Apache as well. When I was configuring Apache to use the same application for www.myhost.com and myhost.realhost.com:8080 I had to do two entries in Apache. Well for other Webservers I don't know, and even for Apache or Tomcat I'm not sure. Basically it does not matter for you since the domain shouldn't change while a user is on a web application. Only Problems which can occure are Logfiles (not quite sure if different virtual hosts can use the same logfile) and Cookies (they are bound to a domain). Regards roman -Ursprüngliche Nachricht- Von: Rainer Mager [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 8. Mai 2001 11:36 An: [EMAIL PROTECTED] Betreff: Virtual hosts Hi all, In server.xml we have multiple virtual hosts configured with host name=www.a.com.../host tags, one for each host. This works fine if the site is hit with the exact name listed. If an alternative name is used, however, like the IP address, then Tomcat doesn't recognize it as the same virtual host. Aside from making mane host... entries, one for each potential name, how can we support multiple names? Thanks much. --Rainer
wired CLASSPATH behaviour
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
AW: wired CLASSPATH behaviour
hay Noel, no I have not tried this. I thought about, but this would mean that the classloader does not support .zip files anymore. And I have not heard about any change like this. But it's still a good idea. I will give it a try and report results. thx roman -Ursprüngliche Nachricht- Von: Noel E. Lecaros [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 7. Mai 2001 12:02 An: [EMAIL PROTECTED] Betreff: 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
AW: HANDLER THREAD PROBLEM when accessing servlet
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
AW: Still trying to configure mod_jk
Hay Sam, I dad the same Problem. I downloaded the source distribution and did the build of mod_jk.so with apxs. This compiled me a working one for Mandrake 8.0 and Apache 1.3.17. For the rest of TomCat I am using binary distribution. apxs -o mod_jk.so -I../jk -I/usr/local/jdk/include -I/usr/local/jdk/include/linux -c *.c ../jk/*.c should do the compile (adjust paths for your needs.) I had this from: http://jakarta.apache.org/tomcat/jakarta-tomcat/src/doc/mod_jk-howto.html then copy the mod_jk.so to your libexec dir which was configured in your Apache (default = PREFIX/libexec) make sure to start TomCat before Apache. (I went into this trap) then include the generated file: $YOUR_TOMCAT_HOME/conf/mod_jk.conf-auto in your httpd.conf using Include /path/to/mod_jk.conf-auto and start Apache. hope this helps a little bit. roman -Ursprüngliche Nachricht- Von: Sam Newman [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 3. Mai 2001 13:38 An: [EMAIL PROTECTED] Betreff: Re: Still trying to configure mod_jk Lots of people have this problem. The downloadable mod_jk seems to work for some people, but not all. I'd suggest downloading the mod_jk source and build it yourself. Give your system, this shouldn't be too hard. sam - Original Message - From: Laurence Mayer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 03, 2001 1:10 PM Subject: Still trying to configure mod_jk Redhat 6.2 Apache -1.3.6-1 httpd start gives the following error Syntax error on line 214 of /etc/httpd/conf/httpd.conf: API module structure 'jk_module' in file /user/libexec/apache/mod_jk.so is garbled - perhaps this is not an apache module DSO? How do I fix? Can anyone shed some light, pleeeaaassse? Desperate Laurence
AW: Tomcat documentation
Which TomCat book? Is there one planned? Or have you been kidding? roman -Ursprüngliche Nachricht- Von: Martin Mauri [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 4. Mai 2001 14:42 An: [EMAIL PROTECTED] Betreff: Re: Tomcat documentation You'll have to wait until the Tomcat book is finished :) Hi, Does anybody know, where I can find another documentation with more detailed information about Tomcat cofiguration than the minimalistic user guide? Mit freundlichen Grüßen Christian Schildt Diplom-Betriebswirt (FH) Softwaredeveloper Phone: 089/89013023 Mailto: [EMAIL PROTECTED] ELAXY AG Gutenbergstr. 5 D-82178 Puchheim bei München Phone: +089/8901300 Fax: +089/89013089 www.elaxy.com
AW: server.xml / dtd
Nope, in the /conf folder, this is the web.dtd for validating web.xml configuration files. TomCat is not coming with a server.dtd, at least slocate was not finding anything ;) I'm searching for the server.dtd as well. It's not specified in the Java Servlet Standard. So it must be something Tomcat specific. regards... ..roman. -Ursprüngliche Nachricht- Von: Hari Yellina [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 4. Mai 2001 14:43 An: [EMAIL PROTECTED] Betreff: Re: server.xml / dtd it can be found in cofig directory of u r tomcat - Original Message - From: Nathan Coast [EMAIL PROTECTED] To: tomcat user [EMAIL PROTECTED] Sent: Friday, May 04, 2001 9:39 PM Subject: server.xml / dtd Hi, where can I find the dtd of server.xml? - is there such a thing? Is the dtd the best place to find docs on server.xml or is there a complete configuration doc elsewhere? Thanks Nathan
AW: AW: Tomcat documentation
Hay Noel, yes ok. I can do some work for this. But I'm involved to TomCat since lets say 2 days. Well it's going to be a plattform for our company and therefore we will have some issues to solve and write about anyways. My english is not perfect, but I can try my best and yes, if I can help you with this, I will. I just finished my diploma thesis and miss writing anyways. :) yepp... lets go. regards roman -Ursprüngliche Nachricht- Von: Noel E. Lecaros [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 4. Mai 2001 15:22 An: [EMAIL PROTECTED] Betreff: Re: AW: Tomcat documentation Hi, Roman No, Martin is quite serious about this (despite the smiley face). It's a book on Tomcat installation, configuration and use that's being written by readers of this mailing list. It's intended to supplement the (scant) documentation there is on Tomcat. Anyone is welcome to join. The project is being hosted on sourceforge.net. Search for tomcatbook. Regards, Noel Lecaros Gerteis, Roman wrote: Which TomCat book? Is there one planned? Or have you been kidding? roman -Ursprüngliche Nachricht- Von: Martin Mauri [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 4. Mai 2001 14:42 An: [EMAIL PROTECTED] Betreff: Re: Tomcat documentation You'll have to wait until the Tomcat book is finished :) Hi, Does anybody know, where I can find another documentation with more detailed information about Tomcat cofiguration than the minimalistic user guide? Mit freundlichen Grüßen Christian Schildt Diplom-Betriebswirt (FH) Softwaredeveloper Phone: 089/89013023 Mailto: [EMAIL PROTECTED] ELAXY AG Gutenbergstr. 5 D-82178 Puchheim bei München Phone: +089/8901300 Fax: +089/89013089 www.elaxy.com
AW: server.xml / dtd
DTD's (or XML-Schemas) are great. they will tell you all options you have inside a XML file. Where to know from which elements are allowed inside a XML file? DTD tells you this. If you create a server.xml any parser can check your file if it is not only wellformed, you will know if it is valid and this is great. This makes it much easier for you writing server.xml files. Then you know if Tomcat is producing an error reading your config or you had an error inside your elements. And... xml files are not really useful without DTD's .. that's what I think. regards roman -Ursprüngliche Nachricht- Von: Hari Yellina [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 4. Mai 2001 15:33 An: [EMAIL PROTECTED] Betreff: Re: server.xml / dtd why do you require DTD. To check whether it is a validate documet. it is ,u dont have to worry much. One more thing it. If it is a XML file. You dont neccesarily require a DTD. Regard, Yellina - Original Message - From: Gerteis, Roman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 04, 2001 11:10 PM Subject: AW: server.xml / dtd Nope, in the /conf folder, this is the web.dtd for validating web.xml configuration files. TomCat is not coming with a server.dtd, at least slocate was not finding anything ;) I'm searching for the server.dtd as well. It's not specified in the Java Servlet Standard. So it must be something Tomcat specific. regards... ..roman. -Ursprüngliche Nachricht- Von: Hari Yellina [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 4. Mai 2001 14:43 An: [EMAIL PROTECTED] Betreff: Re: server.xml / dtd it can be found in cofig directory of u r tomcat - Original Message - From: Nathan Coast [EMAIL PROTECTED] To: tomcat user [EMAIL PROTECTED] Sent: Friday, May 04, 2001 9:39 PM Subject: server.xml / dtd Hi, where can I find the dtd of server.xml? - is there such a thing? Is the dtd the best place to find docs on server.xml or is there a complete configuration doc elsewhere? Thanks Nathan
