[GUMP@brutus]: Project jakarta-tomcat-jasper_tc5 (in module jakarta-tomcat-jasper_tc5) 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-jasper_tc5 has an issue affecting its community integration. This issue affects 14 projects, and has been outstanding for 2 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 - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-jasper_tc5 : JavaServer Pages JSP 2.0 implementation (for Tomcat 5.x) - jakarta-tomcat-jk : Connectors to various web servers - metro-reflector-blocks-complete : Avalon SVN Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-jasper_tc5/jakarta-tomcat-jasper_tc5/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [jasper-runtime.jar] identifier set to output basename: [jasper-runtime] -DEBUG- Output [jasper-compiler.jar] identifier set to output basename: [jasper-compiler] -DEBUG- Dependency on ant exists, no need to add for property ant.jar. -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-jasper_tc5/jakarta-tomcat-jasper_tc5/gump_work/build_jakarta-tomcat-jasper_tc5_jakarta-tomcat-jasper_tc5.html Work Name: build_jakarta-tomcat-jasper_tc5_jakarta-tomcat-jasper_tc5 (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Djsp-api.jar=/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar -Dcommons-el.jar=/usr/local/gump/public/workspace/jakarta-commons/el/dist/commons-el.jar -Djasper-compiler-jdt.jar=/usr/local/gump/packages/eclipse-3.0.1/plugins/org.eclipse.jdt.core_3.0.1/jdtcore.jar -Dant.jar=/usr/local/gump/public/workspace/ant/dist/lib/ant.jar -Dservlet-api.jar=/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar -Dcompile.source=1.4 dist [Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-jasper_tc5/jasper2] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/el/dist/commons-el.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar:/usr/local/gump/packages/eclipse-3.0.1/plugins/org.eclipse.jdt.core_3.0.1/jdtcore.jar - Buildfile: build.xml build-prepare: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-tomcat-jasper_tc5/jasper2/build [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-tomcat-jasper_tc5/jasper2/build/bin [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-tomcat-jasper_tc5/jasper2/build/common/classes [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-tomcat-jasper_tc5/jasper2/build/common/lib [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-tomcat-jasper_tc5/jasper2/build/shared/classes [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-tomcat-jasper_tc5/jasper2/build/shared/lib copy-launcher.jars: build-static: [copy] Copying 4 files to /home/gump/workspaces2/public/workspace/jakarta-tomcat-jasper_tc5/jasper2/build/bin build-only: [javac]
[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 84 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-06042005/build/libtool --silent --mode=compile gcc -I/usr/local/gump/public/workspace/apache-httpd/dest-06042005/include -g -O2 -g -O2 -pthread -DHAVE_APR -I/usr/local/gump/public/workspace/apr/dest-06042005/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-06042005/build/libtool: /usr/local/gump/public/workspace/apache-httpd/dest-06042005/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 2506042005, brutus:brutus-public:2506042005 Gump E-mail Identifier (unique within run) #18. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Tomcat 5.X connectors SSL Accelerator proxy support
[EMAIL PROTECTED] wrote: Dev Team, Attached is a patch to address the Tomcat 5.X inability to specify a secure proxy without an SSL connection. The goal is to specify secure=true, scheme=https, proxyPort=443, and proxyName=ssl-accelerator.domain.com on a plain HTTP Connector in server.xml. BTW: This proxy does not allow to get client certificates doesn't it? I am not sure if this is the best, (or even acceptable), solution, but it is the simplest I could come up with while not changing the documented Tomcat 5.X Connector attributes. The configuration above used to work with Tomcat 4.1, because the SSL support was never enabled unless the Factory/ tag was specified within the Connector specification. The approach here for Tomcat 5.X is to ignore the secure attribute/property configuration in the underlying Http11Protocol instance if the Connector is configured with either a proxyPort or proxyName and there are no other explicit SSL configuration attributes specified. The logic behind this choice is that use of an SSL Accelerator will imply a proxied port and/or host and will not specify any SSL related options. Furthermore, in the event a proxied SSL Connection was desired afterall, it will almost always require at least some keystore access configuration. One possible variation might be to only ignore the secure configuration if the proxyName is set; this might be preferable if simple port forwarding on the host server is more prevalent than the use of SSL Accelerators, (albeit potentially more confusing). The patch is limited to the jakarta-tomcat-connectors module and should be compatible with Tomcat 4.1 and Tomcat 5.X versions. It has been tested only against Tomcat 5.0.30 so far. If someone the Dev Team indicates that this patch is acceptable, I can certainly proceed with Tomcat 4.1 and Tomcat 5.5 testing... I just would like a sanity check first if at all possible. Note: I believe that the minor patch to o/a/coyote/Request.java has already been performed against the Tomcat 5.5 main trunk by Remy, but was missing on the Tomcat 5.0 branch. Thanks for your consideration in advance, Randy Watler Finali-Convergys Corporation - 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: Reminder: 5.5.9 tomorrow
Yoav Shapira wrote: Hi, This is just a reminder that I plan to cut and tag Tomcat version 5.5.9 tomorrow, Saturday March 26th, at 1400h my time, which is 1900h UTC/GMT. Any vote planned on 5.5.9 ? There's no new and better build coming up anytime soon, as some risky changes have been made in CVS. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reminder: 5.5.9 tomorrow
Hi, Any vote planned on 5.5.9 ? There's no new and better build coming up anytime soon, as some risky changes have been made in CVS. I really like to have TCK results before voting. But I suppose I've asked twice already and it's been more than a week, so we might as well have a vote now (in a separate thread). Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA [EMAIL PROTECTED] / [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] 5.5.9 Stability
Hi, Tomcat v5.5.9 has been out for more than a week now, so hopefully we have had time to test/use it. We're still waiting for the TCK results, but let's hear your opinion: [ ] Stable -- good build [ ] Beta -- minor bad stuff: what is it? [ ] Alpha -- something serious is wrong: what is it? The vote will run for about 72 hours as usual. Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA [EMAIL PROTECTED] / [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.9 Stability
From what I could see in my first devel site (the first not using a Tomcat 3.3.2), it seems stable. On Apr 6, 2005 1:25 PM, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, Tomcat v5.5.9 has been out for more than a week now, so hopefully we have had time to test/use it. We're still waiting for the TCK results, but let's hear your opinion: [ ] Stable -- good build [ ] Beta -- minor bad stuff: what is it? [ ] Alpha -- something serious is wrong: what is it? The vote will run for about 72 hours as usual. Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA [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]
New TLP draft
Hi, Here's a new draft with the necessary updates. I suppose this needs to be sent to the PMC for approval. If this draft is ok, I will send it there. Then there are infrastructure taks: - renaming mailing lists - moving CVS - new DNS and virtual host To summarize things: - I will be the proposed first PMC chair - PMC chairs will serve for one year, and cannot serve consecutive one year terms (shouldn't this be put in the resolution text ? - if so, please help writing it, as I can't write ASF resolution compliant language) - although the ASF infrastructure is quite aggressive in pushing Subversion, I find it harder to work with than CVS at the moment (including crucial - for me - revision graphs, and better tool support); as a result, I think I would prefer keeping CVS for the time being - feel free to take any further actions to update the PMC list (as proposed by Costin) Rémy --- Draft TLP resolution --- X. Establish the Apache Tomcat Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the implementation of the Java Servlet and Java Server Pages specifications, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tomcat PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tomcat PMC be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software related to the implementation of the Java Servlet and Java Server Pages specifications based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Tomcat be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tomcat PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tomcat PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tomcat PMC: Jean-Francois Arcand ([EMAIL PROTECTED]) Bill Barker ([EMAIL PROTECTED]) Ian Darwin ([EMAIL PROTECTED]) Jean-Frederic Clere ([EMAIL PROTECTED]) Tim Funk ([EMAIL PROTECTED]) Henri Gomez ([EMAIL PROTECTED]) Filip Hanik ([EMAIL PROTECTED]) Larry Isaacs ([EMAIL PROTECTED]) Jim Jagielski ([EMAIL PROTECTED]) Jan Luehe ([EMAIL PROTECTED]) Costin Manolache ([EMAIL PROTECTED]) Remy Maucherat ([EMAIL PROTECTED]) Kurt Miller ([EMAIL PROTECTED]) Glenn Nielsen ([EMAIL PROTECTED]) Amy Roh ([EMAIL PROTECTED]) Peter Rossbach ([EMAIL PROTECTED]) Yoav Shapira ([EMAIL PROTECTED]) Mark Thomas ([EMAIL PROTECTED]) Mladen Turk ([EMAIL PROTECTED]) Keith Wannamaker ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Remy Maucherat be appointed to the office of Vice President, Apache Tomcat, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Tomcat PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Tomcat Project; and be it further RESOLVED, that the initial Apache Tomcat PMC be and hereby is tasked with the migration and rationalization of the Apache Jakarta PMC Tomcat subproject; and be it further RESOLVED, that all responsibility pertaining to the Jakarta Tomcat sub-project and encumbered upon the Apache Jakarta PMC are hereafter discharged. --- End draft TLP resolution --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New TLP draft
not sure if this is important or not, but how should the migration of the mailing list happen? everyone subscribing to tomcat-user an tomcat-dev automatically get subscribed to the new one? peter On Apr 6, 2005 8:15 AM, Remy Maucherat [EMAIL PROTECTED] wrote: Hi, Here's a new draft with the necessary updates. I suppose this needs to be sent to the PMC for approval. If this draft is ok, I will send it there. Then there are infrastructure taks: - renaming mailing lists - moving CVS - new DNS and virtual host To summarize things: - I will be the proposed first PMC chair - PMC chairs will serve for one year, and cannot serve consecutive one year terms (shouldn't this be put in the resolution text ? - if so, please help writing it, as I can't write ASF resolution compliant language) - although the ASF infrastructure is quite aggressive in pushing Subversion, I find it harder to work with than CVS at the moment (including crucial - for me - revision graphs, and better tool support); as a result, I think I would prefer keeping CVS for the time being - feel free to take any further actions to update the PMC list (as proposed by Costin) Rémy --- Draft TLP resolution --- X. Establish the Apache Tomcat Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the implementation of the Java Servlet and Java Server Pages specifications, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tomcat PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tomcat PMC be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software related to the implementation of the Java Servlet and Java Server Pages specifications based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Tomcat be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tomcat PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tomcat PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tomcat PMC: Jean-Francois Arcand ([EMAIL PROTECTED]) Bill Barker ([EMAIL PROTECTED]) Ian Darwin ([EMAIL PROTECTED]) Jean-Frederic Clere ([EMAIL PROTECTED]) Tim Funk ([EMAIL PROTECTED]) Henri Gomez ([EMAIL PROTECTED]) Filip Hanik ([EMAIL PROTECTED]) Larry Isaacs ([EMAIL PROTECTED]) Jim Jagielski ([EMAIL PROTECTED]) Jan Luehe ([EMAIL PROTECTED]) Costin Manolache ([EMAIL PROTECTED]) Remy Maucherat ([EMAIL PROTECTED]) Kurt Miller ([EMAIL PROTECTED]) Glenn Nielsen ([EMAIL PROTECTED]) Amy Roh ([EMAIL PROTECTED]) Peter Rossbach ([EMAIL PROTECTED]) Yoav Shapira ([EMAIL PROTECTED]) Mark Thomas ([EMAIL PROTECTED]) Mladen Turk ([EMAIL PROTECTED]) Keith Wannamaker ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Remy Maucherat be appointed to the office of Vice President, Apache Tomcat, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Tomcat PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Tomcat Project; and be it further RESOLVED, that the initial Apache Tomcat PMC be and hereby is tasked with the migration and rationalization of the Apache Jakarta PMC Tomcat subproject; and be it further RESOLVED, that all responsibility pertaining to the Jakarta Tomcat sub-project and encumbered upon the Apache Jakarta PMC are hereafter discharged. --- End draft TLP resolution --- - To unsubscribe, e-mail:
How Tomcat validates web.xml
Hi, I found some strange behavior while using Tomcat 5.5.7. In my web.xml Schema declaration, I have this: web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation= http://java.sun.com/xml/ns/j2ee web-app_2_4.xsd version=2.4 (I enabled xmlValidation=true for Host element in server.xml) I found it odd that under schemaLocation, a relative URL is given to the XSD file. Yet, there is no web-app_2_4.xsd file in WEB-INF directory. How does it validate web.xml then? So, I substituted web-app_2_4.xsd with the word whatever. To my surprise it worked again without any problems. What is going on? How does Tomcat validate web.xml of an application? And what's WAY more important: what does the servlet spec say about how a server should validate web.xml? I didn't see anything there at all about this, so I assumed that regular XML rules apply. Could someone straighten me out on this issue? Thanks, NG. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Nested tag problem in tomcat 5.0.29
Hi all, I am having problem compiling jsp pages with nested struts tags. Is this a known error ? It says Unable to compile class for JSP Generated servlet error: %CATALINA_HOME%\work\Catalina\localhost\test\org\apache\jsp\ui\Showjsp .java:124: _jspx_meth_logic_equal_0(javax.servlet.jsp.tagext.JspTag,javax.servlet .jsp.PageContext) in org.apache.jsp.ui.ShowPricingConditionPanel_jsp cannot be applied to (org.apache.struts.taglib.html.FormTag,javax.servlet.jsp.PageContext) if (_jspx_meth_logic_equal_0(_jspx_th_html_form_0, _jspx_page_context)) Has anybody got this error. Kindly advise. Thanks and Regards, Satya
Re: How Tomcat validates web.xml
N G wrote: Hi, I found some strange behavior while using Tomcat 5.5.7. In my web.xml Schema declaration, I have this: web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation= http://java.sun.com/xml/ns/j2ee web-app_2_4.xsd version=2.4 (I enabled xmlValidation=true for Host element in server.xml) I found it odd that under schemaLocation, a relative URL is given to the XSD file. Yet, there is no web-app_2_4.xsd file in WEB-INF directory. How does it validate web.xml then? So, I substituted web-app_2_4.xsd with the word whatever. To my surprise it worked again without any problems. What is going on? How does Tomcat validate web.xml of an application? Tomcat uses it's own local version. This way you can use Tomcat without being connected to the internet, or pay the price of connection over http everytime a war is deployed. And what's WAY more important: what does the servlet spec say about how a server should validate web.xml? See the Servlet Spec. SRV.13.2 Rules for Processing the Deployment Descriptor This section lists some general rules that Web containers and developers must note concerning the processing of the deployment descriptor for a Web application. · Web containers must remove all leading and trailing whitespace, which is de- fined as S(white space) in XML 1.0 (http://www.w3.org/TR/2000/WD-xml- 2e-2814), for the element content of the text nodes of a deployment de- scriptor. · The deployment descriptor must be valid against the schema. Web containers and tools that manipulate Web applications have a wide range of options for checking the validity of a WAR. This includes checking the validity of the de- ployment descriptor document held within. The containers and tools that are part of J2EE technology-compliant implementation are required to validate deployment descriptor against the XML schema for structural correctness. The validation is recommended, but not required for the web containers and tools that are not part of J2EE technology-compliant implementation. -- Jeanfrancois I didn't see anything there at all about this, so I assumed that regular XML rules apply. Could someone straighten me out on this issue? Thanks, NG. - 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]
DO NOT REPLY [Bug 34330] New: - uriworkermap redirections do not work properly
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=34330. 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=34330 Summary: uriworkermap redirections do not work properly Product: Tomcat 5 Version: 5.0.0 Platform: Other OS/Version: Windows Server 2003 Status: NEW Severity: critical Priority: P2 Component: Connector:AJP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The following are my uriworkermap.properties: /supplement/*=supplement /main/*=main /*/=main What this does is: - any URL with 'supplement' goes to the tomcat instance serving supplement pages - any URL with 'main' goes to the main instance - any URL with '/' ending the query string goes to the main instance. The above set of rules does not fully satisfy all the requirements. What we additionally need is a default redirection.. if none of the 3 mappings, the request should be redirected to the 'main' worker as well. I thought this could be done my modifying the last line of the uriworkermap to this: /*=main But when this is done, all requests go to the main tomcat instance. The /supplement/ is completelely ignored. Also, having a trailing '/' to make something work will not satisfy all the URLs that might come to the site. For instance the following URL will work: http://mysite.com/10.1108/21992840238402/ but this will not http://mysite/10.1108/21992840238402 This is quite restrictive. And I feel this is a bug in the latest release of the isapi redirector. ( Version 1.2.10) [Note: This functionality was available in the mod-jk2 version, but now that that is de-supported, we are trying to migrate to JK.. but are coming up against this limitation]. Any help would be greatly appreciated. Best Regards, Nags. -- 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 33711] - Memory leak (classloader) with Log4J and Single Sign On.
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=33711. 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=33711 --- Additional Comments From [EMAIL PROTECTED] 2005-04-06 16:43 --- I had a another look into this, and seems better, but I'm not completely convinced that it is entirely fixed. I can't pin down exactly what is happening, but looks like the very first deployment does not fully undeploy (release all references), but subsequent cycles appear to work correctly. The reason it is odd is because after the first cycle my profiler does not list my BigServlet class, but the 20MB it allocates never appears to be released (but for each later cycle the graph shows their heap allocations are released). So, sorry but I can't really give a definite answer. Yes it is a big improvement, but no I can't say it is entirely fixed. My cycle is: 1) visit some application that does a sign-in for SSO 2) use the manager to list the apps 3) memory profiler snapshot 4) drop a leak.war in the web apps folder (auto deploy) 5) visit leak with a browser 6) undeploy leak using manager web app 7) repeat from 2 several times, and compare snaphots as well as graphing various memory stats and heap, etc. Thanks for all the efforts! Kev -- 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: New TLP draft
Remy Maucherat wrote: Hi, Here's a new draft with the necessary updates. I suppose this needs to be sent to the PMC for approval. If this draft is ok, I will send it there. Then there are infrastructure taks: - renaming mailing lists Is that just keeping both lists and moving them up the domain hierarchy, or is there a move to change the list names while we're at it? - moving CVS - new DNS and virtual host To summarize things: - I will be the proposed first PMC chair Lucky you :-) Everyone else I hope thanks you for taking this on. - PMC chairs will serve for one year, and cannot serve consecutive one year terms (shouldn't this be put in the resolution text ? - if so, please help writing it, as I can't write ASF resolution compliant language) In a conventional organization I think this would be in a separate by-laws document, but I'm not up-to-date on Apache organization. If it belongs in the resolution, I will take a stab at implementing a wording that will be perceived as appropriate and efficacious :-) - although the ASF infrastructure is quite aggressive in pushing Subversion, I find it harder to work with than CVS at the moment (including crucial - for me - revision graphs, and better tool support); as a result, I think I would prefer keeping CVS for the time being I agree - I'd prefer to stay on CVS, at least until the tool support is more widespread (e.g., Eclipse doesn't ship with a SubVersion plug-in yet, though there are a few available). Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nested tag problem in tomcat 5.0.29
Please DO NOT cross post. The mailing list guidelines are very clear on this issue (http://jakarta.apache.org/site/mail.html) Mark Narayan, Satya wrote: Hi all, I am having problem compiling jsp pages with nested struts tags. Is this a known error ? It says Unable to compile class for JSP Generated servlet error: %CATALINA_HOME%\work\Catalina\localhost\test\org\apache\jsp\ui\Showjsp .java:124: _jspx_meth_logic_equal_0(javax.servlet.jsp.tagext.JspTag,javax.servlet .jsp.PageContext) in org.apache.jsp.ui.ShowPricingConditionPanel_jsp cannot be applied to (org.apache.struts.taglib.html.FormTag,javax.servlet.jsp.PageContext) if (_jspx_meth_logic_equal_0(_jspx_th_html_form_0, _jspx_page_context)) Has anybody got this error. Kindly advise. Thanks and Regards, Satya - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: New TLP draft
Hi, Is that just keeping both lists and moving them up the domain hierarchy, or is there a move to change the list names while we're at it? I think we're keeping the same list names, but moving the domain. - PMC chairs will serve for one year, and cannot serve consecutive one year terms (shouldn't this be put in the resolution text ? - if so, please help writing it, as I can't write ASF resolution compliant language) In a conventional organization I think this would be in a separate by-laws document, but I'm not up-to-date on Apache organization. If it belongs in the resolution, I will take a stab at implementing a wording that will be perceived as appropriate and efficacious :-) In the ASF as well, that's in the by-laws, not in the resolution. The resolution is complete as-is. Rules such as emeritus status and PMC chair elections go into the by-laws. BTW, the struts project recently went through this and ended up with I think are a decent set of by-laws. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33711] - Memory leak (classloader) with Log4J and Single Sign On.
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=33711. 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=33711 --- Additional Comments From [EMAIL PROTECTED] 2005-04-06 17:37 --- What did you test exactly (CVS version ?) ? Still using log4j for everything ? Do you have any idea on where the reference to the classloader would be kept ? -- 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: New TLP draft
Ian F. Darwin wrote: Remy Maucherat wrote: Hi, Here's a new draft with the necessary updates. I suppose this needs to be sent to the PMC for approval. If this draft is ok, I will send it there. Then there are infrastructure taks: - renaming mailing lists Is that just keeping both lists and moving them up the domain hierarchy, or is there a move to change the list names while we're at it? I have no idea how infrastructure would do it, but it's part of the process. - moving CVS - new DNS and virtual host To summarize things: - I will be the proposed first PMC chair Lucky you :-) Everyone else I hope thanks you for taking this on. - PMC chairs will serve for one year, and cannot serve consecutive one year terms (shouldn't this be put in the resolution text ? - if so, please help writing it, as I can't write ASF resolution compliant language) In a conventional organization I think this would be in a separate by-laws document, but I'm not up-to-date on Apache organization. If it belongs in the resolution, I will take a stab at implementing a wording that will be perceived as appropriate and efficacious :-) That makes sense to me that it would be a project level rule. - although the ASF infrastructure is quite aggressive in pushing Subversion, I find it harder to work with than CVS at the moment (including crucial - for me - revision graphs, and better tool support); as a result, I think I would prefer keeping CVS for the time being I agree - I'd prefer to stay on CVS, at least until the tool support is more widespread (e.g., Eclipse doesn't ship with a SubVersion plug-in yet, though there are a few available). They'd have to improve a lot very fast (from what was posted, CVS at the ASF dies at the end of the year) ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New TLP draft
Yoav Shapira wrote: BTW, the struts project recently went through this and ended up with I think are a decent set of by-laws. Very good :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New TLP draft
you mean at the speed of light. It's already April, so they only have 5-6 months if they really want to get plugin out that matches the current CVS support. peter On Apr 6, 2005 11:37 AM, Remy Maucherat [EMAIL PROTECTED] wrote: They'd have to improve a lot very fast (from what was posted, CVS at the ASF dies at the end of the year) ;) 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]
cvs commit: jakarta-tomcat-catalina/webapps/docs/config http.xml ajp.xml
remm2005/04/06 08:54:05 Modified:webapps/docs/config http.xml ajp.xml Log: - Fix AJP documentation error about connection timeout (no timeout by default). Revision ChangesPath 1.21 +2 -4 jakarta-tomcat-catalina/webapps/docs/config/http.xml Index: http.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/http.xml,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- http.xml 22 Nov 2004 20:18:30 - 1.20 +++ http.xml 6 Apr 2005 15:54:05 - 1.21 @@ -158,10 +158,8 @@ subsection name=Standard Implementation - pThe standard implementation of the strongHTTP - Connector/strong is - strongorg.apache.coyote.tomcat5.CoyoteConnector/strong. - It supports the following additional attributes (in addition to the + p + HTTP supports the following additional attributes (in addition to the common attributes listed above):/p attributes 1.13 +8 -9 jakarta-tomcat-catalina/webapps/docs/config/ajp.xml Index: ajp.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/ajp.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- ajp.xml 13 Dec 2004 14:25:05 - 1.12 +++ ajp.xml 6 Apr 2005 15:54:05 - 1.13 @@ -159,9 +159,8 @@ subsection name=Standard Implementation - pThe standard implementation of strongAJP Connector/strong is - strongorg.apache.coyote.tomcat5.CoyoteConnector/strong, but you - must specify the protocol attribute (see below)./p + pTo use AJP, you + must specify the protocol attribute (see above)./p pstrongThis implementation supports the AJP 1.3 protocol./strong/p @@ -186,6 +185,12 @@ value is 10./p /attribute +attribute name=connectionTimeout required=false + pThe number of milliseconds this strongConnector/strong will wait, + after accepting a connection, for the request URI line to be + presented. The default value is infinite (i.e. no timeout)./p +/attribute + attribute name=minProcessors required=false strongdeprecated/strong pThe minimum number of processors to start at initialization time. @@ -239,12 +244,6 @@ circumstances. This is set to codetrue/code by default./p /attribute -attribute name=soTimeout required=false - pThe number of milliseconds this strongConnector/strong will wait, - after accepting a connection, for the request URI line to be - presented. The default value is 6 (i.e. 60 seconds)./p -/attribute - attribute name=tomcatAuthentication required=false pIf set to codetrue/code, the authetication will be done in Tomcat. Otherwise, the authenticated principal will be propagated from the native - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33711] - Memory leak (classloader) with Log4J and Single Sign On.
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=33711. 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=33711 --- Additional Comments From [EMAIL PROTECTED] 2005-04-06 17:58 --- (In reply to comment #18) What did you test exactly (CVS version ?) ? Still using log4j for everything ? Do you have any idea on where the reference to the classloader would be kept ? I updated to CVS head just after you committed the changes (31/3 maybe? can't remember). The content of my test WAR is: jar -ft leak.war index.jsp META-INF/context.xml META-INF/MANIFEST.MF META-INF/ WEB-INF/classes/ WEB-INF/classes/BigServlet.class WEB-INF/lib/ WEB-INF/lib/commons-logging.1.0.3.jar WEB-INF/lib/log4j.1.2.8.jar WEB-INF/web.xml WEB-INF/ Context.xml is simply: Context antiResourceLocking=true antiJARLocking=true /Context BigServlet simply has a static byte[] to allocate 20MB, initialised in the init () method, and also logs a message. Web.xml simply specifies it is loaded on startup, and that everything in the web app required the user to be in a given role. The JSP simply displays the remoteUser and SessionID. [Note: this configuration above is just for my test web app and we try to work around it. For production we include the Log4J jar only in our web app, and then use separate jdk logging for anything that is done through commons- logging.] As for ideas as to what is holding the reference, no I don't have ideas. The profiler I'm currently evaluating isn't helping me there :-( The best I used so far (and was using back when I first reported) was YourKit4.0, but my eval has expired. K. -- 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: New TLP draft
It appears that my name (Kin-man Chung [EMAIL PROTECTED]) has been dropped from the PMC. Hope this is not intentional. :-) On Wed, 2005-04-06 at 05:15, Remy Maucherat wrote: Hi, Here's a new draft with the necessary updates. I suppose this needs to be sent to the PMC for approval. If this draft is ok, I will send it there. Then there are infrastructure taks: - renaming mailing lists - moving CVS - new DNS and virtual host To summarize things: - I will be the proposed first PMC chair - PMC chairs will serve for one year, and cannot serve consecutive one year terms (shouldn't this be put in the resolution text ? - if so, please help writing it, as I can't write ASF resolution compliant language) - although the ASF infrastructure is quite aggressive in pushing Subversion, I find it harder to work with than CVS at the moment (including crucial - for me - revision graphs, and better tool support); as a result, I think I would prefer keeping CVS for the time being - feel free to take any further actions to update the PMC list (as proposed by Costin) Rmy --- Draft TLP resolution --- X. Establish the Apache Tomcat Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the implementation of the Java Servlet and Java Server Pages specifications, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tomcat PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tomcat PMC be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software related to the implementation of the Java Servlet and Java Server Pages specifications based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Tomcat be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tomcat PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tomcat PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tomcat PMC: Jean-Francois Arcand ([EMAIL PROTECTED]) Bill Barker ([EMAIL PROTECTED]) Ian Darwin ([EMAIL PROTECTED]) Jean-Frederic Clere ([EMAIL PROTECTED]) Tim Funk ([EMAIL PROTECTED]) Henri Gomez ([EMAIL PROTECTED]) Filip Hanik ([EMAIL PROTECTED]) Larry Isaacs ([EMAIL PROTECTED]) Jim Jagielski ([EMAIL PROTECTED]) Jan Luehe ([EMAIL PROTECTED]) Costin Manolache ([EMAIL PROTECTED]) Remy Maucherat ([EMAIL PROTECTED]) Kurt Miller ([EMAIL PROTECTED]) Glenn Nielsen ([EMAIL PROTECTED]) Amy Roh ([EMAIL PROTECTED]) Peter Rossbach ([EMAIL PROTECTED]) Yoav Shapira ([EMAIL PROTECTED]) Mark Thomas ([EMAIL PROTECTED]) Mladen Turk ([EMAIL PROTECTED]) Keith Wannamaker ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Remy Maucherat be appointed to the office of Vice President, Apache Tomcat, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Tomcat PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Tomcat Project; and be it further RESOLVED, that the initial Apache Tomcat PMC be and hereby is tasked with the migration and rationalization of the Apache Jakarta PMC Tomcat subproject; and be it further RESOLVED, that all responsibility pertaining to the Jakarta Tomcat sub-project and encumbered upon the Apache Jakarta PMC are hereafter discharged. --- End draft TLP resolution --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How Tomcat validates web.xml
On Apr 6, 2005 10:31 AM, Jeanfrancois Arcand [EMAIL PROTECTED] wrote: Tomcat uses it's own local version. This way you can use Tomcat without being connected to the internet, or pay the price of connection over http everytime a war is deployed. And what's WAY more important: what does the servlet spec say about how a server should validate web.xml? See the Servlet Spec. SRV.13.2 Rules for Processing the Deployment Descriptor This section lists some general rules that Web containers and developers must note concerning the processing of the deployment descriptor for a Web application. · Web containers must remove all leading and trailing whitespace, which is de- fined as S(white space) in XML 1.0 (http://www.w3.org/TR/2000/WD-xml- 2e-2814), for the element content of the text nodes of a deployment de- scriptor. · The deployment descriptor must be valid against the schema. Web containers and tools that manipulate Web applications have a wide range of options for checking the validity of a WAR. This includes checking the validity of the de- ployment descriptor document held within. The containers and tools that are part of J2EE technology-compliant implementation are required to validate deployment descriptor against the XML schema for structural correctness. The validation is recommended, but not required for the web containers and tools that are not part of J2EE technology-compliant implementation. Yes, I saw this. However, what gives a PORTABLE application the right to specify a relative URL for the location of the Schema and not provide that schema there? I don't see anything in this paragraph that says this is allowed. SO, are you saying that even though Tomcat will accept whatever you put for the path to the Schema (since it uses its own copy), the app will not necessarily be portable to other servers since they might choose to actually pay attention to the schema location specified by web.xml? So, to guarantee that the app is 100% portable, you must specify: web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation= http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=2.4 Am I correct? Thanks, NG. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New new TLP draft
Kin-man Chung wrote: It appears that my name (Kin-man Chung [EMAIL PROTECTED]) has been dropped from the PMC. Hope this is not intentional. :-) Done. Rmy --- Draft TLP resolution --- X. Establish the Apache Tomcat Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the implementation of the Java Servlet and Java Server Pages specifications, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tomcat PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tomcat PMC be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software related to the implementation of the Java Servlet and Java Server Pages specifications based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Tomcat be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tomcat PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tomcat PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tomcat PMC: Jean-Francois Arcand ([EMAIL PROTECTED]) Bill Barker ([EMAIL PROTECTED]) Kin-man Chung ([EMAIL PROTECTED]) Jean-Frederic Clere ([EMAIL PROTECTED]) Ian Darwin ([EMAIL PROTECTED]) Tim Funk ([EMAIL PROTECTED]) Henri Gomez ([EMAIL PROTECTED]) Filip Hanik ([EMAIL PROTECTED]) Larry Isaacs ([EMAIL PROTECTED]) Jim Jagielski ([EMAIL PROTECTED]) Jan Luehe ([EMAIL PROTECTED]) Costin Manolache ([EMAIL PROTECTED]) Remy Maucherat ([EMAIL PROTECTED]) Kurt Miller ([EMAIL PROTECTED]) Glenn Nielsen ([EMAIL PROTECTED]) Amy Roh ([EMAIL PROTECTED]) Peter Rossbach ([EMAIL PROTECTED]) Yoav Shapira ([EMAIL PROTECTED]) Mark Thomas ([EMAIL PROTECTED]) Mladen Turk ([EMAIL PROTECTED]) Keith Wannamaker ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Remy Maucherat be appointed to the office of Vice President, Apache Tomcat, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Tomcat PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Tomcat Project; and be it further RESOLVED, that the initial Apache Tomcat PMC be and hereby is tasked with the migration and rationalization of the Apache Jakarta PMC Tomcat subproject; and be it further RESOLVED, that all responsibility pertaining to the Jakarta Tomcat sub-project and encumbered upon the Apache Jakarta PMC are hereafter discharged. --- End draft TLP resolution --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New TLP draft
Looks good. Just an idea, it may be nice to have the 3 new lists tomcat-bug - bug updates from bugzilla. When I subscribe to other groups - I sometimes do not care about bug updates and need to write filters to automatically delete them. I am guessing some others might be more interested in the dev discussion and not the bugs. tomcat-cvs - Same as tomcat-bug but just for cvs commits. tomcat-gump - For deaths by gump. If your not a committer - these are useless to someone. -Tim Remy Maucherat wrote: Hi, Here's a new draft with the necessary updates. I suppose this needs to be sent to the PMC for approval. If this draft is ok, I will send it there. Then there are infrastructure taks: - renaming mailing lists - moving CVS - new DNS and virtual host - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
VOTE on final TLP draft
BTW, the struts project recently went through this and ended up with I think are a decent set of by-laws. ... RESOLVED, that the initial Apache Tomcat PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Tomcat Project; and be it further OK, so the Resolutions mean we don't have to decide on our set of bylaws just yet. That being the case, if there is nothing more to discuss over the set of Resolutions, should we just have the initial PMC members vote on it and send it to the Board for approval? This does not need to be a secret ballot since it's just pro/con, so we should be able to move quickly. I volunteer to be vote counter this time. I'd like to propose: simple majority (11) of initial PMC list constitutes approval to send resolutions to the Board. 48 hour time limit (+ a few to make it an even time), so vote ends at: 1700 Eastern Time, Friday, April 8, 2005. Any one of the initial PMC list that I haven't heard from at the half-way point gets ONE nag by email at their email address as in the resolution. The official wording of this ballot is: To approve sending the Resolutions, as posted by Remy Maucherat earlier today (specifically Message-Id: [EMAIL PROTECTED]), to the Board of Directors of the Apache Software Foundation. In case there's any doubt, my vote is +1. :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: VOTE on final TLP draft
Hi, That being the case, if there is nothing more to discuss over the set of Resolutions, should we just have the initial PMC members vote on it and send it to the Board for approval? This does not need to be a secret ballot since it's just pro/con, so we should be able to move quickly. I No, this is a vote that needs to take place on [EMAIL PROTECTED] (you're right that it needs not be secret), and is open to Jakarta [the current TLP] PMC members. The rest of the stuff (time, vote counting, etc.) is fine by me, no big deal anyways. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs/config http.xml ajp.xml
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 06, 2005 8:54 AM Subject: cvs commit: jakarta-tomcat-catalina/webapps/docs/config http.xml ajp.xml remm2005/04/06 08:54:05 Modified:webapps/docs/config http.xml ajp.xml Log: - Fix AJP documentation error about connection timeout (no timeout by default). snip/ +attribute name=connectionTimeout required=false + pThe number of milliseconds this strongConnector/strong will wait, + after accepting a connection, for the request URI line to be + presented. The default value is infinite (i.e. no timeout)./p +/attribute + Urm, in JkMain, it's still called 'soTimeout'. Not that I object to the name change, but currently setting 'connectionTimeout' on an AJP Connector won't do anything at all. 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 33711] - Memory leak (classloader) with Log4J and Single Sign On.
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=33711. 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=33711 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- 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/webapps/docs/config http.xml ajp.xml
Bill Barker wrote: remm2005/04/06 08:54:05 Modified:webapps/docs/config http.xml ajp.xml Log: - Fix AJP documentation error about connection timeout (no timeout by default). snip/ +attribute name=connectionTimeout required=false + pThe number of milliseconds this strongConnector/strong will wait, + after accepting a connection, for the request URI line to be + presented. The default value is infinite (i.e. no timeout)./p +/attribute + Urm, in JkMain, it's still called 'soTimeout'. Not that I object to the name change, but currently setting 'connectionTimeout' on an AJP Connector won't do anything at all. There's an alias for that in the Connector class. The (only) benefit is that it corresponds to the attribute name that was used in 5.0. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs/config http.xml ajp.xml
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Wednesday, April 06, 2005 2:01 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs/config http.xml ajp.xml Bill Barker wrote: remm2005/04/06 08:54:05 Modified:webapps/docs/config http.xml ajp.xml Log: - Fix AJP documentation error about connection timeout (no timeout by default). snip/ +attribute name=connectionTimeout required=false + pThe number of milliseconds this strongConnector/strong will wait, + after accepting a connection, for the request URI line to be + presented. The default value is infinite (i.e. no timeout)./p +/attribute + Urm, in JkMain, it's still called 'soTimeout'. Not that I object to the name change, but currently setting 'connectionTimeout' on an AJP Connector won't do anything at all. There's an alias for that in the Connector class. The (only) benefit is that it corresponds to the attribute name that was used in 5.0. So there is: An alias for another alias ;-). 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]
MAIL TRANSACTION FAILED
The message contains Unicode characters and has been sent as a binary attachment. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34339] New: - commons-modeler.jar file missing from admin package
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=34339. 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=34339 Summary: commons-modeler.jar file missing from admin package Product: Tomcat 5 Version: 5.5.7 Platform: PC OS/Version: Windows XP Status: NEW Severity: minor Priority: P3 Component: Webapps:Administration AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] After installing admin package (into CATALINA_HOME\webapps) and logging in to admin GUI, clicking on the tree control on left hand side for any item causes the following exception: message: description The server encountered an internal error () that prevented it from fulfilling this request. exception: javax.servlet.ServletException: Servlet execution threw an exception org.apache.webapp.admin.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:123) root cause: java.lang.NoClassDefFoundError: org/apache/commons/modeler/Registry org.apache.webapp.admin.ApplicationServlet.initServer(ApplicationServlet.java:154) org.apache.webapp.admin.ApplicationServlet.getServer(ApplicationServlet.java:93) org.apache.webapp.admin.resources.ListDataSourcesAction.execute(ListDataSourcesAction.java:90) org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1192) org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:412) javax.servlet.http.HttpServlet.service(HttpServlet.java:689) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.webapp.admin.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:123) Once the commons-modeler.jar file is inserted into CATALINA_HOME\webapps\admin\WEB-INF\lib, the problem is resolved and admin app works correctly. -- 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 34341] New: - SSI exec cmd= vis-à-vis Apache+Tomcat/mod_jk issue
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=34341. 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=34341 Summary: SSI exec cmd= vis-à-vis Apache+Tomcat/mod_jk issue Product: Tomcat 5 Version: 5.5.7 Platform: Sun OS/Version: Solaris Status: NEW Severity: major Priority: P1 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] [This is a duplicate of bug #34232 (http://issues.apache.org/bugzilla/show_bug.cgi?id=34232) which was marked as INVALID for httpd-2.0] Im working on porting some legacy code into Java, piecewise. The legacy code has a script (which I have to keep for now) that generates a header and footer separately for a page using SSIs for a given HTML page request, e.g., a page on the server would look like !--#exec cmd=/path/to/headerfooterscript --showheader-- (some HTML or other SSI directives here) !--#exec cmd=/path/to/headerfooterscript --showfooter-- Instead of HTML files now, I have JSPs. I have an Apache (2.0.53) installation handing off requests to a Tomcat (5.5.7) server via mod_jk (1.2.8). The output from those requests has the header/footer includes in it, after which Apache is configured to process the output for the SSIs (using SetOutputFilter INCLUDES in the configuration) and run those. Apache parses the output for SSIs but fails to run the headerfooterscript, returning this message in the log: (2)No such file or directory: change of working directory failed The directory exists, the script exists, its executable, the Apache user has permissions to run it, but I get this message. Doing a little debugging, I see that the value that Apache has for the working directory is empty. Now, one odd thing is that doing this works if I use #exec cgi or #include virtual commands in the JSP output instead of #exec cgi (using either of those is undesirable for other reasons right now), it works --- I get the output from a test script or file included in the output from the JSP. The other odd thing is that if I write a plain CGI script (Perl in this case) to return as output the header/footer includes using the #exec cmd syntax, it also works --- no (2)No such file or directory: change of working directory failed messages. Debugging shows that the value for the working directory is being set correctly for all the working cases. So it appears that it might be a bug vis-à-vis Apache and mod_jk (but I'm filing it under mod_include for the moment) in some fashion, either before the request is handed off, or after it comes back. I should note that the original issue was spotted under Solaris 8, but it also happens under Solaris 9. Also, I dont have any third-party modules compiled either. I havent tested Apache under Linux (wouldnt be the production environment anyway) to see if it also happens there. Additional notes: I just saw that mod_jk 1.2.10 is available and have not tried that yet to see if the problem is addressed; I have also not tried Tomcat 5.5.9 (wouldn't put that into production anyway). -- 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: How Tomcat validates web.xml
N G wrote: On Apr 6, 2005 10:31 AM, Jeanfrancois Arcand [EMAIL PROTECTED] wrote: Tomcat uses it's own local version. This way you can use Tomcat without being connected to the internet, or pay the price of connection over http everytime a war is deployed. And what's WAY more important: what does the servlet spec say about how a server should validate web.xml? See the Servlet Spec. SRV.13.2 Rules for Processing the Deployment Descriptor This section lists some general rules that Web containers and developers must note concerning the processing of the deployment descriptor for a Web application. · Web containers must remove all leading and trailing whitespace, which is de- fined as S(white space) in XML 1.0 (http://www.w3.org/TR/2000/WD-xml- 2e-2814), for the element content of the text nodes of a deployment de- scriptor. · The deployment descriptor must be valid against the schema. Web containers and tools that manipulate Web applications have a wide range of options for checking the validity of a WAR. This includes checking the validity of the de- ployment descriptor document held within. The containers and tools that are part of J2EE technology-compliant implementation are required to validate deployment descriptor against the XML schema for structural correctness. The validation is recommended, but not required for the web containers and tools that are not part of J2EE technology-compliant implementation. Yes, I saw this. However, what gives a PORTABLE application the right to specify a relative URL for the location of the Schema and not provide that schema there? I don't see anything in this paragraph that says this is allowed. Are you seeing something that says is not allowed ;-) SO, are you saying that even though Tomcat will accept whatever you put for the path to the Schema (since it uses its own copy), the app will not necessarily be portable to other servers since they might choose to actually pay attention to the schema location specified by web.xml? So, to guarantee that the app is 100% portable, you must specify: web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation= http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=2.4 Am I correct? We use SAX when parsing/validating the web.xml, and at the time we resolve the XML entity, we use the system ID to redirect the stream to our internal version. So if you don't have everything required in your web-app .. element, then it will fail because the parser (unfortunalty we use buggy Xerces ;-)) will not be able to create properly its schema table, unless you are connected to the internet and we are able to resolve the uri. So I don't see why your app deployed/validated in Tomcat will not be portable. Do you have a test case? Thanks -- Jeanfrancosi Thanks, NG. - 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: New TLP draft
Tim Funk wrote: Looks good. Just an idea, it may be nice to have the 3 new lists tomcat-bug - bug updates from bugzilla. When I subscribe to other groups tomcat-cvs - Same as tomcat-bug but just for cvs commits. tomcat-gump - For deaths by gump. If your not a committer - these are This has been debated many times :-), maybe this time it'll succeed. The typical argument for keeping it all in one place is that it may force people to read them instead of filtering the out with the mail app. It would be nice to split it - it'll be much easier to read tomcat-dev ( including in blogs.gmane.org ). Regarding CVS move - are we going to just change the name of the roots ( s/jakarta/apache/ ) or should we do a bit more reorg, to make it easier when we move to svn ? The current layout is based on a lot of 'historic' reasons that no longer apply. For 3.x and 4.x - of course it makes sense to just keep the trees as they are. Costin -Tim Remy Maucherat wrote: Hi, Here's a new draft with the necessary updates. I suppose this needs to be sent to the PMC for approval. If this draft is ok, I will send it there. Then there are infrastructure taks: - renaming mailing lists - moving CVS - new DNS and virtual host - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
