[GUMP@brutus]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project jakarta-tomcat-jk-native has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 46 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-tomcat-jk-native : Connectors to various web servers Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: make [Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native] - Making all in common make[1]: Entering directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common' /bin/sh /usr/local/gump/public/workspace/apache-httpd/dest-02032005/build/libtool --silent --mode=compile gcc -I/usr/local/gump/public/workspace/apache-httpd/dest-02032005/include -g -O2 -g -O2 -pthread -DHAVE_APR -I/usr/local/gump/public/workspace/apr/dest-02032005/include/apr-1 -g -O2 -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/gump/workspaces2/public/workspace/apache-httpd/srclib/pcre -I /opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c /usr/local/gump/public/workspace/apache-httpd/dest-02032005/build/libtool: /usr/local/gump/public/workspace/apache-httpd/dest-02032005/build/libtool: No such file or directory make[1]: *** [jk_ajp12_worker.lo] Error 127 make[1]: Leaving directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common' make: *** [all-recursive] Error 1 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2402032005, brutus:brutus-public:2402032005 Gump E-mail Identifier (unique within run) #12. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project jakarta-tomcat-5 (in module jakarta-tomcat-5) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project jakarta-tomcat-5 has an issue affecting its community integration. This issue affects 11 projects, and has been outstanding for 5 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - avalon-http-context : Avalon SVN - avalon-http-demo : Avalon SVN - avalon-http-examples : Avalon SVN - avalon-http-impl : Avalon SVN - avalon-http-server : Avalon SVN - avalon-http-servlet : Avalon SVN - avalon-http-static : Avalon SVN - avalon-http-test : Avalon SVN - avalon-planet-facilities : Avalon SVN - jakarta-tomcat-5 : Servlet 2.4 and JSP 2.0 Reference Implementation - metro-reflector-blocks-complete : Avalon SVN Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-5/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [servlets-default.jar] identifier set to output basename: [servlets-default] -DEBUG- Output [servlets-invoker.jar] identifier set to output basename: [servlets-invoker] -DEBUG- Output [catalina.jar] identifier set to output basename: [catalina] -DEBUG- Output [bootstrap.jar] identifier set to output basename: [bootstrap] -DEBUG- Dependency on javamail exists, no need to add for property mail.jar. -DEBUG- Dependency on jaf exists, no need to add for property activation.jar. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property servlet-api.jar. -DEBUG- Dependency on jakarta-servletapi-5-jsp exists, no need to add for property jsp-api.jar. -DEBUG- Dependency on xml-xerces exists, no need to add for property xercesImpl.jar. -DEBUG- Dependency on jakarta-tomcat-util exists, no need to add for property tomcat-util.jar. -DEBUG- Dependency on commons-el exists, no need to add for property commons-el.jar. -DEBUG- Dependency on commons-logging exists, no need to add for property commons-logging-api.jar. -DEBUG- Dependency on commons-modeler exists, no need to add for property commons-modeler.jar. -DEBUG- Dependency on ant exists, no need to add for property ant.home. -DEBUG- Dependency on jmx exists, no need to add for property jmx.home. -DEBUG- Dependency on jmx exists, no need to add for property jmx.jar. -DEBUG- Dependency on jmx exists, no need to add for property jmx-tools.jar. -DEBUG- Dependency on javamail exists, no need to add for property mail.home. -DEBUG- Dependency on jakarta-tomcat-coyote exists, no need to add for property tomcat-coyote.home. -DEBUG- Dependency on jakarta-tomcat-jasper_tc5 exists, no need to add for property jasper.home. -DEBUG- Dependency on jaf exists, no need to add for property activation.home. -DEBUG- Dependency on commons-modeler exists, no need to add for property commons-modeler.home. -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.jsvc.tar.gz. -DEBUG- Dependency on struts-core exists, no need to add for property struts.home. -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-5/gump_work/build_jakarta-tomcat-5_jakarta-tomcat-5.html Work Name: build_jakarta-tomcat-5_jakarta-tomcat-5 (Type: Build) Work ended in a state of : Failed Elapsed: 39 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dtomcat33.home=--UnSet-- -Dstruts-core.jar=/usr/local/gump/public/workspace/struts/core/dist/lib/struts.jar -Djsp-api.jar=/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar -Djmx.jar=/usr/local/gump/packages/jmx-1_2-ri/lib/jmxri.jar -Djasper-compiler-jdt.jar=/usr/local/gump/packages/eclipse-3.0.1/plugins/org.eclipse.jdt.core_3.0.1/jdtcore.jar -Djmx.home=/usr/local/gump/packages/jmx-1_2-ri -Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar -Dmail.home=/usr/local/gump/packages/javamail-1.3.2 -Dant.home=/usr/local/gump/public/workspace/ant/dist -Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02032005.jar
DO NOT REPLY [Bug 33753] - service-ref/ tag in web.xml is ignored. Servlet 2.4 spec.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33753. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33753 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-03-02 12:00 --- Please allow me to clarify with references to the Servlet 2.4 specification. Page 104. SRV.13.1.2: --- CUT HERE --- The following additional elements exist in the Web application deployment descriptor to meet the requirements of Web containers that are JSP pages enabled or part of a J2EE application server. They are not required to be supported by containers wishing to support only the servlet specification: jsp-config Syntax for looking up JNDI objects (env-entry, ejb-ref, ejb-local-ref, resource- ref, resource-env-ref) Syntax for specifying the message destination (message-destination, message- destination-ref) Reference to a Web service (service-ref) The syntax for these elements is now held in the JavaServer Pages specification version 2.0, and the J2EE specification version 1.4. ---CUT HERE--- The key phrase is JSP pages enabled or part of a J2EE application server. Tomcat does support JSPs. Tomcat 5.5 does claim to support JSP 2.0. Therefore, according to the spec it should support the service-ref/ tag. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33753] - service-ref/ tag in web.xml is ignored. Servlet 2.4 spec.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33753. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33753 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33753] - service-ref/ tag in web.xml is ignored. Servlet 2.4 spec.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33753. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33753 --- Additional Comments From [EMAIL PROTECTED] 2005-03-02 12:26 --- Correction, the reference is actually page 104. SRV.13.1 Deployment Descriptor Elements. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33753] - service-ref/ tag in web.xml is ignored. Servlet 2.4 spec.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33753. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33753 --- Additional Comments From [EMAIL PROTECTED] 2005-03-02 12:52 --- Hmmm... The information is not actually in the JSP 2.0 specification. I'm sending an email pointing out the potential problem to [EMAIL PROTECTED] I'll post here if anything interesting comes back. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33753] - service-ref/ tag in web.xml is ignored. Servlet 2.4 spec.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33753. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33753 --- Additional Comments From [EMAIL PROTECTED] 2005-03-02 13:11 --- If you want this functionality, get a full J2EE 1.4 application server. Please do not reopen this report. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33804] New: - Some log messages say 'JK2' when they mean 'JK'
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33804. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33804 Summary: Some log messages say 'JK2' when they mean 'JK' Product: Tomcat 5 Version: 5.5.7 Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P2 Component: Connector:AJP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] In the source distibution, we find log messages saying 'JK2' when they actually mean 'JK' (I guess...) A grep for JK2 on the source distro shows: jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/AprImpl.java: log.info(JK2: Initialized apr ); jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelJni.java: log.info(JK2: listening on channel.jni:jni ); jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java: log.info(JK2: ajp13 disabling channelSocket); jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java: log.info(JK2: ajp13 listening on + getAddress() + : + port ); Also, in jakarta-tomcat-5.5.7-src/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java the comment says Plugs Jk2 into Coyote. All around this JK/JK2 thing is confusing. I suppose code from one was borrowed for the other... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33806] New: - Session tracking using URL rewriting fails, if client URL-encodes reserved characters ; and =
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33806. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33806 Summary: Session tracking using URL rewriting fails, if client URL-encodes reserved characters ; and = Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Servlet JSP API AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] It seems that Tomcat 5.0.28 (at least) fails to track session using URL rewriting (whith no cookies), when the client converts the reserved characters ; and = in a rewritten URL, rendering what was supposed to be ;jsessionid= as %3Bjsessionid%D. I had a look at RFC 2396, but did not figure out, wether URL encoding in path part of URI is valid. Is it? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33807] New: - When thread pool fills tomcat stops processing requests.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33807. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33807 Summary: When thread pool fills tomcat stops processing requests. Product: Tomcat 5 Version: 5.5.4 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I'm running 5.5.4 with sun jdk 1.4 (but this problem exists probably with every jdk version and with many tomcat versions). I have a very loaded site. When I restart tomcat it gets immediately hit by hundreds of clients. The load goes up and processing requests starts taking a very long time. As a result all the worker threads become busy and I get the following message in the log: Mar 1, 2005 3:33:31 PM org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads (900) are currently busy, waiting. Increase maxThreads (900) or check the servlet status After this tomcat stops processing new requests. I believe that the correct behaviour would be to continue processing requests with the existing threads and processing new as the threads become free. But in this case, as I said tomcat simply stops accepting new connections and 'hangs' not doing anything. Increasing max threads seems to be a workaround but not a good one. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33807] - When thread pool fills tomcat stops processing requests.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33807. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33807 --- Additional Comments From [EMAIL PROTECTED] 2005-03-02 14:53 --- My guess is that you may be having deadlocks somewhere in your code. Your report is also very incomplete (no mention of configuration, platform, etc). I recommend posting to tomcat-user instead. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33809] New: - UTF-16 Encoding does not work for response
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33809. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33809 Summary: UTF-16 Encoding does not work for response Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows XP Status: NEW Severity: major Priority: P2 Component: Servlet JSP API AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Tomcat 4.0.4 does not work properly with UTF-16LE Encoding . My data is in UTF-16LE encoding and the byte are sent back using reqsponse.getWriter() stream. See the code below :- % response.setContentType(text/plain; charset=utf-16le); response.setHeader(Content-Disposition,attachment; filename=\test.csv\); java.io.PrintWriter out1 = response.getWriter(); //Add Multibyte data 82A7 String strData = test+\u82A7; strData = new String(strData.getBytes(UTF-16LE),UTF-16LE); //Write BOM and UTF-16 encoded String out1.write(\uFEFF+strData); out1.flush(); out1.close(); % This code does not work properly on tomcat4, The jsp does not show the pop up Open/Save Dialog as desired . If , response.setContentType(text/plain; charset=utf-16le); this is changed to response.setContentType(text/plain; charset=utf-8); the the Open/Save Dialog comes up. But it saves the File in UTF-8 encoding. This is Wrong , since File contains data in UTF-16LE ( required for CSVs that has Multibyte data and microsoft Supports UTF-16LE by default for Excel) If I run the above Code in Tomcat5, it works fine. The file test.csv is saved in Unicode Encoding and gets opened properly in MsExcel. Did i miss something for tomcat4 ? Is it a Bug with tomcat4 Thanks, Anuj -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33809] - UTF-16 Encoding does not work for response
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33809. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33809 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Summary|UTF-16 Encoding does not |UTF-16 Encoding does not |work for response |work for response --- Additional Comments From [EMAIL PROTECTED] 2005-03-02 15:17 --- 4.0.4 is an out of date code base not being updated. The tomcat-user list might be of help. [Bugzilla is not a help desk forum] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TCKs and vote for 5.5.8
Hi, Thanks for your prompt response. Yoav Shapira wrote: Hola, 5.0.30 will stay beta, there will be no vote on it, no matter what the TCKs say, because of other bugs. (I don't remember the specifics right now, they were discussed on this list at the time shortly after the release). Sorry, I joined after that. Should have checked the archives. When a good new 5.0.x release comes out (for which there's no ETA), we'll request the TCKs be run. OK, so there is a possibility that this still happens. Good to know. Thanks again for the clarifications. Regards, Fernando Yoav -Original Message- From: Fernando Nasser [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 4:10 PM To: Tomcat Developers List Subject: Re: TCKs and vote for 5.5.8 Any chance of doing the same for the last of the 5.0.x lineage, 5.0.30, which is still marked as Beta? I know that as part of an Application Server (running as the embedded Web Container) it does pass the TCK. Regards to all, Fernando Yoav Shapira wrote: Hola, Can someone please run the TCKs for 5.5.8 if you haven't already? I'd like to have the results before voting on release stability. Thanks, Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] / mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Fernando Nasser Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED] 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33810] New: - Stream closed errors from JSP tags under load
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33810. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33810 Summary: Stream closed errors from JSP tags under load Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] We have a Struts based application deployed on JBoss 3.2.6. In our production environment under load the servers throw Stream closed errors and after that the servers do not work and forced to restart. We have not seen this problem in test regions where the load is lower. We have tried disabling tag pooling in Tomcat, but that does not seem to help fix the problems. Does any one else have similar issues in production environment? The server encountered an internal error () that prevented it from fulfilling this request. exception java.io.IOException: Stream closed org.apache.jasper.runtime.BodyContentImpl.ensureOpen(BodyContentImpl.java:576) org.apache.jasper.runtime.BodyContentImpl.write(BodyContentImpl.java:140) org.apache.jasper.runtime.BodyContentImpl.write(BodyContentImpl.java:157) org.apache.jsp.protected_.security.AvailApplications_jsp._jspService(AvailApplications_jsp.java:210) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1069) org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:455) com.citistreet.id.i401k.struts.util.PwebRequestProcessor.processForwardConfig(PwebRequestProcessor.java:96) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) citistreet.id.struts.action.AbstractController.process(AbstractController.java:141) com.citistreet.id.i401k.struts.action.Controller.process(Controller.java:142) org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:507) javax.servlet.http.HttpServlet.service(HttpServlet.java:697) citistreet.id.struts.action.AbstractController.service(AbstractController.java:108) com.citistreet.id.i401k.struts.action.Controller.service(Controller.java:118) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) citistreet.id.servlet.filter.AbstractFilter.doFilter(AbstractFilter.java:79) citistreet.id.servlet.filter.AbstractFilter.doFilter(AbstractFilter.java:79) com.citistreet.id.i401k.servlet.filter.TimingFilter.doFilter(TimingFilter.java:54) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) Thanks Purush -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33810] - Stream closed errors from JSP tags under load
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33810. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33810 [EMAIL PROTECTED] changed: What|Removed |Added Priority|P2 |P1 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21220] - java.util.zip.ZipException on Tomcat boot is less than helpful
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=21220.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=21220
--- Additional Comments From [EMAIL PROTECTED] 2005-03-02 18:03 ---
Here we go again, this time in Tomcat 5.5.
Here is a little patch (diff --unified) for this badness:
---
./jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java.bak
2005-03-02 17:53:50.136472408 +0100
+++
./jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
2005-03-02 17:57:14.185452248 +0100
@@ -1540,7 +1540,7 @@
try {
jarFiles[i] = new JarFile(jarRealFiles[i]);
} catch (IOException e) {
- log.warn(Failed to open JAR, e);
+ log.warn(Failed to open JAR file ' +
jarRealFiles[i] + ', e);
}
}
}
@@ -2040,7 +2040,12 @@
if (triggers == null)
return (true);
-JarFile jarFile = new JarFile(jarfile);
+try {
+ JarFile jarFile = new JarFile(jarfile);
+} catch (IOException e) {
+ log.warn(Failed to open JAR file ' + jarfile + ', e);
+ throw e;
+}
for (int i = 0; i triggers.length; i++) {
Class clazz = null;
try {
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
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 StandardContext.java
remm2005/03/02 10:14:06
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
- Fix context classloader binding during loader initialization (it was set to
null before).
- The webapp loader should only be retrieved when the context classloader is
set to the webapp's classloader. The initialization of
StandardContainer violates this by having its basic valve instantiated,
which in turns gets the logger right away. This means it will use
whatever logging configuration is defined for the server classloader :(
Revision ChangesPath
1.166 +7 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.165
retrieving revision 1.166
diff -u -r1.165 -r1.166
--- StandardContext.java 24 Feb 2005 17:11:06 - 1.165
+++ StandardContext.java 2 Mar 2005 18:14:06 - 1.166
@@ -4007,8 +4007,6 @@
// Start our subordinate components, if any
if ((loader != null) (loader instanceof Lifecycle))
((Lifecycle) loader).start();
-if ((logger != null) (logger instanceof Lifecycle))
-((Lifecycle) logger).start();
// Unbinding thread
unbindThread(oldCCL);
@@ -4016,6 +4014,8 @@
// Binding thread
oldCCL = bindThread();
+if ((logger != null) (logger instanceof Lifecycle))
+((Lifecycle) logger).start();
if ((cluster != null) (cluster instanceof Lifecycle))
((Lifecycle) cluster).start();
if ((realm != null) (realm instanceof Lifecycle))
@@ -4483,8 +4483,10 @@
if (getResources() == null)
return oldContextClassLoader;
-Thread.currentThread().setContextClassLoader
-(getLoader().getClassLoader());
+if (getLoader().getClassLoader() != null) {
+Thread.currentThread().setContextClassLoader
+(getLoader().getClassLoader());
+}
DirContextURLStreamHandler.bind(getResources());
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32696] - WEB-INF protection stops IIS
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32696. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32696 [EMAIL PROTECTED] changed: What|Removed |Added Status|CLOSED |REOPENED Component|Unknown |Connector:JK/AJP Keywords||ErrorMessage, ||NeedsReleaseNote Resolution|FIXED | Version|4.1.30 |4.1.31 --- Additional Comments From [EMAIL PROTECTED] 2005-03-02 19:22 --- Finding: When the scanning tools guessed WEB-INF directory, the error message indicated that access to the directory was denied. As a result, the error message confirmed the existence of this directory. Tomcat response HTTP Status 404, while isapi_redirect.dll redirector responses Access forbidden!, which is HTTP Status 403. Example: http://localhost:8080/WEB-INF/ Return: HTTP Status 404 - /WEB-INF/ This is correct. http://localhost:80/WEB-INF/ Return: Access forbidden! You don't have permission to access the requested object. It is either read- protected or not readable by the server. This should be 404, not 403. I have checked the code, jakarta-tomcat-connectors-1.2.8- src\jk\native\isapi\jk_isapi_plugin.c, at line 713, and it does response 403 HTTP Status. I cannot find the place to change it from configuration file except re-compile this redirector. While directory listing is not strictly considered vulnerability, I suggest to response 404 HTTP Status to hide the directory, like Tomcat does now. I found a link http://jakarta.apache.org/tomcat/connectors-doc/howto/iis.html mentions something like this: Protecting the WEB-INF Directory , this directory contains sensitive configurations data and Java classes and must be kept hidden from web users. Using the IIS management console it is possible to protect the WEB-INF directory from user access,. To avoid this need the redirector plugin automatically protects your WEB-INF directories by rejecting any request that contains WEB-INF in its URL-Path. I tried to configure IIS, but it looks like jk_isapi gets higher priority to handle the request and always returns 403 status. Without re-compile the program, how can I make IIS return 404 status? Or maybe next release will do? Recommendation from Cert: When an unauthorized user attempts to access a directory, they should receive an error message that doesn't confirm the existence of the directory. Whether a user is trying to access a valid or invalid directory, they should receive the same error message. My system environment: Win 2K Tomcat 4.1.31 IIS 5 JK-1.2.8 - isapi_redirect-1.2.8.dll binary version - 17 December -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/juli - New directory
remm2005/03/02 10:30:40 jakarta-tomcat-connectors/juli - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/juli/src - New directory
remm2005/03/02 10:30:40 jakarta-tomcat-connectors/juli/src - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/juli/src/conf - New directory
remm2005/03/02 10:30:40 jakarta-tomcat-connectors/juli/src/conf - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/juli/src/java - New directory
remm2005/03/02 10:30:40 jakarta-tomcat-connectors/juli/src/java - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/juli build.xml
remm2005/03/02 10:30:45
Modified:.build.xml
catalina/etc bootstrap.MF
Added: juli/src/conf logging.properties
juli/src/java/org/apache/juli ClassLoaderLogManager.java
FileHandler.java
juli build.xml
Log:
- Add JULI, a Java Util Logging Implementation.
- It supports per classloader configuration, using standard JDK properties
files, with optional extensions to be able to flexibly assign handlers to
loggers.
- The package includes a rotating handler, since zillions of people have
lamented its departure in 5.5.x (even if it didn't contain anything useful
anymore).
- This builds a small JAR, which is then added to the classpath by
bootstrap.jar.
- I may need to fix packaging a little after that change; sorry for the
trouble.
- I'll add comments and docs soon.
- This is based on code subimmted by Lachlan O'Dea in bug 33143, and is
likely to move to commons (once I get comfortable enough with svn).
Revision ChangesPath
1.1
jakarta-tomcat-connectors/juli/src/conf/logging.properties
Index: logging.properties
===
handlers = org.apache.juli.FileHandler java.util.logging.ConsoleHandler
# Handler specific properties.
# Describes specific configuration info for Handlers.
org.apache.juli.FileHandler.level = FINE
org.apache.juli.FileHandler.directory = ${catalina.base}/logs
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
# Facility specific properties.
# Provides extra control for each logger.
# For example, set the com.xyz.foo logger to only log SEVERE
# messages:
#org.apache.catalina.startup.ContextConfig.level = FINE
#org.apache.catalina.startup.HostConfig.level = FINE
#org.apache.catalina.session.ManagerBase.level = FINE
1.223 +23 -0 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.222
retrieving revision 1.223
diff -u -r1.222 -r1.223
--- build.xml 20 Jan 2005 12:00:20 - 1.222
+++ build.xml 2 Mar 2005 18:30:45 - 1.223
@@ -288,6 +288,27 @@
/target
+ target name=build-juli
+ unless=tomcatjuli.build.notrequired
+ depends=init description=builds j-t-c/juli
+ echo== Building: tomcat-juli /echo
+
+ ant dir=${jtc.home}/juli target=compile-only
+ property name=build.home value=${tomcat.build}/
+ /ant
+
+ !-- Java.util.logging Implementation --
+ jar jarfile=${tomcat.build}/bin/tomcat-juli.jar index=true
+ fileset dir=${tomcat.build}/classes
+ include name=org/apache/juli/** /
+ !-- Javadoc and i18n exclusions --
+ exclude name=**/package.html /
+ exclude name=**/LocalStrings_* /
+ /fileset
+ /jar
+
+ /target
+
target name=build-jasper
unless=jasper.build.notrequired
depends=init description=build jasper
@@ -513,6 +534,8 @@
antcall target=build-tomcathttp11/
+antcall target=build-juli/
+
antcall target=build-jasper/
antcall target=build-i18n/
1.6 +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.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- bootstrap.MF 2 Mar 2004 12:32:19 - 1.5
+++ bootstrap.MF 2 Mar 2005 18:30:45 - 1.6
@@ -1,5 +1,5 @@
Manifest-Version: 1.0
Main-Class: org.apache.catalina.startup.Bootstrap
-Class-Path: jmx.jar commons-daemon.jar commons-logging-api.jar
+Class-Path: jmx.jar commons-daemon.jar commons-logging-api.jar
tomcat-juli.jar
Specification-Title: Catalina
Specification-Version: 1.0
\ No newline at end of file
1.1
jakarta-tomcat-connectors/juli/src/java/org/apache/juli/ClassLoaderLogManager.java
Index: ClassLoaderLogManager.java
===
/*
* Copyright 1999,2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in
DO NOT REPLY [Bug 33143] - [PATCH] Java 1.4 loggers per context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33143. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33143 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-03-02 19:34 --- I have expanded the code provided to provide configurability using properties file (like java.util.logging has), and the code is now (likely temporarily) located in j-t-c/juli. Thanks. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml
remm2005/03/02 10:36:29
Modified:.build.xml
Log:
- Don't include juli in dist.
Revision ChangesPath
1.224 +1 -0 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.223
retrieving revision 1.224
diff -u -r1.223 -r1.224
--- build.xml 2 Mar 2005 18:30:45 - 1.223
+++ build.xml 2 Mar 2005 18:36:29 - 1.224
@@ -1226,6 +1226,7 @@
exclude name=*-using-launcher.*/
exclude name=LauncherBootstrap.class/
exclude name=launcher.properties/
+ exclude name=tomcat-juli.jar/
/fileset
/copy
copy todir=${tomcat.dist}/common/classes
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/juli/src/java/org/apache/juli - New directory
remm2005/03/02 10:30:40 jakarta-tomcat-connectors/juli/src/java/org/apache/juli - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/juli/src/java/org - New directory
remm2005/03/02 10:30:40 jakarta-tomcat-connectors/juli/src/java/org - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/juli/src/java/org/apache - New directory
remm2005/03/02 10:30:40 jakarta-tomcat-connectors/juli/src/java/org/apache - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
luehe 2005/03/02 11:27:11
Modified:catalina/src/share/org/apache/catalina/realm RealmBase.java
Log:
Consider the case where original request was mapped to welcome page.
In this case, the mapped welcome page (and not the original request
URI!) needs to be the target of hasResourcePermission().
This is consistent with the change that had been made in
findSecurityConstraints().
BTW, shouldn't request.getDecodedRequestURI() return the mapped
welcome page (instead of the original URI) in this case?
In other words, shouldn't the path passed to
mappingData.requestPath.setString(pathStr)
in Mapper.java be propagated to the request object associatd with the
mappingData?
Revision ChangesPath
1.49 +2 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java
Index: RealmBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- RealmBase.java23 Feb 2005 19:27:56 - 1.48
+++ RealmBase.java2 Mar 2005 19:27:11 - 1.49
@@ -702,7 +702,7 @@
LoginConfig config = context.getLoginConfig();
if ((config != null)
(Constants.FORM_METHOD.equals(config.getAuthMethod( {
-String requestURI = request.getDecodedRequestURI();
+String requestURI = request.getRequestPathMB().toString();
String loginPage = context.getPath() + config.getLoginPage();
if (loginPage.equals(requestURI)) {
if (log.isDebugEnabled())
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33816] New: - Unkosher lines in build.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33816.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33816
Summary: Unkosher lines in build.xml
Product: Tomcat 5
Version: 5.5.7
Platform: PC
OS/Version: Linux
Status: NEW
Severity: trivial
Priority: P2
Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
Looks like jakarta-tomcat-5.5.7-src/jakarta-tomcat-5/build.xml
specifies a parameter called 'destfile' for target 'downloadgz'.
However, the definition of 'downloadgz' is such that said parameter is never
used:
target name=downloadgz unless=exist depends=setproxy,testexist
!-- Download and extract the package --
get src=${sourcefile} dest=${base.path}/file.tar.gz /
gunzip src=${base.path}/file.tar.gz dest=${base.path}/file.tar/
untar src=${base.path}/file.tar dest=${base.path}/
delete file=${base.path}/file.tar/
delete file=${base.path}/file.tar.gz/
/target
So we can rip out the 'destfiles':
--- /usr/local/tarballs/jakarta-tomcat-5.5.7-src/jakarta-tomcat-5/build.xml.bak
2005-03-02 20:42:30.009017936 +0100
+++ /usr/local/tarballs/jakarta-tomcat-5.5.7-src/jakarta-tomcat-5/build.xml
2005-03-02 20:47:08.198726672 +0100
@@ -601,17 +601,14 @@
!-- antcall target=build-commons-modeler / --
!-- antcall target=build-commons-daemon / --
- antcall target=downloadgz
+antcall target=downloadgz
param name=sourcefile value=${commons-collections-src.loc}/
- param name=destfile value=${tomcat-dbcp.jar} /
/antcall
- antcall target=downloadgz
+antcall target=downloadgz
param name=sourcefile value=${commons-pool-src.loc}/
- param name=destfile value=${tomcat-dbcp.jar} /
/antcall
antcall target=downloadgz
param name=sourcefile value=${commons-dbcp-src.loc}/
- param name=destfile value=${tomcat-dbcp.jar} /
/antcall
antcall target=build-tomcat-dbcp /
@@ -1714,48 +1711,39 @@
!-- Downdown any sub package or tools needed. --
antcall target=downloadgz
param name=sourcefile value=${commons-beanutils.loc}/
- param name=destfile value=${commons-beanutils.jar}/
/antcall
antcall target=downloadgz
param name=sourcefile value=${commons-collections.loc}/
- param name=destfile value=${commons-collections.jar}/
/antcall
antcall target=downloadgz
param name=sourcefile value=${commons-el.loc}/
- param name=destfile value=${commons-el.jar}/
/antcall
antcall target=downloadgz
param name=sourcefile value=${commons-logging.loc}/
- param name=destfile value=${commons-logging.jar}/
/antcall
antcall target=downloadgz
param name=sourcefile value=${commons-modeler.loc}/
- param name=destfile value=${commons-modeler.jar}/
/antcall
antcall target=downloadgz
param name=sourcefile value=${log4j.loc}/
- param name=destfile value=${log4j.jar}/
/antcall
antcall target=downloadgz
param name=sourcefile value=${commons-digester.loc}/
- param name=destfile value=${commons-digester.jar}/
/antcall
antcall target=downloadgz
param name=sourcefile value=${commons-fileupload.loc}/
- param name=destfile value=${commons-fileupload.jar}/
/antcall
antcall target=downloadgz
!-- xerces2 brings 2 files, test for one of them --
param name=sourcefile value=${xerces.loc}/
- param name=destfile value=${xml-apis.jar}/
/antcall
antcall target=downloadzip
@@ -1772,25 +1760,20 @@
antcall target=downloadgz
param name=sourcefile value=${commons-launcher.loc}/
- param name=destfile value=${commons-launcher.jar}/
/antcall
!--
antcall target=downloadgz
param name=sourcefile value=${commons-pool.loc}/
- param name=destfile value=${commons-pool.jar}/
/antcall
antcall target=downloadgz
param name=sourcefile value=${commons-dbcp.loc}/
- param name=destfile value=${commons-dbcp.jar}/
- param name=destdir value=${base.path}/
/antcall
--
antcall target=downloadgz
param name=sourcefile value=${commons-httpclient.loc}/
- param name=destfile value=${commons-httpclient.jar}/
/antcall
antcall target=downloadfile
@@ -1801,22 +1784,18 @@
antcall target=downloadgz
param name=sourcefile value=${struts.loc}/
- param name=destfile value=${struts.jar}/
/antcall
antcall target=downloadgz
param name=sourcefile value=${commons-daemon.loc}/
- param name=destfile value=${commons-daemon.jar}/
/antcall
antcall target=downloadgz
param name=sourcefile
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
[EMAIL PROTECTED] wrote: luehe 2005/03/02 11:27:11 Modified:catalina/src/share/org/apache/catalina/realm RealmBase.java Log: Consider the case where original request was mapped to welcome page. In this case, the mapped welcome page (and not the original request URI!) needs to be the target of hasResourcePermission(). This is consistent with the change that had been made in findSecurityConstraints(). BTW, shouldn't request.getDecodedRequestURI() return the mapped welcome page (instead of the original URI) in this case? In other words, shouldn't the path passed to mappingData.requestPath.setString(pathStr) in Mapper.java be propagated to the request object associatd with the mappingData? I consider welcome files to be internal forwards (since it is allowed to handle them this way). As a result, they shouldn't be matched by secrurity constraints. Only the original request path should be the used (so here it's getDecodedRequestURI - as sent by the client). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33816] - Unkosher lines in build.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33816. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33816 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-03-02 21:01 --- The destfile is used by the testexist target -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Wednesday, March 02, 2005 11:56 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java [EMAIL PROTECTED] wrote: luehe 2005/03/02 11:27:11 Modified:catalina/src/share/org/apache/catalina/realm RealmBase.java Log: Consider the case where original request was mapped to welcome page. In this case, the mapped welcome page (and not the original request URI!) needs to be the target of hasResourcePermission(). This is consistent with the change that had been made in findSecurityConstraints(). BTW, shouldn't request.getDecodedRequestURI() return the mapped welcome page (instead of the original URI) in this case? In other words, shouldn't the path passed to mappingData.requestPath.setString(pathStr) in Mapper.java be propagated to the request object associatd with the mappingData? I consider welcome files to be internal forwards (since it is allowed to handle them this way). As a result, they shouldn't be matched by secrurity constraints. Only the original request path should be the used (so here it's getDecodedRequestURI - as sent by the client). I agree with Remy. It's an internal Tomcat implementation detail that welcome-files aren't handled via DefaultServlet doing: RequestDispatcher rd = request.getRequestDispatcher(welcome[i]); rd.forward(request, response); Since this is explicitly allowed by the spec, nobody can expect that a security-constraint mapped only to the welcome-file will be applied. However, this is probably another thing that should be better specified in the 2.5 spec. Rémy - 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]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ValveBase.java
remm2005/03/02 12:19:58
Modified:catalina/src/share/org/apache/catalina/valves ValveBase.java
Log:
- Move the creation of the logger to a little bit later (not late enough
probably, but for Tomcat standalone it works).
Revision ChangesPath
1.18 +3 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ValveBase.java
Index: ValveBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ValveBase.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- ValveBase.java23 Feb 2005 19:27:56 - 1.17
+++ ValveBase.java2 Mar 2005 20:19:58 - 1.18
@@ -114,7 +114,7 @@
public void setContainer(Container container) {
this.container = container;
-this.containerLog = container.getLogger();
+
}
@@ -239,6 +239,7 @@
Container container=this.getContainer();
if( container == null || ! (container instanceof ContainerBase) )
return null;
+this.containerLog = container.getLogger();
ContainerBase containerBase=(ContainerBase)container;
Pipeline pipe=containerBase.getPipeline();
Valve valves[]=pipe.getValves();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
Bill/Remy, Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Wednesday, March 02, 2005 11:56 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java [EMAIL PROTECTED] wrote: luehe 2005/03/02 11:27:11 Modified:catalina/src/share/org/apache/catalina/realm RealmBase.java Log: Consider the case where original request was mapped to welcome page. In this case, the mapped welcome page (and not the original request URI!) needs to be the target of hasResourcePermission(). This is consistent with the change that had been made in findSecurityConstraints(). BTW, shouldn't request.getDecodedRequestURI() return the mapped welcome page (instead of the original URI) in this case? In other words, shouldn't the path passed to mappingData.requestPath.setString(pathStr) in Mapper.java be propagated to the request object associatd with the mappingData? I consider welcome files to be internal forwards (since it is allowed to handle them this way). As a result, they shouldn't be matched by secrurity constraints. Only the original request path should be the used (so here it's getDecodedRequestURI - as sent by the client). I agree with Remy. It's an internal Tomcat implementation detail that welcome-files aren't handled via DefaultServlet doing: RequestDispatcher rd = request.getRequestDispatcher(welcome[i]); rd.forward(request, response); Since this is explicitly allowed by the spec, nobody can expect that a security-constraint mapped only to the welcome-file will be applied. However, this is probably another thing that should be better specified in the 2.5 spec. But SRV.9.10 (Welcome Files) already has this: The container may send the request to the welcome resource with a forward, a redirect, or a container specific mechanism **that is indistinguishable from a direct request**. The latter to me implies that any sec constraints must be applied to the mapped welcome page (if any). Also, see the attached diffs, in particular: -String uri = request.getDecodedRequestURI(); -String contextPath = hreq.getContextPath(); -if (contextPath.length() 0) -uri = uri.substring(contextPath.length()); +String uri = request.getRequestPathMB().toString(); in findSecurityConstraints(). When accessing host:port:/somecontext/, which has welcome page /somecontext/index.jsp, request.getDecodedRequestURI() returns /somecontext/, whereas request.getRequestPathMB().toString() returns /index.jsp (as set by the mapper), so there already is a precedent in findSecurityConstraints() to match sec constraints against welcome page, which I think makes sense. Otherwise, the following sec constraint: security-constraint web-resource-collection web-resource-nameProtected Area/web-resource-name url-pattern*.jsp/url-pattern http-methodPUT/http-method http-methodDELETE/http-method http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-nametomcat/role-name /auth-constraint /security-constraint which is supposed to protect all JSP pages, would be bypassed if a request was mapped to index.jsp welcome page. Jan Rémy - 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] Index: RealmBase.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- RealmBase.java 26 Dec 2003 17:33:44 - 1.23 +++ RealmBase.java 10 Jan 2004 17:23:39 - 1.24 @@ -1,7 +1,7 @@
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java JspUtil.java
markt 2005/03/02 12:56:03
Modified:jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch Generator.java JspUtil.java
Log:
Port fix for 22867 tag handlers can't be inner/nested classes from TC5
- TC4 port provided by Steven Parkes in bug 24586
Revision ChangesPath
No revision
No revision
1.35.2.28 +14 -10
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.35.2.27
retrieving revision 1.35.2.28
diff -u -r1.35.2.27 -r1.35.2.28
--- Generator.java22 Feb 2005 22:00:54 - 1.35.2.27
+++ Generator.java2 Mar 2005 20:56:02 - 1.35.2.28
@@ -648,7 +648,7 @@
if (beanInfo.checkVariable(name)) {
// Bean is defined using useBean, introspect at compile time
Class bean = beanInfo.getBeanType(name);
-String beanName = bean.getName();
+String beanName = JspUtil.getCanonicalName(bean);
java.lang.reflect.Method meth =
JspRuntimeLibrary.getReadMethod(bean, property);
String methodName = meth.getName();
@@ -1293,21 +1293,23 @@
declareScriptingVars(n, VariableInfo.AT_BEGIN);
saveScriptingVars(n, VariableInfo.AT_BEGIN);
-out.printin(tagHandlerClass.getName());
+String tagHandlerClassName =
+JspUtil.getCanonicalName(tagHandlerClass);
+out.printin(tagHandlerClassName);
out.print( );
out.print(tagHandlerVar);
out.print( = );
if (ctxt.getOptions().isPoolingEnabled()) {
out.print(();
-out.print(tagHandlerClass.getName());
+out.print(tagHandlerClassName);
out.print() );
out.print(n.getTagHandlerPoolName());
out.print(.get();
-out.print(tagHandlerClass.getName());
+out.print(tagHandlerClassName);
out.println(.class););
} else {
out.print(new );
-out.print(tagHandlerClass.getName());
+out.print(tagHandlerClassName);
out.println((););
}
@@ -1750,11 +1752,12 @@
throws JasperException {
if (propEditorClass != null) {
-return ( + c.getName()
+String className = JspUtil.getCanonicalName(c);
+return ( + className
+
)JspRuntimeLibrary.getValueFromBeanInfoPropertyEditor(
-+ c.getName() + .class, \ + attrName + \,
++ className + .class, \ + attrName + \,
+ quote(s) + ,
-+ propEditorClass.getName() + .class);
++ JspUtil.getCanonicalName(propEditorClass) + .class);
} else if (c == String.class) {
return quote(s);
} else if (c == boolean.class) {
@@ -1808,9 +1811,10 @@
} else if (c == Object.class) {
return new String( + quote(s) + );
} else {
-return ( + c.getName()
+String className = JspUtil.getCanonicalName(c);
+return ( + className
+ )JspRuntimeLibrary.getValueFromPropertyEditorManager(
-+ c.getName() + .class, \ + attrName + \,
++ className + .class, \ + attrName + \,
+ quote(s) + );
}
}
1.4.2.4 +29 -0
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspUtil.java
Index: JspUtil.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspUtil.java,v
retrieving revision 1.4.2.3
retrieving revision 1.4.2.4
diff -u -r1.4.2.3 -r1.4.2.4
--- JspUtil.java 25 Aug 2004 20:53:31 - 1.4.2.3
+++ JspUtil.java 2 Mar 2005 20:56:03 - 1.4.2.4
@@ -423,6 +423,35 @@
}
return b;
}
+
+// javac -classpath
~mint/tomcat/common/lib/ant.jar:~mint/tomcat/common/endorsed/xml-apis.jar:~mint/tomcat/common/lib/servlet.jar
`find . -name \*.java `
+
+
+/**
+ * Compute the canonical name from a Class instance. Note that a
+ * simple replacment of '$' with '.' of a binary name would not work,
+ * as '$' is a legal Java Identifier character.
+
DO NOT REPLY [Bug 24586] - Compilation error when exposing an Inner class
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=24586. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=24586 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-03-02 22:00 --- I have applied the port - thanks for the patch - but it doesn't fix the test case originally described here. The test case needs to be modified to return the canonical rather than binary name of the inner class. type.getName() is not sufficient. See the getCanonicalName() function in the attached patch for how this might be performed. With this modification (I just replaced type.getName() with a hard coded test.FooTag.InnerBean) the test case works as expected. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid url-pattern in servlet mapping
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=13014. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=13014 --- Additional Comments From [EMAIL PROTECTED] 2005-03-02 22:31 --- This is quite an old bug. Having reviewed this bug I would make the following observations: 1. Users of OS/390 should have migrated to z/OS but as far as I can tell this issue also applies to z/OS. 2. Binary fixes cannot be applied to CVS. I know in theory they could be reverse engineered but I am not going own that road. 3. The getReporter() issue is in the deprecated HTTP connector. 4. A better fix may be to add a configuration option to o.a.c.util.RequestUtil I will leave this bug open for now but since AFAIAA none of the Tomcat developers have access to a machine running z/OS this will be resolved as WONTFIX at some point in the future unless appropriate source code patches are provided for review. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
Jan Luehe wrote: Bill/Remy, But SRV.9.10 (Welcome Files) already has this: The container may send the request to the welcome resource with a forward, a redirect, or a container specific mechanism **that is indistinguishable from a direct request**. The latter to me implies that any sec constraints must be applied to the mapped welcome page (if any). The plot thickens. Also, see the attached diffs, in particular: -String uri = request.getDecodedRequestURI(); -String contextPath = hreq.getContextPath(); -if (contextPath.length() 0) -uri = uri.substring(contextPath.length()); +String uri = request.getRequestPathMB().toString(); in findSecurityConstraints(). When accessing host:port:/somecontext/, which has welcome page /somecontext/index.jsp, request.getDecodedRequestURI() returns /somecontext/, whereas request.getRequestPathMB().toString() returns /index.jsp (as set by the mapper), so there already is a precedent in findSecurityConstraints() to match sec constraints against welcome page, which I think makes sense. Right. However, when I made that commit, the current mapper behavior may not have been in place already, or maybe it's simply that I thought the two would be equivalent (I was busy optimizing at the time). I don't quite remember ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/juli/src/java/org/apache/juli ClassLoaderLogManager.java FileHandler.java
remm2005/03/02 13:40:00
Modified:juli/src/java/org/apache/juli ClassLoaderLogManager.java
FileHandler.java
Log:
- The java.util.logging javadocs imply that the configuration of the handler
(filter, formatter, etc) should be done by the handler itself.
Revision ChangesPath
1.2 +30 -3
jakarta-tomcat-connectors/juli/src/java/org/apache/juli/ClassLoaderLogManager.java
Index: ClassLoaderLogManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/juli/src/java/org/apache/juli/ClassLoaderLogManager.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ClassLoaderLogManager.java2 Mar 2005 18:30:45 - 1.1
+++ ClassLoaderLogManager.java2 Mar 2005 21:40:00 - 1.2
@@ -16,13 +16,23 @@
package org.apache.juli;
-import java.util.logging.*;
-import java.util.*;
import java.io.IOException;
import java.io.InputStream;
import java.net.URLClassLoader;
import java.security.AccessController;
import java.security.PrivilegedAction;
+import java.util.Collections;
+import java.util.Enumeration;
+import java.util.HashMap;
+import java.util.Iterator;
+import java.util.Map;
+import java.util.Properties;
+import java.util.StringTokenizer;
+import java.util.WeakHashMap;
+import java.util.logging.Handler;
+import java.util.logging.Level;
+import java.util.logging.LogManager;
+import java.util.logging.Logger;
/**
@@ -294,12 +304,29 @@
this.prefix.set(prefix);
Handler handler =
(Handler)
classLoader.loadClass(handlerClassName).newInstance();
-this.prefix.set(null);
+// FIXME: The specification strongly implies
this should be done in the
+// handler configuration
+/*
+// Initialize handler's level
String handlerLevel =
info.props.getProperty(handlerName +
.level);
if (handlerLevel != null) {
handler.setLevel(Level.parse(handlerLevel.trim()));
}
+// Initialize filter
+String filterName =
+info.props.getProperty(handlerName +
.filter);
+if (filterName != null) {
+try {
+handler.setFilter
+((Filter)
classLoader.loadClass(filterName).newInstance());
+} catch (Exception e) {
+// FIXME: Report this using the main
logger ?
+// Ignore
+}
+}
+*/
+this.prefix.set(null);
info.handlers.put(handlerName, handler);
if (rootHandlers == null) {
localRootLogger.addHandler(handler);
1.2 +37 -8
jakarta-tomcat-connectors/juli/src/java/org/apache/juli/FileHandler.java
Index: FileHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/juli/src/java/org/apache/juli/FileHandler.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- FileHandler.java 2 Mar 2005 18:30:45 - 1.1
+++ FileHandler.java 2 Mar 2005 21:40:00 - 1.2
@@ -23,7 +23,10 @@
import java.io.UnsupportedEncodingException;
import java.sql.Timestamp;
import java.util.logging.ErrorManager;
+import java.util.logging.Filter;
+import java.util.logging.Formatter;
import java.util.logging.Handler;
+import java.util.logging.Level;
import java.util.logging.LogManager;
import java.util.logging.LogRecord;
import java.util.logging.SimpleFormatter;
@@ -238,27 +241,53 @@
LogManager manager = LogManager.getLogManager();
String className = FileHandler.class.getName();
+ClassLoader cl = Thread.currentThread().getContextClassLoader();
+
// Retrieve configuration of logging file name
directory = getProperty(className + .directory, logs);
prefix = getProperty(className + .prefix, juli.);
suffix = getProperty(className + .suffix, .log);
-// FIXME: Add filter configuration in LogManager ?
-//setFilter(manager.getFilterProperty(className + .filter, null));
-//
DO NOT REPLY [Bug 33819] New: - 5.5.7 startup script does not work on Linux, JDK 1.5.0
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33819. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33819 Summary: 5.5.7 startup script does not work on Linux, JDK 1.5.0 Product: Tomcat 5 Version: 5.5.7 Platform: PC OS/Version: Linux Status: NEW Severity: blocker Priority: P1 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The startup 5.5.7 startup script does not work on Linux. Please note that this is NOT the JRE problem - I have JDK 1.5.0 (or 5.0 under the new numbering system) installed, and have JAVA_HOME set to it. Note also that this is specific to 5.5; after I was unable to get 5.5.7 to work, I downloaded 5.0.28, which works per the installation instructions with no changes to my system. After running the 5.5.7 startup.sh, catalina.log contains: Error: could not find libjava.so Error: could not find Java 2 Runtime Environment. Looks like a path problem, but $JAVA_HOME is correct and $LD_LIBRARY_PATH is unset. Regards B. Wagman -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
- Original Message - From: Jan Luehe [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Wednesday, March 02, 2005 12:51 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java Bill/Remy, Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Wednesday, March 02, 2005 11:56 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java [EMAIL PROTECTED] wrote: luehe 2005/03/02 11:27:11 Modified:catalina/src/share/org/apache/catalina/realm RealmBase.java Log: Consider the case where original request was mapped to welcome page. In this case, the mapped welcome page (and not the original request URI!) needs to be the target of hasResourcePermission(). This is consistent with the change that had been made in findSecurityConstraints(). BTW, shouldn't request.getDecodedRequestURI() return the mapped welcome page (instead of the original URI) in this case? In other words, shouldn't the path passed to mappingData.requestPath.setString(pathStr) in Mapper.java be propagated to the request object associatd with the mappingData? I consider welcome files to be internal forwards (since it is allowed to handle them this way). As a result, they shouldn't be matched by secrurity constraints. Only the original request path should be the used (so here it's getDecodedRequestURI - as sent by the client). I agree with Remy. It's an internal Tomcat implementation detail that welcome-files aren't handled via DefaultServlet doing: RequestDispatcher rd = request.getRequestDispatcher(welcome[i]); rd.forward(request, response); Since this is explicitly allowed by the spec, nobody can expect that a security-constraint mapped only to the welcome-file will be applied. However, this is probably another thing that should be better specified in the 2.5 spec. But SRV.9.10 (Welcome Files) already has this: The container may send the request to the welcome resource with a forward, a redirect, or a container specific mechanism **that is indistinguishable from a direct request**. I read the emphasised text as referring to 'container specific mechanism'. Yes, I agree that the last-minute changes that were made to 9.10 made it a total mess, but it still explicitly allows DefaultServlet to do a rd.forward. The latter to me implies that any sec constraints must be applied to the mapped welcome page (if any). Also, see the attached diffs, in particular: Firstly, I'm strongly -1 on the patch, since removing the 'if(found)return' statements causes Tomcat to no longer be spec-complient. Just because the spec is silly doesn't mean that we don't have to implement it. -String uri = request.getDecodedRequestURI(); -String contextPath = hreq.getContextPath(); -if (contextPath.length() 0) -uri = uri.substring(contextPath.length()); +String uri = request.getRequestPathMB().toString(); in findSecurityConstraints(). When accessing host:port:/somecontext/, which has welcome page /somecontext/index.jsp, request.getDecodedRequestURI() returns /somecontext/, whereas request.getRequestPathMB().toString() returns /index.jsp (as set by the mapper), so there already is a precedent in findSecurityConstraints() to match sec constraints against welcome page, which I think makes sense. Servlet 12.8.3 says to use the decoded requestURI, which is defined as contextPath+servletPath+pathInfo. Since servletPath is set to /index.jsp in Tomcat, I guess that requestPathMB is the correct one to use. Otherwise, the following sec constraint: security-constraint web-resource-collection web-resource-nameProtected Area/web-resource-name url-pattern*.jsp/url-pattern http-methodPUT/http-method http-methodDELETE/http-method http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-nametomcat/role-name /auth-constraint /security-constraint which is supposed to protect all JSP pages, would be bypassed if a request was mapped to index.jsp welcome page. Jan Rémy - 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
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
Remy, Remy Maucherat wrote: Jan Luehe wrote: Bill/Remy, But SRV.9.10 (Welcome Files) already has this: The container may send the request to the welcome resource with a forward, a redirect, or a container specific mechanism **that is indistinguishable from a direct request**. The latter to me implies that any sec constraints must be applied to the mapped welcome page (if any). The plot thickens. What do you mean by that? ;-) Do you agree the spec is pretty clear about the fact that any sec constraints must be applied to welcome page? Also, see the attached diffs, in particular: -String uri = request.getDecodedRequestURI(); -String contextPath = hreq.getContextPath(); -if (contextPath.length() 0) -uri = uri.substring(contextPath.length()); +String uri = request.getRequestPathMB().toString(); in findSecurityConstraints(). When accessing host:port:/somecontext/, which has welcome page /somecontext/index.jsp, request.getDecodedRequestURI() returns /somecontext/, whereas request.getRequestPathMB().toString() returns /index.jsp (as set by the mapper), so there already is a precedent in findSecurityConstraints() to match sec constraints against welcome page, which I think makes sense. Right. However, when I made that commit, the current mapper behavior may not have been in place already, or maybe it's simply that I thought the two would be equivalent (I was busy optimizing at the time). I don't quite remember ;) I think you did the right thing without realizing it. :) The change I committed earlier today is just consistent with what you had done. I'm still nervous about request.getDecodedRequestURI() returning the original URI even after the request has been mapped to a welcome page. This violates spec requirement that any container specific mechanism for mapping request to welcome page must be indistinguishable from a direct request. Jan Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
Jan Luehe wrote: Remy, Remy Maucherat wrote: Jan Luehe wrote: Bill/Remy, But SRV.9.10 (Welcome Files) already has this: The container may send the request to the welcome resource with a forward, a redirect, or a container specific mechanism **that is indistinguishable from a direct request**. The latter to me implies that any sec constraints must be applied to the mapped welcome page (if any). The plot thickens. What do you mean by that? ;-) Do you agree the spec is pretty clear about the fact that any sec constraints must be applied to welcome page? It means that the statement would seem to be conflicting with other things, but still seems relevant to the topic. So it makes the problem more complex. Right. However, when I made that commit, the current mapper behavior may not have been in place already, or maybe it's simply that I thought the two would be equivalent (I was busy optimizing at the time). I don't quite remember ;) I think you did the right thing without realizing it. :) The change I committed earlier today is just consistent with what you had done. I was out to kiil the substring thing. I'm still nervous about request.getDecodedRequestURI() returning the original URI even after the request has been mapped to a welcome page. This violates spec requirement that any container specific mechanism for mapping request to welcome page must be indistinguishable from a direct request. Changing this is very risky, as it will have uses elsewhere. If using Eclipse, you should use the call hierarchy (since it's an internal method which is never used through reflection). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
Bill, Bill Barker wrote: - Original Message - From: Jan Luehe [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Wednesday, March 02, 2005 12:51 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java Bill/Remy, Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Wednesday, March 02, 2005 11:56 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java [EMAIL PROTECTED] wrote: luehe 2005/03/02 11:27:11 Modified:catalina/src/share/org/apache/catalina/realm RealmBase.java Log: Consider the case where original request was mapped to welcome page. In this case, the mapped welcome page (and not the original request URI!) needs to be the target of hasResourcePermission(). This is consistent with the change that had been made in findSecurityConstraints(). BTW, shouldn't request.getDecodedRequestURI() return the mapped welcome page (instead of the original URI) in this case? In other words, shouldn't the path passed to mappingData.requestPath.setString(pathStr) in Mapper.java be propagated to the request object associatd with the mappingData? I consider welcome files to be internal forwards (since it is allowed to handle them this way). As a result, they shouldn't be matched by secrurity constraints. Only the original request path should be the used (so here it's getDecodedRequestURI - as sent by the client). I agree with Remy. It's an internal Tomcat implementation detail that welcome-files aren't handled via DefaultServlet doing: RequestDispatcher rd = request.getRequestDispatcher(welcome[i]); rd.forward(request, response); Since this is explicitly allowed by the spec, nobody can expect that a security-constraint mapped only to the welcome-file will be applied. However, this is probably another thing that should be better specified in the 2.5 spec. But SRV.9.10 (Welcome Files) already has this: The container may send the request to the welcome resource with a forward, a redirect, or a container specific mechanism **that is indistinguishable from a direct request**. I read the emphasised text as referring to 'container specific mechanism'. So do I. indistinguishable from a direct request means that any sec constraints will have to be applied to welcome pages when the request is sent to the welcome page via container specific mechanism (as in Tomcat). Yes, I agree that the last-minute changes that were made to 9.10 made it a total mess, but it still explicitly allows DefaultServlet to do a rd.forward. Yes, in which case the welcome page that is the target of the rd.forward() will not be subjected to any sec constraints. So the spec is inconsistent as to whether sec constraints need to be applied to welcome pages. This means that web developers should always use a pattern of this form: url-pattern/*/url-pattern in their DD's security constraints if they want their welcome pages to be subjected to the specified sec constraints no matter which container their webapp is deployed on. If they specify: url-pattern*.jsp/url-pattern their index.jsp welcome page will not be subjected to any sec constraints in containers that send the request to the welcome page using rd.forward(). The latter to me implies that any sec constraints must be applied to the mapped welcome page (if any). Also, see the attached diffs, in particular: Firstly, I'm strongly -1 on the patch, since removing the 'if(found)return' statements causes Tomcat to no longer be spec-complient. Just because the spec is silly doesn't mean that we don't have to implement it. The patch I attached has been 1 year old. My main purpose in attaching it was to draw attention to this change in rev 1.24: -String uri = request.getDecodedRequestURI(); -String contextPath = hreq.getContextPath(); -if (contextPath.length() 0) -uri = uri.substring(contextPath.length()); +String uri = request.getRequestPathMB().toString(); in findSecurityConstraints(). Remy had restored the 'if(found)return' in rev 1.25: revision 1.25 date: 2004/01/11 09:23:42; author: remm; state: Exp; lines: +11 -11 - Ooops. Put back the if(found) blocks. revision 1.24 date: 2004/01/10 17:23:39; author: remm; state: Exp; lines: +16 -11 - findMethod wasn't called on the right collection. - The algorithm ignored extension mapped constraints as long as a widcard or exact mapped constraint was found. This doesn't seem right (I did quickly read the relevant portions of the spec). - Next, I'll try to optimize the algorithm (allocating a collection on each request is not good, we should add a matched contraints array on the request). When accessing host:port:/somecontext/,
DO NOT REPLY [Bug 33810] - Stream closed errors from JSP tags under load
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33810. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33810 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-03-03 00:08 --- Sounds like the client closed the connection while still writing content. Please use tomcat-user to debug this -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/juli/src/java/org/apache/juli ClassLoaderLogManager.java FileHandler.java
remm2005/03/02 16:23:00
Modified:juli/src/java/org/apache/juli ClassLoaderLogManager.java
FileHandler.java
Log:
- Fix NPE caused by my last change.
- Use ',' as separator for the handler lists.
- Just noticed that java.util.logging does support a handlers property on
loggers, and that I reinvented it
(I had been looking at the JDK 1.4 config files all along).
Revision ChangesPath
1.3 +4 -4
jakarta-tomcat-connectors/juli/src/java/org/apache/juli/ClassLoaderLogManager.java
Index: ClassLoaderLogManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/juli/src/java/org/apache/juli/ClassLoaderLogManager.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ClassLoaderLogManager.java2 Mar 2005 21:40:00 - 1.2
+++ ClassLoaderLogManager.java3 Mar 2005 00:23:00 - 1.3
@@ -150,9 +150,9 @@
final String handlers = getProperty(loggerName + .handlers);
if (handlers != null) {
logger.setUseParentHandlers(false);
-StringTokenizer tok = new StringTokenizer(handlers);
+StringTokenizer tok = new StringTokenizer(handlers, ,);
while (tok.hasMoreTokens()) {
-String handlerName = (tok.nextToken());
+String handlerName = (tok.nextToken().trim());
Handler handler = (Handler) info.handlers.get(handlerName);
if (handler != null) {
logger.addHandler(handler);
@@ -283,9 +283,9 @@
String rootHandlers = info.props.getProperty(.handlers);
String handlers = info.props.getProperty(handlers);
if (handlers != null) {
-StringTokenizer tok = new StringTokenizer(handlers);
+StringTokenizer tok = new StringTokenizer(handlers, ,);
while (tok.hasMoreTokens()) {
-String handlerName = (tok.nextToken());
+String handlerName = (tok.nextToken().trim());
String handlerClassName = handlerName;
String prefix = ;
if (handlerClassName.length() = 0) {
1.3 +4 -2
jakarta-tomcat-connectors/juli/src/java/org/apache/juli/FileHandler.java
Index: FileHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/juli/src/java/org/apache/juli/FileHandler.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- FileHandler.java 2 Mar 2005 21:40:00 - 1.2
+++ FileHandler.java 3 Mar 2005 00:23:00 - 1.3
@@ -297,8 +297,10 @@
String value = LogManager.getLogManager().getProperty(name);
if (value == null) {
value = defaultValue;
+} else {
+value = value.trim();
}
-return value.trim();
+return value;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33810] - Stream closed errors from JSP tags under load
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33810. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33810 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33810] - Stream closed errors from JSP tags under load
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33810. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33810 --- Additional Comments From [EMAIL PROTECTED] 2005-03-03 01:50 --- All this is happening from JSPs that use JSP tags. These JSPs work fine under normal load. If the stream is closed incorrectly by user code then this should happen all the time, not just under load. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/juli/src/java/org/apache/juli ClassLoaderLogManager.java FileHandler.java
remm2005/03/02 17:51:13
Modified:juli/src/java/org/apache/juli ClassLoaderLogManager.java
FileHandler.java
Log:
- Implement delegation in getProperty (when the current classloader does not
have any configuration).
- Read useParentHandlers property.
- Code cleanup in FileHandler.
Revision ChangesPath
1.4 +31 -5
jakarta-tomcat-connectors/juli/src/java/org/apache/juli/ClassLoaderLogManager.java
Index: ClassLoaderLogManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/juli/src/java/org/apache/juli/ClassLoaderLogManager.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ClassLoaderLogManager.java3 Mar 2005 00:23:00 - 1.3
+++ ClassLoaderLogManager.java3 Mar 2005 01:51:12 - 1.4
@@ -159,6 +159,17 @@
}
}
}
+
+// Parse useParentHandlers to set if the logger should delegate to
its parent.
+// Unlike java.util.logging, the default is to not delegate if a
list of handlers
+// has been specified for the logger.
+String useParentHandlersString = getProperty(loggerName +
.useParentHandlers);
+if ((useParentHandlersString != null)
+
(!Boolean.valueOf(useParentHandlersString).booleanValue())) {
+logger.setUseParentHandlers(false);
+} else {
+logger.setUseParentHandlers(true);
+}
return true;
}
@@ -216,11 +227,26 @@
}
final ClassLoader classLoader = Thread.currentThread()
.getContextClassLoader();
-String result =
-getClassLoaderInfo(classLoader).props.getProperty(name);
-if (result == null) {
-// FIXME: Look in parent classloader ? Probably not.
-result = super.getProperty(name);
+ClassLoaderLogInfo info = getClassLoaderInfo(classLoader);
+String result = info.props.getProperty(name);
+// If the property was not found, and the current classloader had no
+// configuration (property list is empty), look for the parent
classloader
+// properties.
+if ((result == null) (info.props.isEmpty())) {
+ClassLoader current = classLoader.getParent();
+while (current != null) {
+info = (ClassLoaderLogInfo) classLoaderLoggers.get(current);
+if (info != null) {
+result = info.props.getProperty(name);
+if ((result != null) || (!info.props.isEmpty())) {
+break;
+}
+}
+current = current.getParent();
+}
+if (result == null) {
+result = super.getProperty(name);
+}
}
// Simple property replacement (mostly for folder names)
if (result != null) {
1.4 +11 -72
jakarta-tomcat-connectors/juli/src/java/org/apache/juli/FileHandler.java
Index: FileHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/juli/src/java/org/apache/juli/FileHandler.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- FileHandler.java 3 Mar 2005 00:23:00 - 1.3
+++ FileHandler.java 3 Mar 2005 01:51:12 - 1.4
@@ -20,7 +20,6 @@
import java.io.File;
import java.io.FileWriter;
import java.io.PrintWriter;
-import java.io.UnsupportedEncodingException;
import java.sql.Timestamp;
import java.util.logging.ErrorManager;
import java.util.logging.Filter;
@@ -51,6 +50,14 @@
open();
}
+
+public FileHandler(String directory, String prefix, String suffix) {
+this();
+this.directory = directory;
+this.prefix = prefix;
+this.suffix = suffix;
+}
+
// - Instance
Variables
@@ -86,63 +93,6 @@
private PrintWriter writer = null;
-// -
Properties
-
-
-/**
- * Return the directory in which we create log files.
-public String getDirectory() {
-return (directory);
-}
- */
-
-
-/**
- * Set the directory in which we create log files.
- *
- * @param directory The new log file directory
-public void setDirectory(String directory) {
-this.directory = directory;
-}
- */
-
-
-/**
- * Return the log file prefix.
-public String getPrefix() {
-return (prefix);
-}
- */
-
-
-/**
-
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ValveBase.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: luehe 2005/02/23 11:27:56 Modified:catalina/src/share/org/apache/catalina/authenticator FormAuthenticator.java NonLoginAuthenticator.java SSLAuthenticator.java SingleSignOn.java catalina/src/share/org/apache/catalina/realm DataSourceRealm.java JDBCRealm.java JNDIRealm.java RealmBase.java UserDatabaseRealm.java catalina/src/share/org/apache/catalina/valves ValveBase.java Log: No change in functionality. Added new containerLog instance var to RealmBase and ValveBase, which is initialized as container.getLogger() inside setContainer(). This will make it easier to do something like containerLog = LogFactory.getLog(container.logName()+.RealmBase); in the future, as suggested by Bill Barker. Actually, this is probably a bad idea (or at least the implementation is bad): the logger must be retrieved only when the context class loader of the application is set. This is where I'm not following: ;-) I don't see any dependency on the context's context class loader when calling ContainerBase.getLogger(), which is implemented like this: logger = LogFactory.getLog(logName()); A context's context class loader is required only for loading webapp resources. Jan This means no retrieving the logger in ValveBase.setContainer, since this is first called in StandardContext(). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33810] - Stream closed errors from JSP tags under load
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33810. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33810 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-03-03 03:01 --- Looking at BodyContentImpl - the error is thrown if something tries to call write some time after close was already called on the BodyContent. Why close was called is up to your code. (For example, sendredirects, writing to stream after a forwards, ...) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Logging The Revenge
Hi, As I will rewrite the documentation for java.util.logging, I'd like to ask the question of how it will be packaged and distributed. The package needs to be placed in the classpath (note: any custom components, such as handlers, formatters, etc, can be deployed in other classloaders, the only requirement is that their classes must be visible to the classloader which contains the logging configuration where they are used), and needs a system property to be used when starting the JVM (using -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager). The defaults provided by the java.util.logging implementation inside the JVM are acceptable for a development use (if usage remains simple enough), but are bad for production. So overall, it is decent, but could be better. If the implementation is bundled, I'd recommend including it directly inside bootstrap.jar. If it's not, the package should be as easy to install as possible (it will be very small, it's a start :) ). Comments ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ValveBase.java
Jan Luehe wrote: Remy Maucherat wrote: Actually, this is probably a bad idea (or at least the implementation is bad): the logger must be retrieved only when the context class loader of the application is set. This is where I'm not following: ;-) I don't see any dependency on the context's context class loader when calling ContainerBase.getLogger(), which is implemented like this: logger = LogFactory.getLog(logName()); A context's context class loader is required only for loading webapp resources. The configuration for that logger should be doable at the webapp level (to summarize, I'd like to be able to have my logger configured using either /WEB-INF/classes/logging.properties or common/classes/logging.properties if the first one does not exist). The logging implementation gets which config it should lookup for the logger based on what the context CL is when calling getLogger. So the context CL needs to be set properly (or getLogger has to be called again). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ValveBase.java
Remy Maucherat wrote: Jan Luehe wrote: Remy Maucherat wrote: Actually, this is probably a bad idea (or at least the implementation is bad): the logger must be retrieved only when the context class loader of the application is set. This is where I'm not following: ;-) I don't see any dependency on the context's context class loader when calling ContainerBase.getLogger(), which is implemented like this: logger = LogFactory.getLog(logName()); A context's context class loader is required only for loading webapp resources. The configuration for that logger should be doable at the webapp level (to summarize, I'd like to be able to have my logger configured using either /WEB-INF/classes/logging.properties or common/classes/logging.properties if the first one does not exist). The logging implementation gets which config it should lookup for the logger based on what the context CL is when calling getLogger. So the context CL needs to be set properly (or getLogger has to be called again). Got it. Thanks! Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging The Revenge
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Wednesday, March 02, 2005 6:10 PM Subject: Logging The Revenge Hi, As I will rewrite the documentation for java.util.logging, I'd like to ask the question of how it will be packaged and distributed. The package needs to be placed in the classpath (note: any custom components, such as handlers, formatters, etc, can be deployed in other classloaders, the only requirement is that their classes must be visible to the classloader which contains the logging configuration where they are used), and needs a system property to be used when starting the JVM (using -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager). The defaults provided by the java.util.logging implementation inside the JVM are acceptable for a development use (if usage remains simple enough), but are bad for production. So overall, it is decent, but could be better. If the implementation is bundled, I'd recommend including it directly inside bootstrap.jar. If it's not, the package should be as easy to install as possible (it will be very small, it's a start :) ). Comments ? As a log4j user I'd prefer a separate jar for Juli (so that I can remove her easily :). I'm pretty agnostic as to including it in the default tomcat-5.5.x.tar.gz or as tomcat-logging.tar.gz. In the second case, it should be enough to have tomcat-juli.jar. It's easy enough to have catalina.sh/bat look to see if tomcat-juli.jar is in bin and add the -Dj.u.l.m= to the JAVA_OPTS. I haven't had time to look at it in detail, but from what I have looked at Juli looks nice. Rémy - 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 33810] - Stream closed errors from JSP tags under load
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33810. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33810 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-03-03 04:14 --- There are no explicit stream closes in JSP. The JSPs use Struts tags which work fine for some time and fail with these errors after some time and under load. If it is a code issue it should fail consistently under normal cases too. This could be a problem with how Tomcat handles JSP tags at run-time. If you need more information, I will be glad to provide. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
