DO NOT REPLY [Bug 19799] - Tomcat dies after being up for a while (complains about maxThreads)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19799. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19799 Tomcat dies after being up for a while (complains about maxThreads) --- Additional Comments From [EMAIL PROTECTED] 2003-08-15 08:00 --- Created an attachment (id=7830) catalina.out with full thread dump. Snipped to remove earlier startups and System.out.printlns - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19799] - Tomcat dies after being up for a while (complains about maxThreads)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19799. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19799 Tomcat dies after being up for a while (complains about maxThreads) --- Additional Comments From [EMAIL PROTECTED] 2003-08-15 08:01 --- Bingo, the problem seems to be in a deadlock on JspServletWrappers somehow. I've attached the log of the kill -3. This was dumped inside catalina.out, and it might be interesting to notice that there had been quite a few warnings about RESETs. Leave it up to Remy to decide to reopen or not... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22451] New: - $CATALINA_HOME/conf/jk directory missing in binary 4.1.27-LE-jdk141 tar ball
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22451. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22451 $CATALINA_HOME/conf/jk directory missing in binary 4.1.27-LE-jdk141 tar ball Summary: $CATALINA_HOME/conf/jk directory missing in binary 4.1.27-LE-jdk141 tar ball Product: Tomcat 4 Version: 4.1.27 Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When working with apache 1.3.27/mod_jk 1.1 and jakarta-tomcat 4.1.27-LE-jdk141, I am missing the $CATALINA_HOME/conf/jk direcroty and workers.properties especially. Has something changes or is this just a minor mistake in packaging? jakarta-tomcat-4.1.27-LE-jdk14.tar.gz downloaded from apache mirror Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19799] - Tomcat dies after being up for a while (complains about maxThreads)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19799. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19799 Tomcat dies after being up for a while (complains about maxThreads) --- Additional Comments From [EMAIL PROTECTED] 2003-08-15 11:01 --- Created an attachment (id=7832) Thread dump - reduced to 3 threads (jsp compiler,unix process,waiting jsp wrapper) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSP 2.0 Jasper in Jetty 5
I've just started checking the integration of jasper from 5.0.7 in Jetty 5, and felt compelled to send a quick thank you note. Integration has been totally painless and the results appear to be a very fast and snappy! Also the 2.0 features are very cool - I'll have to stop making nasty remarks about JSPs!-) So thanks again for jasper! Good work guys! -- Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462 Mort Bay Consulting Australia and UK. http://www.mortbay.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP 2.0 Jasper in Jetty 5
On Fri, 15 Aug 2003, Greg Wilkins wrote: Integration has been totally painless and the results appear to be a very fast and snappy! I'd like to second that. I've managed to integrate Jasper into a number of non-tomcat Servlet 2.3 containers for using tagfiles. I've also been able to add a small extension ( Class getTag(String tagfileUri) ) for programmatic tag file invocation. And it worked impressively easy and well. Chapeau! Matthias -- Matthias Ernst Software Engineer CoreMedia - Smart Content Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
limits the access of upper directory
Dear Sir/Madam: I have used Tomcat to make a web site, please see: http://bac-portal.mc.vanderbilt.edu/BAC/BACWEB.jsp Would you please tell me how I can limit the access to whole name of this site only? For example. now people can access (by deleting /BACWEB.jsp): http://bac-portal.mc.vanderbilt.edu/BAC where I have other sites developing. Thank you a lot for give me the convenience to built this web site. Tomcat is great. Zhongjun Luo, Ph.D. Research Assistant Professor Genetic Medicine Department Vanderbilt University Medical Center Nashville, TN 37232
DO NOT REPLY [Bug 22466] New: - StackOverflowError in ResponseBase.write (no recursion)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22466. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22466 StackOverflowError in ResponseBase.write (no recursion) Summary: StackOverflowError in ResponseBase.write (no recursion) Product: Tomcat 4 Version: 4.0.2 Final Platform: Other OS/Version: Other Status: NEW Severity: Blocker Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We have a JSP page that brings down JBoss with a StackOverflowError exception when it iterates too many (2419) times. We are using JBoss 2.4.4 and Struts 1.0.2 on SCO 5.0.6 with Caldera-UNIX-J2SE-1.3.0_02 (green threads, sunwjit). I am including the stack trace and JSP code below. There is no recursion, the stack has only 60 frames. Also, our javac has no -Xss (stack size) option. When it crashes, the browser (not surprisingly) receives incomplete HTML (approx 3 Mb). One bit of explanation about the JSP: we used a file called GUIStyle.properties to contain common HTML snippets. (And yes, we are currently converting to CSS :-) I would greatly appreciate any fix or workaround suggestions, pointers to known bugs causing this, or recommendations for further debugging. Thanks in advance. P.S. I just confirmed that JBoss running on Win2k does NOT exhibit this problem. However, since virtually all of the code in the stack trace is JBoss', I don't think this can be easily dismissed as an OS or JVM problem. I am working to reduce the JSP to something smaller and repeatable. --- Stack Trace: --- 2003-08-13 11:32:51,361 HttpProcessor[8080][4]/ERROR: ApplicationDispatcher [/webconfig] Servlet.service() for servlet jsp threw exception javax.servlet.ServletException at org.apache.jasper.runtime.PageContextImpl.handlePageException (PageContextImpl.java:457) at org.apache.jsp.agentList$jsp._jspService(agentList$jsp.java, Compiled Code) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service (JspServlet.java, Compiled Code) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java, Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke (ApplicationDispatcher.java, Compiled Code) at org.apache.catalina.core.ApplicationDispatcher.doForward (ApplicationDispatcher.java, Compiled Code) at org.apache.catalina.core.ApplicationDispatcher.forward (ApplicationDispatcher.java:355) at org.apache.struts.action.RequestProcessor.doForward (RequestProcessor.java:961) at org.apache.struts.action.RequestProcessor.processActionForward (RequestProcessor.java:400) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java, Compiled Code) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1227) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:484) at javax.servlet.http.HttpServlet.service(HttpServlet.java, Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java, Compiled Code) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java, Compiled Code) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java, Compiled Code) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java, Compiled Code) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java, Compiled Code) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java, Compiled Code) at org.apache.catalina.valves.CertificatesValve.invoke (CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java, Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java, Compiled Code) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:164) at org.apache.catalina.core.StandardPipeline.invokeNext
Re: limits the access of upper directory
Hi Luo, You can create an index.jsp or index.html page in that directory and people will no longer be able to list the directory contents. - MArk Luo, Zhongjun wrote: Dear Sir/Madam: I have used Tomcat to make a web site, please see: http://bac-portal.mc.vanderbilt.edu/BAC/BACWEB.jsp Would you please tell me how I can limit the access to whole name of this site only? For example. now people can access (by deleting /BACWEB.jsp): http://bac-portal.mc.vanderbilt.edu/BAC where I have other sites developing. Thank you a lot for give me the convenience to built this web site. Tomcat is great. Zhongjun Luo, Ph.D. Research Assistant Professor Genetic Medicine Department Vanderbilt University Medical Center Nashville, TN 37232 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: limits the access of upper directory
Rule #1 - don't post configuration or use questions to the tomcat-dev list...that's what tomcat-user is for. That said, look at ./conf/web.xml for the 'listings' init-param of DefaultServlet. Setting this parameter to 'false' will deny directory listings. -chris -Original Message- From: Luo, Zhongjun [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2003 11:41 AM To: [EMAIL PROTECTED] Subject: limits the access of upper directory Dear Sir/Madam: I have used Tomcat to make a web site, please see: http://bac-portal.mc.vanderbilt.edu/BAC/BACWEB.jsp Would you please tell me how I can limit the access to whole name of this site only? For example. now people can access (by deleting /BACWEB.jsp): http://bac-portal.mc.vanderbilt.edu/BAC where I have other sites developing. Thank you a lot for give me the convenience to built this web site. Tomcat is great. Zhongjun Luo, Ph.D. Research Assistant Professor Genetic Medicine Department Vanderbilt University Medical Center Nashville, TN 37232
Re: JSP 2.0 Jasper in Jetty 5
Greg, Thanks - the new features in JSP 2.0 are directly as a result of feedback from the Java community. We've received some excellent feedback, and the JSP expert group, composed of over 30 experts from various companies, has done a great job processing the most requested features and making this happen. I hope we can continue this going forward, so remember to send all your JSP specification feedback, be it positive or negative, to [EMAIL PROTECTED] --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. Greg Wilkins wrote: I've just started checking the integration of jasper from 5.0.7 in Jetty 5, and felt compelled to send a quick thank you note. Integration has been totally painless and the results appear to be a very fast and snappy! Also the 2.0 features are very cool - I'll have to stop making nasty remarks about JSPs!-) So thanks again for jasper! Good work guys! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22388] - TC 5.0.7 Startup Exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22388. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22388 TC 5.0.7 Startup Exception [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-08-15 19:46 --- I have seen this. At this point, I believe it is a MX4J bug (there's only one thread during the Tomcat init, so I don't see what could be wrong). Tomcat 5 final will not ship with this JMX implementation: it will be either MX4J 1.2 or the JMX 1.2 RI with remoting. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21206] - Tomcat 5 - Jetspeed JSP Portlets do not display
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21206. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21206 Tomcat 5 - Jetspeed JSP Portlets do not display [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-08-15 19:49 --- You likely have a problem compiling JSPs. This works for me. Please don't reopen the bug, unless you can make a more convincing argument there's a Tomcat flaw. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19799] - Tomcat dies after being up for a while (complains about maxThreads)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19799. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19799 Tomcat dies after being up for a while (complains about maxThreads) --- Additional Comments From [EMAIL PROTECTED] 2003-08-15 20:07 --- That's a sync point which occurs when Jasper is in dev mode (on each access, Jasper checks for recompilation). Please read the Jasper docs (set the development init param to false in $CATALINA_HOME/conf/web.xml). I'll examine the stacktrace for a deadlock, but this particular configuration should never be put in production (it has terrible performance). Thread dumps like this are very useful info to debug contention, deadlocks, infinite loops, etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22388] - TC 5.0.7 Startup Exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22388. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22388 TC 5.0.7 Startup Exception --- Additional Comments From [EMAIL PROTECTED] 2003-08-15 21:03 --- Invalid ? Are you saying that if TC ships with MX4J 1.2 that this won't be an issue ? You know this is fixed ? I assume that the 'JMX 1.2 RI with remoting' is another code line. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler TagLibraryInfoImpl.java
luehe 2003/08/15 14:01:41
Modified:jasper2/src/share/org/apache/jasper/compiler
TagLibraryInfoImpl.java
Log:
Restored JSP default for 1.2 based tag handlers
Revision ChangesPath
1.44 +11 -19
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
Index: TagLibraryInfoImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- TagLibraryInfoImpl.java 24 Jul 2003 01:17:33 - 1.43
+++ TagLibraryInfoImpl.java 15 Aug 2003 21:01:41 - 1.44
@@ -370,7 +370,14 @@
String tagName = null;
String tagClassName = null;
String teiClassName = null;
-String bodycontent = null;
+
+/*
+ * Default body content for JSP 1.2 tag handlers (body-content has
+ * become mandatory in JSP 2.0, because the default would be invalid
+ * for simple tag handlers)
+ */
+String bodycontent = JSP;
+
String info = null;
String displayName = null;
String smallIcon = null;
@@ -420,21 +427,6 @@
tname));
}
}
- }
-
- // Determine appropriate default value for body-content
- if (bodycontent == null) {
-try {
-Class tagClass = ctxt.getClassLoader().loadClass(tagClassName);
- if (SimpleTag.class.isAssignableFrom(tagClass)) {
- bodycontent = TagInfo.BODY_CONTENT_SCRIPTLESS;
- } else {
- bodycontent = TagInfo.BODY_CONTENT_JSP;
- }
- } catch (Exception e) {
-err.jspError(jsp.error.loadclass.taghandler, tagClassName,
- tagName);
-}
}
TagExtraInfo tei = null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[j-t-c] Thread problem in jk_uri_worker_map.c
I've run into a threading problem in /j-t-c/native/jk/common/jk_uri_worker_map.c. The problem has been around for a long time, but I believe the changes checked in for version 1.15 on June, 27, 2003 made the problem worse. I have only been able to reproduce the problem on multi-processor machines running under a fairly heavy load. Unfortunately, I don't have a good solution, yet. The worker map contains a temp pool (jk_uri_worker_map.tp) that is used in the map_uri_to_worker() function. The temp pool is used to store a copy of the incoming URI so that it can be altered to remove any jsessionid and to remove multiple adjacent / characters. The problem is that this single pool is shared by all the worker threads so if multiple threads are executing map_uri_to_worker() simultaneously there is a chance that the pool will get corrupted. This can happen in two ways. The jk_pool code is not thread safe so the internal state of the pool may be corrupted. Second, the map_uri_to_worker() function always calls jk_pool_reset() after mapping the URI. This means that if multiple URIs did get allocated into the pool without corruption, when the first thread finishes it will reset the pool. This may not create a noticeable problem because the memory in the pools isn't overwritten by a reset. If the other threads finish before another thread enters map_uri_to_worker() then nothing will fail. However, if another thread does enter map_uri_to_worker() then its call to jk_pool_strdup() will overwrite some of the previous contents of the pool and really bad things may happen. As I said, I don't have a solution, yet. Any solution would have to be platform independent and also work with all the Web servers that use the JK plugin (e.g. Apache 1.3, Apache 2.0, ISAPI, Netscape, ...). Suggestions? -- Marc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [j-t-c] Thread problem in jk_uri_worker_map.c
The easiest solution would be to change the map_uri_to_worker contract to be that the uri parameter is modifiable. Then Apache can dup it using the request's pool, it looks like IIS is doing this most of the time anyway, and Netscape isn't using map_uri_to_worker at all. That leave Domino, which I don't really know. - Original Message - From: Marc Saegesser [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 15, 2003 3:11 PM Subject: [j-t-c] Thread problem in jk_uri_worker_map.c I've run into a threading problem in /j-t-c/native/jk/common/jk_uri_worker_map.c. The problem has been around for a long time, but I believe the changes checked in for version 1.15 on June, 27, 2003 made the problem worse. I have only been able to reproduce the problem on multi-processor machines running under a fairly heavy load. Unfortunately, I don't have a good solution, yet. The worker map contains a temp pool (jk_uri_worker_map.tp) that is used in the map_uri_to_worker() function. The temp pool is used to store a copy of the incoming URI so that it can be altered to remove any jsessionid and to remove multiple adjacent / characters. The problem is that this single pool is shared by all the worker threads so if multiple threads are executing map_uri_to_worker() simultaneously there is a chance that the pool will get corrupted. This can happen in two ways. The jk_pool code is not thread safe so the internal state of the pool may be corrupted. Second, the map_uri_to_worker() function always calls jk_pool_reset() after mapping the URI. This means that if multiple URIs did get allocated into the pool without corruption, when the first thread finishes it will reset the pool. This may not create a noticeable problem because the memory in the pools isn't overwritten by a reset. If the other threads finish before another thread enters map_uri_to_worker() then nothing will fail. However, if another thread does enter map_uri_to_worker() then its call to jk_pool_strdup() will overwrite some of the previous contents of the pool and really bad things may happen. As I said, I don't have a solution, yet. Any solution would have to be platform independent and also work with all the Web servers that use the JK plugin (e.g. Apache 1.3, Apache 2.0, ISAPI, Netscape, ...). Suggestions? -- Marc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22477] New: - Modifying classes in WEB-INF/classes causes Exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22477. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22477 Modifying classes in WEB-INF/classes causes Exception Summary: Modifying classes in WEB-INF/classes causes Exception Product: Tomcat 4 Version: 4.1.27 Platform: Sun URL: http://localhost:8080/examples/jsp/num/numguess.jsp OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When modifying a class in WEB-INF/classes that is used in a jsp that resides in a reloadable context, Tomcat will report an internal server error. To recreate the problem: 1) Install Tomcat 4.1.27 and use the default installation 2) Request a page in the examples context (which uses reloadable=true) For example http://localhost:8080/examples/jsp/num/numguess.jsp 3) *touch* the class file used in the requested jsp For example: % cd $CATALINA_HOME/webapps/examples/WEB-INF/classes/num % touch NumberGuessBean.class 4) View logfiles to verify WebappClassLoader has found the modified class 5) Request the same jsp page again without restarting Tomcat 6) Witness the bug This problem is not specific to the examples context that ships with Tomcat. I ran into it working on my own webapp trying to take advantage of the reloadable=true feature of Tomcat. While developing, I recompile often and it's handy not to have to restart Tomcat after every change. I havn't testing this with 4.1.24, so I don't know if this bug has just recently been introduced. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationContext.java
luehe 2003/08/15 17:35:32
Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java
Log:
Clone attribute names iterator, to avoid
java.lang.ConcurrentModificationException when removing attribute
while iterating over attribute names
Revision ChangesPath
1.17 +5 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
Index: ApplicationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- ApplicationContext.java 12 Aug 2003 23:01:36 - 1.16
+++ ApplicationContext.java 16 Aug 2003 00:35:32 - 1.17
@@ -260,7 +260,7 @@
public Enumeration getAttributeNames() {
synchronized (attributes) {
-return (new Enumerator(attributes.keySet()));
+return new Enumerator(attributes.keySet(), true);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java
luehe 2003/08/15 17:39:33
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java
Log:
Clone attribute names iterator, to avoid
java.lang.ConcurrentModificationException when removing attribute
while iterating over attribute names
Revision ChangesPath
1.13 +5 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
Index: CoyoteRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- CoyoteRequest.java9 Aug 2003 19:04:55 - 1.12
+++ CoyoteRequest.java16 Aug 2003 00:39:33 - 1.13
@@ -968,7 +968,7 @@
* empty codeEnumeration/code if there are none.
*/
public Enumeration getAttributeNames() {
-return (new Enumerator(attributes.keySet()));
+return new Enumerator(attributes.keySet(), true);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
JkCoyoteHandler with SSL
While using Apache2.0.47 and Tomcat 4.1.24 integrated with JBOSS 3.2.1 on a Win2000 box. I get the following exception from the Tomcat JkCoyoteHandler when making a https call If I hit the ok button several times when it pops up the Select your Certificate box in windows it processes the request as you can see by the output I'm able to correctly process the SSL information being sent across the wire. The Certificate is a pk7 which was built from x509 Any help with this issue would be greatly appreciated. I've struggled long and hard with the SSL communication between Apache and Tomcat and it looks like I'm very close to having it. Except for the following error. One last thing: mod_sll.so (came with the Apache2.0 distribution) mod_jdk_2.0.46.dll 19:43:29,503 INFO [Server] JBoss (MX MicroKernel) [3.2.1 (build: CVSTag=JBoss_3 _2_1 date=200305041533)] Started in 1m:39s:313ms 19:44:49,248 ERROR [JkCoyoteHandler] Certificate convertion failed java.security.cert.CertificateException: Unable to initialize, java.io.IOExcepti on: DerInputStream.getLength(): lengthTag=127, too big. at sun.security.x509.X509CertImpl.init(X509CertImpl.java:289) at sun.security.provider.X509Factory.engineGenerateCertificate(X509Facto ry.java:94) at java.security.cert.CertificateFactory.generateCertificate(Certificate Factory.java:389) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:395) at org.apache.coyote.Response.action(Response.java:222) at org.apache.coyote.tomcat4.CoyoteAdapter.postParseRequest(CoyoteAdapte r.java:310) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:22 1) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.ja va:562) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:619) at java.lang.Thread.run(Thread.java:536) Caused by: java.io.IOException: DerInputStream.getLength(): lengthTag=127, too b ig. at sun.security.util.DerInputStream.getLength(DerInputStream.java:502) at sun.security.util.DerInputStream.getLength(DerInputStream.java:476) at sun.security.util.DerValue.init(DerValue.java:233) at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:358) at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1608) at sun.security.x509.X509CertImpl.init(X509CertImpl.java:286) ... 13 more . . 19:45:12,001 INFO [Engine] CoyoteAdapter Requested cookie session id is 01BD9D C9B2EF687EE90F8FAD8147B49F 19:45:12,001 ERROR [JkCoyoteHandler] Certificate convertion failed java.security.cert.CertificateException: Unable to initialize, java.io.IOExcepti on: DerInputStream.getLength(): lengthTag=102, too big. at sun.security.x509.X509CertImpl.init(X509CertImpl.java:289) at sun.security.provider.X509Factory.engineGenerateCertificate(X509Facto ry.java:94) at java.security.cert.CertificateFactory.generateCertificate(Certificate Factory.java:389) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:395) at org.apache.coyote.Response.action(Response.java:222) at org.apache.coyote.tomcat4.CoyoteAdapter.postParseRequest(CoyoteAdapte r.java:310) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:22 1) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.ja va:562) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:619) at java.lang.Thread.run(Thread.java:536) Caused by: java.io.IOException: DerInputStream.getLength(): lengthTag=102, too b ig. at sun.security.util.DerInputStream.getLength(DerInputStream.java:502) at sun.security.util.DerInputStream.getLength(DerInputStream.java:476) at sun.security.util.DerValue.init(DerValue.java:233) at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:358) at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1608) at sun.security.x509.X509CertImpl.init(X509CertImpl.java:286) ... 13 more 19:46:56,281 INFO [Engine] action: Processing a POST for /logon 19:46:56,291 INFO [Engine] action: Setting locale 'en_US'
Re: JkCoyoteHandler with SSL
Client-certs don't work with JkCoyote on 4.1.24. You need to use 4.1.27 (or, at least the tomcat-jk2.jar). - Original Message - From: Ben Sifuentes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 15, 2003 5:45 PM Subject: JkCoyoteHandler with SSL While using Apache2.0.47 and Tomcat 4.1.24 integrated with JBOSS 3.2.1 on a Win2000 box. I get the following exception from the Tomcat JkCoyoteHandler when making a https call If I hit the ok button several times when it pops up the Select your Certificate box in windows it processes the request as you can see by the output I'm able to correctly process the SSL information being sent across the wire. The Certificate is a pk7 which was built from x509 Any help with this issue would be greatly appreciated. I've struggled long and hard with the SSL communication between Apache and Tomcat and it looks like I'm very close to having it. Except for the following error. One last thing: mod_sll.so (came with the Apache2.0 distribution) mod_jdk_2.0.46.dll 19:43:29,503 INFO [Server] JBoss (MX MicroKernel) [3.2.1 (build: CVSTag=JBoss_3 _2_1 date=200305041533)] Started in 1m:39s:313ms 19:44:49,248 ERROR [JkCoyoteHandler] Certificate convertion failed java.security.cert.CertificateException: Unable to initialize, java.io.IOExcepti on: DerInputStream.getLength(): lengthTag=127, too big. at sun.security.x509.X509CertImpl.init(X509CertImpl.java:289) at sun.security.provider.X509Factory.engineGenerateCertificate(X509Facto ry.java:94) at java.security.cert.CertificateFactory.generateCertificate(Certificate Factory.java:389) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:395) at org.apache.coyote.Response.action(Response.java:222) at org.apache.coyote.tomcat4.CoyoteAdapter.postParseRequest(CoyoteAdapte r.java:310) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:22 1) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.ja va:562) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:619) at java.lang.Thread.run(Thread.java:536) Caused by: java.io.IOException: DerInputStream.getLength(): lengthTag=127, too b ig. at sun.security.util.DerInputStream.getLength(DerInputStream.java:502) at sun.security.util.DerInputStream.getLength(DerInputStream.java:476) at sun.security.util.DerValue.init(DerValue.java:233) at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:358) at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1608) at sun.security.x509.X509CertImpl.init(X509CertImpl.java:286) ... 13 more . . 19:45:12,001 INFO [Engine] CoyoteAdapter Requested cookie session id is 01BD9D C9B2EF687EE90F8FAD8147B49F 19:45:12,001 ERROR [JkCoyoteHandler] Certificate convertion failed java.security.cert.CertificateException: Unable to initialize, java.io.IOExcepti on: DerInputStream.getLength(): lengthTag=102, too big. at sun.security.x509.X509CertImpl.init(X509CertImpl.java:289) at sun.security.provider.X509Factory.engineGenerateCertificate(X509Facto ry.java:94) at java.security.cert.CertificateFactory.generateCertificate(Certificate Factory.java:389) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:395) at org.apache.coyote.Response.action(Response.java:222) at org.apache.coyote.tomcat4.CoyoteAdapter.postParseRequest(CoyoteAdapte r.java:310) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:22 1) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.ja va:562) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:619) at java.lang.Thread.run(Thread.java:536) Caused by: java.io.IOException: DerInputStream.getLength(): lengthTag=102, too b ig. at sun.security.util.DerInputStream.getLength(DerInputStream.java:502) at sun.security.util.DerInputStream.getLength(DerInputStream.java:476) at sun.security.util.DerValue.init(DerValue.java:233) at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:358) at
Re: JkCoyoteHandler with SSL
Look at the bug 15790. http://issues.apache.org/bugzilla/show_bug.cgi?id=15790 This problem was fixed in 4.1.25 or later. Ben Sifuentes wrote: While using Apache2.0.47 and Tomcat 4.1.24 integrated with JBOSS 3.2.1 on a Win2000 box. I get the following exception from the Tomcat JkCoyoteHandler when making a https call If I hit the ok button several times when it pops up the Select your Certificate box in windows it processes the request as you can see by the output I'm able to correctly process the SSL information being sent across the wire. The Certificate is a pk7 which was built from x509 Any help with this issue would be greatly appreciated. I've struggled long and hard with the SSL communication between Apache and Tomcat and it looks like I'm very close to having it. Except for the following error. One last thing: mod_sll.so (came with the Apache2.0 distribution) mod_jdk_2.0.46.dll 19:43:29,503 INFO [Server] JBoss (MX MicroKernel) [3.2.1 (build: CVSTag=JBoss_3 _2_1 date=200305041533)] Started in 1m:39s:313ms 19:44:49,248 ERROR [JkCoyoteHandler] Certificate convertion failed java.security.cert.CertificateException: Unable to initialize, java.io.IOExcepti on: DerInputStream.getLength(): lengthTag=127, too big. at sun.security.x509.X509CertImpl.init(X509CertImpl.java:289) at sun.security.provider.X509Factory.engineGenerateCertificate(X509Facto ry.java:94) at java.security.cert.CertificateFactory.generateCertificate(Certificate Factory.java:389) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:395) at org.apache.coyote.Response.action(Response.java:222) at org.apache.coyote.tomcat4.CoyoteAdapter.postParseRequest(CoyoteAdapte r.java:310) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:22 1) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.ja va:562) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:619) at java.lang.Thread.run(Thread.java:536) Caused by: java.io.IOException: DerInputStream.getLength(): lengthTag=127, too b ig. at sun.security.util.DerInputStream.getLength(DerInputStream.java:502) at sun.security.util.DerInputStream.getLength(DerInputStream.java:476) at sun.security.util.DerValue.init(DerValue.java:233) at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:358) at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1608) at sun.security.x509.X509CertImpl.init(X509CertImpl.java:286) ... 13 more . . 19:45:12,001 INFO [Engine] CoyoteAdapter Requested cookie session id is 01BD9D C9B2EF687EE90F8FAD8147B49F 19:45:12,001 ERROR [JkCoyoteHandler] Certificate convertion failed java.security.cert.CertificateException: Unable to initialize, java.io.IOExcepti on: DerInputStream.getLength(): lengthTag=102, too big. at sun.security.x509.X509CertImpl.init(X509CertImpl.java:289) at sun.security.provider.X509Factory.engineGenerateCertificate(X509Facto ry.java:94) at java.security.cert.CertificateFactory.generateCertificate(Certificate Factory.java:389) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:395) at org.apache.coyote.Response.action(Response.java:222) at org.apache.coyote.tomcat4.CoyoteAdapter.postParseRequest(CoyoteAdapte r.java:310) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:22 1) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.ja va:562) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:619) at java.lang.Thread.run(Thread.java:536) Caused by: java.io.IOException: DerInputStream.getLength(): lengthTag=102, too b ig. at sun.security.util.DerInputStream.getLength(DerInputStream.java:502) at sun.security.util.DerInputStream.getLength(DerInputStream.java:476) at sun.security.util.DerValue.init(DerValue.java:233) at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:358) at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1608) at sun.security.x509.X509CertImpl.init(X509CertImpl.java:286) ... 13 more
DO NOT REPLY [Bug 21206] - Tomcat 5 - Jetspeed JSP Portlets do not display
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21206. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21206 Tomcat 5 - Jetspeed JSP Portlets do not display [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-08-16 02:06 --- Remy, Ok, I'm sure I would have noticed if my normal JSP weren't compiling but just to be sure about whether JSPs would compile, I just now went through and clicked on all the JSP examples provided with Tomcat 5.0.7 and every one of them is working just fine. Granted they're not too complicated but I'm not seeing any problem at all compiling JSPs so far with 5.0.7. I went and dropped the original jetspeed.war into webapps and then added a JSP Portlet and received the same error as I reported above. This time I noticed another exception in the log that may help: INFO: Server startup in 20610 ms java.lang.IllegalArgumentException: -82 at org.apache.jasper.compiler.SmapStratum$LineInfo.setOutputLineIncrement(SmapStratum.java:124) at org.apache.jasper.compiler.SmapStratum.optimizeLineSection(SmapStratum.java:221) at org.apache.jasper.compiler.SmapUtil.evaluateNodes(SmapUtil.java:490) at org.apache.jasper.compiler.SmapUtil.generateSmap(SmapUtil.java:123) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:301) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:453) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:555) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:300) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:293) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:286) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:752) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:640) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:552) at org.apache.turbine.services.jsp.TurbineJspService.handleRequest(TurbineJspService.java:202) at org.apache.turbine.services.jsp.TurbineJspService.handleRequest(TurbineJspService.java:163) at org.apache.jetspeed.portal.portlets.viewprocessor.JSPViewProcessor.processView(JSPViewProcessor.java:170) at org.apache.jetspeed.portal.portlets.GenericMVCPortlet.buildContent(GenericMVCPortlet.java:301) at org.apache.jetspeed.portal.portlets.GenericMVCPortlet.getContent(GenericMVCPortlet.java:219) at org.apache.jetspeed.portal.security.portlets.PortletWrapper.getContent(PortletWrapper.java:148) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:260) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:207) at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:250) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:94) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:109) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:94) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:109) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:271) at org.apache.velocity.Template.merge(Template.java:296) at org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java:492) at org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java:461) at org.apache.turbine.services.velocity.TurbineVelocityService.decodeRequest(TurbineVelocityService.java:494) at
DO NOT REPLY [Bug 21206] - Tomcat 5 - Jetspeed JSP Portlets do not display
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21206. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21206 Tomcat 5 - Jetspeed JSP Portlets do not display [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-16 02:23 --- IllegalArgumentException in setOutputLineIncrement() is Bugzilla Bug 22277, and is fixed in CVS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/etc bootstrap.MF
remm2003/08/15 19:36:20 Modified:catalina/etc bootstrap.MF Log: - Put commons-daemon in the classpath. Revision ChangesPath 1.3 +1 -1 jakarta-tomcat-catalina/catalina/etc/bootstrap.MF Index: bootstrap.MF === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/etc/bootstrap.MF,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- bootstrap.MF 17 Jan 2003 09:55:22 - 1.2 +++ bootstrap.MF 16 Aug 2003 02:36:20 - 1.3 @@ -1,5 +1,5 @@ Manifest-Version: 1.0 Main-Class: org.apache.catalina.startup.Bootstrap -Class-Path: commons-launcher.jar +Class-Path: commons-daemon.jar Specification-Title: Catalina Specification-Version: 1.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs setup.xml
remm2003/08/15 19:39:33 Modified:webapps/docs setup.xml Log: - Document using commons-daemon with Tomcat on Unix. Revision ChangesPath 1.3 +51 -1 jakarta-tomcat-catalina/webapps/docs/setup.xml Index: setup.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/setup.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- setup.xml 24 Jul 2003 17:16:56 - 1.2 +++ setup.xml 16 Aug 2003 02:39:32 - 1.3 @@ -44,7 +44,8 @@ JSP pages at runtime. Either all webapps will need to be precompiled (this can be easily done using the Tomcat deployer), or the codelib\tools.jar/code file from a JDK installation -to the codecommon\lib/code path of the Tomcat installation. +must be copied to the codecommon\lib/code path of the Tomcat +installation. /li listrongTray icon/strong: When Tomcat is run as a service, there will not be any tray icon present when Tomcat is running. Note that @@ -56,6 +57,55 @@ pThe installer will create shortcuts allowing starting and configuring Tomcat. It is important to note that Tomcat administration web application can only be used when Tomcat is started./p + + /section + + section name=Unix daemon + +pTomcat can be run as a daemon using the jsvc tool from the + commons-daemon project. Source tarballs for jsvc are included with the + Tomcat binaries, and need to be compiled. Building jsvc requires + a C ANSI compiler (such as GCC), GNU Autoconf, and a JDK./p + +pBefore running the script, the codeJAVA_HOME/code environment + variable should be set to the base path of the JDK. Alternately, when + calling the code./configure/code script, the path of the JDK may + be specified using the code--with-java/code parameter, such as + code./configure --with-java=/usr/java/code./p + +pUsing the following commands should result in a compiled jsvc binary, + located in the code$CATALINA_HOME/bin/code folder. This assumes + that GNU TAR is used, and that codeCATALINA_HOME/code is an + environment variable pointing to the base path of the Tomcat + installation./p + +source +cd $CATALINA_HOME/bin +tar xvfz jsvc.tar.gz +cd jsvc +autoconf +./configure +make +cp jsvc .. +cd .. +/source + +pTomcat can then be run as a daemon using the following commands./p + +source +cd $CATALINA_HOME +./bin/jsvc -Djava.endorsed.dirs=./common/endorsed -cp ./bin/bootstrap.jar \ +-outfile ./logs/catalina.out -errfile ./logs/catalina.err \ +org.apache.catalina.startup.Bootstrap +/source + +pjsvc has other useful parameters, such as code-user/code which + causes to switch to another user after the daemon initialization is + complete. This allows, for example, running Tomcat as a non priviledged + user while still being able to use privileged ports. + codejsvc --help/code will return the full jsvc usage + information. In particular, the code-debug/code option is useful + to debug issues running jsvc./p /section - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs setup.xml
billbarker2003/08/15 20:37:48 Modified:webapps/docs setup.xml Log: Adding a note about the tomcat.sh file to start Tomcat as a service on *nix systems. Revision ChangesPath 1.4 +5 -0 jakarta-tomcat-catalina/webapps/docs/setup.xml Index: setup.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/setup.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- setup.xml 16 Aug 2003 02:39:32 - 1.3 +++ setup.xml 16 Aug 2003 03:37:48 - 1.4 @@ -107,6 +107,11 @@ information. In particular, the code-debug/code option is useful to debug issues running jsvc./p +pThe file code$CATALINA_HOME/bin/jsvc/native/tomcat.sh/code can be + used as a template for starting Tomcat automatically at boot time from + code/etc/init.d/code. The file is currently setup for running + Tomcat4.1.x, so it is necessary to edit it and change the classname + from codeBootstrapService/code to codeBootstrap/code./p /section /body - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22183] - Copy of Jasper in WEB-INF confuses Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22183. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22183 Copy of Jasper in WEB-INF confuses Tomcat [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-08-16 03:54 --- The jar for jasper should not be placed inside a web application. To ensure that this does not cause problems if the jar for jasper gets placed in a web apps /WEB-INF/lib when you run Tomcat, start Tomcat with the -security option. This puts in place package access restrictions which will prevent org.apache.jasper classes from being loaded by the web application class loader. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22478] New: - Ant manager deploy causing webapp to initialize twice
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22478. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22478 Ant manager deploy causing webapp to initialize twice Summary: Ant manager deploy causing webapp to initialize twice Product: Tomcat 5 Version: 5.0.7 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If have my webapp sitting in CATALINA_HOME/webapps and my context configuration file in conf/Catalina/localhost before Tomcat starts, initialization is done once. If, however, I do a deploy using the Ant manager deploy task, initialization is performed twice. Actually, this happens more clearly after an Ant manager deploy + html manager undeploy + Ant manager deploy. The first time it is deployed, I get an exception from digester which seems to prevent the duplicate initialization. I'll be attaching text file showing the log output from stdout.log (I run Tomcat as a WinXP service) and localhost_log that shows the stack traces. Like I said, it is more clear the duplicate initialization is happening after a deploy + undeploy + deploy. Here is what it looks like beginning with the undeploy... 3124297 [http8080-Processor25] INFO org.apache.catalina.core.ContainerBase - Removing web application at context path /Barracuda 3125031 [http8080-Processor25] INFO org.apache.catalina.logger.LoggerBase - unregistering logger Catalina:type=Logger,path=/Barracuda,host=localhost 3192547 [http8080-Processor24] INFO org.apache.catalina.core.StandardHostDeployer - Installing web application from Config file URL file:/D:/Java/Apache/Jakarta/tomcat-5.0.7/conf/Catalina/localhost/Barracuda.xml 3192547 [http8080-Processor24] INFO org.apache.catalina.core.StandardHostDeployer - Installing web application from URL jar:file:/D:/Java/Apache/Jakarta/tomcat-5.0.7/webapps/Barracuda.war!/ Aug 15, 2003 8:33:25 PM org.apache.catalina.loader.WebappClassLoader findResourceInternal INFO: Lifecycle error : CL stopped java.lang.IncompatibleClassChangeError: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1251) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1211) at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:93) at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:174) at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:644) at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:616) at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:584) at org.apache.log4j.xml.XMLWatchdog.doOnChange(DOMConfigurator.java:815) at org.apache.log4j.helpers.FileWatchdog.checkAndConfigure(FileWatchdog.java:80) at org.apache.log4j.helpers.FileWatchdog.run(FileWatchdog.java:99) Aug 15, 2003 8:33:26 PM org.apache.catalina.loader.WebappClassLoader findResourceInternal INFO: Lifecycle error : CL stopped java.lang.IncompatibleClassChangeError: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1251) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1211) at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:93) at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:174) at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:644) at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:616) at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:584) at org.apache.log4j.xml.XMLWatchdog.doOnChange(DOMConfigurator.java:815) at org.apache.log4j.helpers.FileWatchdog.checkAndConfigure(FileWatchdog.java:80) at org.apache.log4j.helpers.FileWatchdog.run(FileWatchdog.java:99) [webapp specific initialization logging happens here.] 3216172 [ContainerBackgroundProcessor[StandardEngine[Catalina]]] INFO org.apache.catalina.startup.HostConfig - restartContext(/Barracuda) 3216672 [ContainerBackgroundProcessor[StandardEngine[Catalina]]] INFO org.apache.catalina.logger.LoggerBase - unregistering logger Catalina:type=Logger,path=/Barracuda,host=localhost [webapp specific initialization logging
DO NOT REPLY [Bug 22478] - Ant manager deploy causing webapp to initialize twice
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22478. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22478 Ant manager deploy causing webapp to initialize twice --- Additional Comments From [EMAIL PROTECTED] 2003-08-16 04:12 --- Created an attachment (id=7843) log of Digester exception upon first Ant manager deployment - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
