io.File relative path constructor
Hi, A should-be easy one - I do not wish to define an absolute path to a File as it will packaged in a JAR, therefore its path will change. How do I construct a File relative to my src root, something like File file = new File(/path/myFile.xml);? I tried passing in a URL, URI but am getting: Exception in thread main java.lang.IllegalArgumentException: URI is not hierarchical when I jar and run it. Am using Win XP + Java 1.5. Thanks Paul. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jasper TCKing
All, Not sure how to go about this, but I wanted to offer my services with TCK compliance testing of tomcat/jasper. I have been granted JSR 152 and 154 TCK karma for my own container (winstone), and I figured since TCK karma is so hard to get, you guys might appreciate having someone else who can share the responsibility for tomcat. Obviously there would be some working out of communication details because of TCK contract restrictions, but that shouldn't be hard. It's in my interest to help with compliance because Jasper is being used within Winstone - I've got it to pass all the JSR154 tests, but the 152 tests were failing in a few places ... I haven't been on this list for a while, so shoot me down if this is a known problem - I ran the JSP TCK over jasper + tomcat 5.5.9, and noticed that there were a few test failures when I ran it (four or so that I counted in the api section). The main reason was that under winstone I noticed the errors, so I tried running it against tomcat, and got the same errors. It's possible they've been excluded and I've misconfigured my test environment, so I well and truly leave open the possibility it's my fault - just wanted to check. Anyway, please let me know if the help is needed. Rick -- Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sourceforge.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36538] New: - (Apache 2.0.54) mod_jk 1.2.10 ignores -ForwardDirectories
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=36538. 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=36538 Summary: (Apache 2.0.54) mod_jk 1.2.10 ignores - ForwardDirectories Product: Tomcat 5 Version: 5.5.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Using Apache 2.0.54 / JK1.2.10 / Tomcat 5.5.9 -ForwardDirectories (defauted or explicitly coded) has no effects : all URIs that map to a directory are passed to and responded by tomcat, instead of Apache 1/ If no index.html, no index.jsp, and without 'Options Indexes' is present : Expected : 403 Forbidden returned by Apache Actually : Directory listing returned by Tomcat 2/ If no index.html, no index.jsp, but with 'Options Indexes' : Expected : Directory listing returned by Apache Actually : Directory listing returned by Tomcat Directives used --- DirectoryIndex index.html JkOptions -ForwardDirectories SetEnvIf Request_URI .htm$|\.html$|\.css$|\.js$|\.gif$|\.jpg$|\.jpeg$ no-jk VirtualHost *:* ... Alias /context-root /path/to/webapp/docs JkMount /context-root/* workerName /VirtualHost Aditionnal information -- I found a similar problem, reported in the bug 25104, for mod_jk 1.2.5 and Tomcat 4. It was not solved, because jk 1.2 was told to be deprecated. But it is actually not. -- 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 36525] - mod_jk 1.2.14.1 core dump
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=36525. 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=36525 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 11:25 --- I can confirm that I fully shut down Apache before installing the new mod_jk and starting Apache back up. Removing the mod_jk.shm after shutting down, installing the new module and starting back up doesn't make a difference. Using ipcs to view shared memory after Apache shutdown shows that Apache has correctly released the shared memory that was in use. Hope to try commenting out the lines in the next day or 2. -- 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 36534] - Context relative URLs returned by ServletContext.getResource() for the same path are not equal
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=36534. 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=36534 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 12:05 --- I will not be fixing that, as this changes the value of toString for the URL. -- 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: io.File relative path constructor
Paul, If the file is in a JAR you can generate a URL to access it. either something along the lines of ServletContext context = getServletConfig().getServletContext(); URL url = context.getResource(/path/file.xml); or alternatively using the class loader URL url = getClass().getResource(/path/file.xml); Best regards Robert -Original Message- From: Paul Wallace [mailto:[EMAIL PROTECTED] Sent: 07 September 2005 07:51 To: Tomcat Developers List Subject: io.File relative path constructor Hi, A should-be easy one - I do not wish to define an absolute path to a File as it will packaged in a JAR, therefore its path will change. How do I construct a File relative to my src root, something like File file = new File(/path/myFile.xml);? I tried passing in a URL, URI but am getting: Exception in thread main java.lang.IllegalArgumentException: URI is not hierarchical when I jar and run it. Am using Win XP + Java 1.5. Thanks Paul. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information contained in this message is intended only for the recipient, and may be a confidential attorney-client communication or may otherwise be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please be aware that any dissemination or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the message and deleting it from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 6648] - jakarta-servletapi build with java 1.4 javadoc errors
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=6648. 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=6648 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 12:29 --- Can you give some more info about it. 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]
DO NOT REPLY [Bug 36540] New: - pooled cluster replication does not seem ensure synchronized replication in tomcat 5.5.11
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=36540. 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=36540 Summary: pooled cluster replication does not seem ensure synchronized replication in tomcat 5.5.11 Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalina:Cluster AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] If I understand it correctly, the pooled replication should ensure the availability of the session on all cluster nodes as soon as the request is finished. It doesn't seem to do that with the following test-case: The attached simple webapp (clustertest.war) just prints the content of the session entry host and then stores its hostname in that entry. This webapp is installed on 2 tomcat 5.5.11's, tomcat1 and tomcat2, and mod_jk is used as a load balancer, sticky sessions are disabled. (Config files are attached). A JMeter 2.1 Test Plan is used to make requests. It repeatedly makes requests to the webapp, waiting 20ms between the requests. Expected behaviour: The first request yields null, and subsequent ones return tomcat1, then tomcat2, tomcat1, tomcat2 and so on. Actual behaviour: Several requests return null, and the rest is not exactly alternating. In this test case, it stabilized when waiting like 50ms between the requests, but on other webapps with larger sessions, it needed a lot more time. This is quite serious since correctness is not ensured when not using sticky sessions. -- 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 36540] - pooled cluster replication does not seem ensure synchronized replication in tomcat 5.5.11
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=36540. 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=36540 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 12:42 --- Created an attachment (id=16329) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16329action=view) the test case and config files -- 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 36541] New: - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 Summary: session getAttribute/setAttribute and removeAttribute are NOT Thread safe. Product: Tomcat 5 Version: 5.0.25 Platform: All OS/Version: All Status: NEW Severity: critical Priority: P1 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I'm not quite sure if it's a bug or spec flaw, but I talked to Craig McClanahan and he encouraged me to submit it. The session attribute handling methods in 5.0.x aren't thread safe. The org.apache.catalina.session.StandardSession and StadardSessionFacade do not synchronize in get/set/remove Attribute. The result is following: If you write and read from the session simultaneously with multiple threads the getter/setter methods corrupt the underlying HashMap. The HashMap's entries got circularly linked, and any thread using a get() on such a HashMap will spin forever chasing its tail (quoted from Larry Isaacs). Now what Josh Bloch and Co. are saying in the javadoc for HashMap: * pbNote that this implementation is not synchronized./b If multiple * threads access this map concurrently, and at least one of the threads * modifies the map structurally, it imust/i be synchronized externally. * (A structural modification is any operation that adds or deletes one or * more mappings; merely changing the value associated with a key that an * instance already contains is not a structural modification.) This is * typically accomplished by synchronizing on some object that naturally * encapsulates the map. If no such object exists, the map should be * wrapped using the ttCollections.synchronizedMap/tt method. This is * best done at creation time, to prevent accidental unsynchronized access to * the map: pre Map m = Collections.synchronizedMap(new HashMap(...)); * /pre The bug is quite easy to fix, by making the map synchronized (as stated above) or explicitely synchronize the places where HashMap.get() or put() is called. I could provide a patch if wished. -- 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 36540] - pooled cluster replication does not seem ensure synchronized replication in tomcat 5.5.11
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=36540. 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=36540 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 12:48 --- How about not filing a bug ? It should be evident sticky sessions are mandatory, or you're going to run into problems. -- 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 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |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 36542] New: - Cluster documentation implies sticky sessions are not mandatory
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=36542. 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=36542 Summary: Cluster documentation implies sticky sessions are not mandatory Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalina:Cluster AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Quote: Asynchronous replication, should be used if you have sticky sessions until fail over,... This implies that if you don't have sticky sessions (which isn't marked as mandatory) synchronous mode should be used and is supported. Please change the docs if you don't support non-sticky sessions. In that case, all but the fastasyncqueue mode are obsolete either. -- 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 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 13:12 --- And to prevent the REOPEN ... SRV.7.7.1 Threading Issues Multiple servlets executing request threads may have active access to a single session object at the same time. *The Developer has the responsibility for synchronizing access to session resources as appropriate.* -- 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 36542] - Cluster documentation implies sticky sessions are not mandatory
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=36542. 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=36542 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 13:21 --- They're not mandatory *sometimes*, depending on what your servlet does. It's really all simple logic. *** This bug has been marked as a duplicate of 36540 *** -- 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 36540] - pooled cluster replication does not seem ensure synchronized replication in tomcat 5.5.11
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=36540. 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=36540 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 13:21 --- *** Bug 36542 has been marked as a duplicate of this bug. *** -- 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 36542] - Cluster documentation implies sticky sessions are not mandatory
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=36542. 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=36542 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 13:27 --- (In reply to comment #1) They're not mandatory *sometimes*, depending on what your servlet does. It's really all simple logic. It's not that simple for me. As soon as you store stuff in the session, you need sticky sessions, because else subsequent requests may not get the most recent one. And if you don't need sessions, you obviousely don't need cluster session replication. So in which case are sticky sessions not mandatory? -- 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: Jasper TCKing
Rick, Thank you for the offer. It's certainly welcome. We have TCK grants for these APIs at Apache, and have had them for years. (In fact, the ASF has TCK rights from Sun for virtually every API out there ;)) But as you've noted, it's a time-consuming task, and in general we gladly welcome external help in all areas. Would it be possible for you to run the TCK occasionally (as your time permits, of course) on publicly-released Tomcat versions, and post the results either to this mailing list or as a Bugzilla issue for Tomcat? If not, we'll see what we can work out. There are some more private forums to which that information can go, but the public route is preferred, to help our users with their QA and due diligence tasks. Yoav --- Rick Knowles [EMAIL PROTECTED] wrote: All, Not sure how to go about this, but I wanted to offer my services with TCK compliance testing of tomcat/jasper. I have been granted JSR 152 and 154 TCK karma for my own container (winstone), and I figured since TCK karma is so hard to get, you guys might appreciate having someone else who can share the responsibility for tomcat. Obviously there would be some working out of communication details because of TCK contract restrictions, but that shouldn't be hard. It's in my interest to help with compliance because Jasper is being used within Winstone - I've got it to pass all the JSR154 tests, but the 152 tests were failing in a few places ... I haven't been on this list for a while, so shoot me down if this is a known problem - I ran the JSP TCK over jasper + tomcat 5.5.9, and noticed that there were a few test failures when I ran it (four or so that I counted in the api section). The main reason was that under winstone I noticed the errors, so I tried running it against tomcat, and got the same errors. It's possible they've been excluded and I've misconfigured my test environment, so I well and truly leave open the possibility it's my fault - just wanted to check. Anyway, please let me know if the help is needed. Rick -- Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sourceforge.net/) - 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]
svn commit: r279315 - in /tomcat/site/trunk: build.xml docs/download.cgi docs/download.html docs/lists.html xdocs/download.cgi xdocs/download.xml xdocs/lists.xml xdocs/robots.txt xdocs/stylesheets/project.xml
Author: remm
Date: Wed Sep 7 05:53:20 2005
New Revision: 279315
URL: http://svn.apache.org/viewcvs?rev=279315view=rev
Log:
- Add placeholder downloads and lists pages.
- These use *likely* locations for all links, in particular file names and
mailing lists names.
Added:
tomcat/site/trunk/docs/download.cgi
tomcat/site/trunk/docs/download.html
tomcat/site/trunk/docs/lists.html
tomcat/site/trunk/xdocs/download.cgi
tomcat/site/trunk/xdocs/download.xml
tomcat/site/trunk/xdocs/lists.xml
tomcat/site/trunk/xdocs/robots.txt
Modified:
tomcat/site/trunk/build.xml
tomcat/site/trunk/xdocs/stylesheets/project.xml
Modified: tomcat/site/trunk/build.xml
URL:
http://svn.apache.org/viewcvs/tomcat/site/trunk/build.xml?rev=279315r1=279314r2=279315view=diff
==
--- tomcat/site/trunk/build.xml (original)
+++ tomcat/site/trunk/build.xml Wed Sep 7 05:53:20 2005
@@ -58,10 +58,11 @@
/fileset
/copy
-!-- Copy CSS stylesheets --
+!-- Copy CSS stylesheets and download CGI --
copytodir=${docs.dest} filtering=no
fileset dir=${docs.src}
include name=**/*.css/
+include name=download.cgi/
/fileset
/copy
Added: tomcat/site/trunk/docs/download.cgi
URL:
http://svn.apache.org/viewcvs/tomcat/site/trunk/docs/download.cgi?rev=279315view=auto
==
--- tomcat/site/trunk/docs/download.cgi (added)
+++ tomcat/site/trunk/docs/download.cgi Wed Sep 7 05:53:20 2005
@@ -0,0 +1,6 @@
+#!/bin/sh
+# Wrapper script around mirrors.cgi script
+# (we must change to that directory in order for python to pick up the
+# python includes correctly)
+cd /www/www.apache.org/dyn/mirrors
+/www/www.apache.org/dyn/mirrors/mirrors.cgi $*
Added: tomcat/site/trunk/docs/download.html
URL:
http://svn.apache.org/viewcvs/tomcat/site/trunk/docs/download.html?rev=279315view=auto
==
--- tomcat/site/trunk/docs/download.html (added)
+++ tomcat/site/trunk/docs/download.html Wed Sep 7 05:53:20 2005
@@ -0,0 +1,534 @@
+?xml version=1.0 encoding=iso-8859-1?
+!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
+html
+head
+titleThe Jakarta Site - Download/title
+meta value=HTTPD Documentation Group name=author /
+meta value= name=email /
+/head
+body vlink=#525D76 alink=#525D76 link=#525D76 text=#00
bgcolor=#ff
+table cellspacing=0 width=100% border=0
+!--PAGE HEADER--
+tr
+td colspan=2
+!--JAKARTA LOGO--
+a href=http://jakarta.apache.org/;
+img border=0 alt=The Jakarta Project align=left
src=http://jakarta.apache.org/images/jakarta-logo.gif; /
+/a
+!--PROJECT LOGO--
+a href=http://jakarta.apache.org/tomcat/;
+img border=0 alt=The Apache Tomcat Project align=right
src=./images/tomcat.gif /
+/a
+/td
+/tr
+/table
+table cellspacing=4 width=100% border=0
+!--HEADER SEPARATOR--
+tr
+td colspan=2
+hr size=1 noshade= /
+/td
+/tr
+tr
+!--LEFT SIDE NAVIGATION--
+td nowrap=true valign=top width=20%
+p
+strongApache Tomcat/strong
+/p
+ul
+li
+a href=./index.htmlHome/a
+/li
+li
+a href=./bugreport.htmlBug Database/a
+/li
+li
+a href=./resources.htmlResources/a
+/li
+li
+a href=./irc.htmlIRC/a
+/li
+li
+a href=./faq/FAQ/a
+/li
+/ul
+p
+strongDocumentation/strong
+/p
+ul
+li
+a href=./tomcat-5.5-doc/index.htmlApache Tomcat 5.5/a
+/li
+li
+a href=./tomcat-5.0-doc/index.htmlApache Tomcat 5.0/a
+/li
+li
+a href=./tomcat-4.1-doc/index.htmlApache Tomcat 4.1/a
+/li
+li
+a href=./tomcat-3.3-doc/index.htmlApache Tomcat 3.3/a
+/li
+/ul
+p
+strongDownload/strong
+/p
+ul
+li
+a
href=http://jakarta.apache.org/site/downloads/downloads_tomcat-5.cgi;Current
Releases/a
+/li
+li
+a
href=http://jakarta.apache.org/site/downloads/downloads_tomcat-5.cgi;Apache
Tomcat 5.x/a
+/li
+li
+a
href=http://jakarta.apache.org/site/downloads/downloads_tomcat-4.cgi;Apache
Tomcat 4.x/a
+/li
+li
+a
href=http://jakarta.apache.org/site/downloads/downloads_tomcat-3.cgi;Apache
Tomcat 3.x/a
+/li
+/ul
+p
+strongArchives/strong
+/p
+ul
+li
+a href=./tomcat-4.0-doc/index.htmlApache Tomcat 4.0/a
+/li
+li
+a href=./tomcat-3.2-doc/index.htmlApache Tomcat 3.2/a
+/li
+/ul
+p
+strongJakarta/strong
+/p
+ul
+li
+a href=./../index.htmlFront Page/a
+/li
+li
+a href=http://jakarta.apache.org/site/news.html;News amp; Status/a
+/li
+li
+a href=http://jakarta.apache.org/site/mission.html;Mission/a
+/li
+li
+a href=http://jakarta.apache.org/site/guidelines.html;Guidelines Notes/a
+/li
+li
+a href=http://jakarta.apache.org/site/faqs.html;FAQs/a
+/li
+/ul
+p
+strongGet Involved/strong
+/p
+ul
+li
+a href=http://jakarta.apache.org/site/getinvolved.html;Overview/a
+/li
+li
Re: Jasper TCKing
Yoav, Thank you for the offer. It's certainly welcome. We have TCK grants for these APIs at Apache, and have had them for years. (In fact, the ASF has TCK rights from Sun for virtually every API out there ;)) But as you've noted, it's a time-consuming task, and in general we gladly welcome external help in all areas. Yes - I noticed the Apache Watchdog project heritage. Couldn't help but laugh that Sun are charging for the same tests now (for commercial vendors anyway) ... The main thing I wanted to offer was to help with running it before releases (which I think is part of the contract), and my understanding is that only the individuals within the project that sign their lives away to Sun are allowed access to the TCK, which I would guess isn't everyone on the tomcat-dev team. Would it be possible for you to run the TCK occasionally (as your time permits, of course) on publicly-released Tomcat versions, and post the results either to this mailing list or as a Bugzilla issue for Tomcat? If not, we'll see what we can work out. There are some more private forums to which that information can go, but the public route is preferred, to help our users with their QA and due diligence tasks. OK - no problem. Is it okay to post the results of TCK tests publicly though ? I thought that wasn't allowed by the contract. I guess it should be okay if I just publish the test groups and indexes that fail. The tests that failed were: jsp/api/javax_servlet/jsp/pagecontext: tests 15,28,30 jsp/api/javax_servlet/jsp/tagext/simpletagsupport: test 7 jsp/spec/core_syntax/actions/invoke: test 7 jsp/spec/core_syntax/implicitobjects: test 3 jsp/spec/tagfiles/semantics: tests 1,2,3,4 Note this is 5.5.9, so possibly already fixed. Rick -- Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sourceforge.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 15:21 --- Sorry, but this means that the develop is responsible for the object he puts in session, not for the session itself. To quote Graig: the underlying spec language (SRV.7.7.1) was originally intended to remind application users that they must make their *own* objects threadsafe if they are stored as a session attribute. To use that language as an excuse for the *container* not having to make its own collections threadsafe means that the language is broken. So, reopen it now? -- 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 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 15:39 --- (In reply to comment #2) Sorry, but this means that the develop is responsible for the object he puts in session, not for the session itself. To quote Graig: the underlying spec language (SRV.7.7.1) was originally intended to remind application users that they must make their *own* objects threadsafe if they are stored as a session attribute. To use that language as an excuse for the *container* not having to make its own collections threadsafe means that the language is broken. So, reopen it now? Don't bother ;) -- 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 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 15:45 --- (In reply to comment #2) Heheh ... I think you answered the question for yourself ... fix the spec first, then the container implementations second. -- 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 36546] New: - AJP returns pages with text/plain content type
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=36546. 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=36546 Summary: AJP returns pages with text/plain content type Product: Tomcat 4 Version: 4.1.31 Platform: Other OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: Connector:JK/AJP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] If I'm trying to get the page directly from Tomcat, the content-type is set to text/html. But after I connected the application to the Apache 1.3 with mod_jk (1.2.14.1) all pages from the resources mapped by JkMount are returning with the content-type text/plain. Is there a way to fix that? -- 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 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 16:34 --- (In reply to comment #4) (In reply to comment #2) Heheh ... I think you answered the question for yourself ... fix the spec first, then the container implementations second. Interesting, servlet spec 2.3 has exact the same wording of SRV.7.7.1 Threading Issues and tomcat 4.1.31, which is the official implementation of the 2.3 spec, has a SYNCHRONIZED session. So tomcat 4.x is buggy, or tomcat 5.x is. You say it's the 4.x, I say it's 5.x. -- 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 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 16:47 --- (In reply to comment #5) Actually I'd say neither is buggy, since they both implement the spec as it's written. If that's not what was intended, then as you quoted Craig saying: the language is broken, and the spec needs to be changed. -- 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 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 18:08 --- (In reply to comment #6) (In reply to comment #5) Actually I'd say neither is buggy, since they both implement the spec as it's written. If that's not what was intended, then as you quoted Craig saying: the language is broken, and the spec needs to be changed. I would agree that neither implementation is buggy -- it is entirely legal for a servlet container to avoid letting an application corrupt its interna data structures. It's too bad that the current Tomcat developers care more about performance than they care about reliability. If you aren't going to change it back to the 4.1 implementation (with synchronization locks around the accesses), please take my name out of the @author tag for org.apache.catalina.session.StandardSession -- this code does *not* represent anything I wish to be associated with. -- 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 36548] New: - First undeploy doesn't work
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=36548. 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=36548 Summary: First undeploy doesn't work Product: Tomcat 5 Version: 5.5.9 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] When Tomcat still has a webapps deployed after startup, the first un-deployement of this webapps doesn't work. Only the file web.xml is removed, so tomcat tries to redeploy it and it crashes. If we deploy the webapps a second times (or a 3rd, etc.) it works fine. So it's only the first undeployement. To reproduce : start tomcat deploy the webapp stop tomcat start tomcat undeploy the webapp It works both with ant tasks and with the tomcat manager. -- 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 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 18:45 --- (In reply to comment #7) I would agree that neither implementation is buggy -- it is entirely legal for a servlet container to avoid letting an application corrupt its interna data structures. It's too bad that the current Tomcat developers care more about performance than they care about reliability. Of course. Thankfully, you guys have glassfish now for good reliability, so you don't have to deal with these loony Tomcat developers anymore ;) If you aren't going to change it back to the 4.1 implementation (with synchronization locks around the accesses), please take my name out of the @author tag for org.apache.catalina.session.StandardSession -- this code does *not* represent anything I wish to be associated with. Sure, I have no problem with that if it's your wish. These changes were made as an experiment (the spec allows this to be non-synced), and included in 5.0.19+ and as a consequence in all the most popular 5.0.x releases. In the end, it would seem it worked reasonably well. However, I did get a few reports of corruption a while after this, and I added back synchrnozation on write operations to the map in the 5.5 branch. I never ported this back to 5.0.x given the lack of demand. Apparently, you didn't look at it. All that got discussed in the past, including the readding of some of the syncs. -- 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 36534] - Context relative URLs returned by ServletContext.getResource() for the same path are not equal
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=36534.
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=36534
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFIX |
--- Additional Comments From [EMAIL PROTECTED] 2005-09-07 19:47 ---
Good point about toString(). I have a solution for that as well. Just override
org.apache.naming.resources.DirContextURLStreamHandler.toExternalForm() and have
it ignore the authority part of the URL, as follows (this is copied from
java.net.URLStreamHandler.toExternalForm(), with authority part ignored):
/**
* Converts a codeURL/code of a specific protocol to a
* codeString/code.
*
* @param u the URL.
* @return a string representation of the codeURL/code argument.
*/
protected String toExternalForm(URL u) {
// pre-compute length of StringBuffer
int len = u.getProtocol().length() + 1;
if (u.getPath() != null) {
len += u.getPath().length();
}
if (u.getQuery() != null) {
len += 1 + u.getQuery().length();
}
if (u.getRef() != null)
len += 1 + u.getRef().length();
StringBuffer result = new StringBuffer(len);
result.append(u.getProtocol());
result.append(:);
if (u.getPath() != null) {
result.append(u.getPath());
}
if (u.getQuery() != null) {
result.append('?');
result.append(u.getQuery());
}
if (u.getRef() != null) {
result.append(#);
result.append(u.getRef());
}
return result.toString();
}
It is important that URLs returned by ServletContext.getResource() that are
equal have equals() return TRUE. This works for all other kinds of URLs.
--
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 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
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=35461. 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=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 20:18 --- I am getting the exact same problem. When will this be fixed? Is there a new release slated soon? -- 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 36102] - jk 1.2.14 - Worker actions do not persist
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=36102. 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=36102 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Component|Connector:Other |Connector:AJP Priority|P4 |P3 Product|Tomcat 4|Tomcat 5 Resolution|REMIND | Version|4.1.27 |5.5.9 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 20:24 --- Symptoms recreated in Tomcat 5.5.9 -- 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: [ANN] Servlet and JSP APIs have moved to subversion
Remy Maucherat wrote: Mark Thomas wrote: The following CVS modules have been migrated to subversion jakarta-servletapi jakarta-servletapi-4 jakarta-servletapi-5 It seems to work well ! Good. What's the next step ? TC3 TC4. I looked into the website work, and I think it should be enough to simply add a page for mailing lists and downloads (for starters, other pages can be added as needed). For the latter, what are the preferences ? One like jakarta.apache.org, or a much simpler one like httpd.apache.org ? Keeping it simple is good (like httpd). I started to edit the project.xml file and was thinking along the following lines: Apache Tomcat * Home Download * Which version? * Apache Tomcat 5.5 * Apache Tomcat 5.0 * Apache Tomcat 4.1 * Apache Tomcat 3.3 * Archives Problems? * Find help * FAQ * Mailing Lists * Bug Database * IRC Documentation * Apache Tomcat 5.5 * Apache Tomcat 5.0 * Apache Tomcat 4.1 * Apache Tomcat 3.3 * Archives Get Involved * Overview * SVN Repositories * Mailing Lists Misc * Who We Are * Heritage * Apache Home * Resources * Acknowledgements * Contact * Legal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36549] New: - Tomcat Stopped with HotSpot libjvm error
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=36549. 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=36549 Summary: Tomcat Stopped with HotSpot libjvm error Product: Tomcat 5 Version: 5.5.9 Platform: Sun OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] We are running Tomcat 5.5.9 on Sun Solaris 9 64bit We have Apache Axis running a Java webservice which makes a JNI call into C code... Pretty straight forward - right! But unexplained Tomcat stops responding Java version reports - java version 1.5.0_04 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05) Java HotSpot(TM) Server VM (build 1.5.0_04-b05, mixed mode) - Catalina.out shows - Sep 7, 2005 10:42:08 AM org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource Sep 7, 2005 10:42:09 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 6449 ms - Unable to find config file. Creating new servlet engine config file: /WEB- INF /server-config.wsdd # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xfe9bac34, pid=8093, tid=39 # # Java VM: Java HotSpot(TM) Server VM (1.5.0_04-b05 mixed mode) # Problematic frame: # V [libjvm.so+0x1bac34] # # An error report file with more information is saved as hs_err_pid8093.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # - And then it doesn't respond on 8080 any more... I noticed around this time that the catalina log file showed a - Sep 7, 2005 10:41:47 AM org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 Sep 7, 2005 10:41:47 AM org.apache.jk.common.ChannelSocket acceptConnections WARNING: Exception executing accept java.net.SocketException: Invalid argument at java.net.PlainSocketImpl.socketSetOption(Native Method) at java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:264) at java.net.Socket.setSoLinger(Socket.java:869) at org.apache.jk.common.ChannelSocket.accept(ChannelSocket.java:300) at org.apache.jk.common.ChannelSocket.acceptConnections (ChannelSocket.ja va:641) at org.apache.jk.common.SocketAcceptor.runIt(ChannelSocket.java:852) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadP ool.java:684) at java.lang.Thread.run(Thread.java:595) Sep 7, 2005 10:41:48 AM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina - Am I missing something here? -- 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: DO NOT REPLY [Bug 36534] - Context relative URLs returned by ServletContext.getResource() for the same path are not equal
[EMAIL PROTECTED] wrote:
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=36534.
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=36534
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFIX |
--- Additional Comments From [EMAIL PROTECTED] 2005-09-07 19:47 ---
Good point about toString(). I have a solution for that as well. Just override
org.apache.naming.resources.DirContextURLStreamHandler.toExternalForm() and have
it ignore the authority part of the URL, as follows (this is copied from
java.net.URLStreamHandler.toExternalForm(), with authority part ignored):
/**
* Converts a codeURL/code of a specific protocol to a
* codeString/code.
*
* @param u the URL.
* @return a string representation of the codeURL/code argument.
*/
protected String toExternalForm(URL u) {
// pre-compute length of StringBuffer
int len = u.getProtocol().length() + 1;
if (u.getPath() != null) {
len += u.getPath().length();
}
if (u.getQuery() != null) {
len += 1 + u.getQuery().length();
}
if (u.getRef() != null)
len += 1 + u.getRef().length();
StringBuffer result = new StringBuffer(len);
result.append(u.getProtocol());
result.append(:);
if (u.getPath() != null) {
result.append(u.getPath());
}
if (u.getQuery() != null) {
result.append('?');
result.append(u.getQuery());
}
if (u.getRef() != null) {
result.append(#);
result.append(u.getRef());
}
return result.toString();
}
It is important that URLs returned by ServletContext.getResource() that are
equal have equals() return TRUE. This works for all other kinds of URLs.
I hadn't noticed you were the one who filed the bug. Besides skipping
the result.append(:);, you should simply apply the fix, it's a very
good solution.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36550] New: - Tomcat Stopped with HotSpot libjvm error
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=36550. 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=36550 Summary: Tomcat Stopped with HotSpot libjvm error Product: Tomcat 5 Version: 5.5.9 Platform: Sun OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] We are running Tomcat 5.5.9 on Sun Solaris 9 64bit We have Apache Axis running a Java webservice which makes a JNI call into C code... Pretty straight forward - right! But unexplained Tomcat stops responding Java version reports - java version 1.5.0_04 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05) Java HotSpot(TM) Server VM (build 1.5.0_04-b05, mixed mode) - Catalina.out shows - Sep 7, 2005 10:42:08 AM org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource Sep 7, 2005 10:42:09 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 6449 ms - Unable to find config file. Creating new servlet engine config file: /WEB- INF /server-config.wsdd # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xfe9bac34, pid=8093, tid=39 # # Java VM: Java HotSpot(TM) Server VM (1.5.0_04-b05 mixed mode) # Problematic frame: # V [libjvm.so+0x1bac34] # # An error report file with more information is saved as hs_err_pid8093.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # - And then it doesn't respond on 8080 any more... I noticed around this time that the catalina log file showed a - Sep 7, 2005 10:41:47 AM org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 Sep 7, 2005 10:41:47 AM org.apache.jk.common.ChannelSocket acceptConnections WARNING: Exception executing accept java.net.SocketException: Invalid argument at java.net.PlainSocketImpl.socketSetOption(Native Method) at java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:264) at java.net.Socket.setSoLinger(Socket.java:869) at org.apache.jk.common.ChannelSocket.accept(ChannelSocket.java:300) at org.apache.jk.common.ChannelSocket.acceptConnections (ChannelSocket.ja va:641) at org.apache.jk.common.SocketAcceptor.runIt(ChannelSocket.java:852) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadP ool.java:684) at java.lang.Thread.run(Thread.java:595) Sep 7, 2005 10:41:48 AM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina - Am I missing something here? -- 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 36550] - Tomcat Stopped with HotSpot libjvm error
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=36550. 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=36550 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 20:53 --- *** This bug has been marked as a duplicate of 36549 *** -- 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 36549] - Tomcat Stopped with HotSpot libjvm error
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=36549. 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=36549 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 20:53 --- *** Bug 36550 has been marked as a duplicate of this bug. *** -- 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 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 21:29 --- After we finish clarifying who's is bigger (and mine is best case average), we could return to the bug. 1. The bug isn't invalid, so I reopen it. You can set it to WONTFIX, but not to INVALID. 2. Applications working well with tomcat 4, resin or probably any other servlet container do not work with tomcat 5.0.x or tomcat 5.5.x. Thus tomcat 5 seems to be not compatible to the servlet spec (or be the only one compatible), if not in the language of the specification itself, but in the intension of it. So tomcat 5 can be considered BROKEN. 3. The bug applies to tomcat 5.5.x as well, because ... added back synchrnozation on write operations to the map in the 5.5 branch... doesn't fix anything, since the read operation are the problem and MUST be synchronized. 4. The effort to provide a workaround for this problem is enormous compared to the effort to fix the bug. Each and every framework around there now MUST provide two versions, the normal version and the tomcat 5 compatible version. You can't use struts, tapestry, jstl, actually NOTHING existing with tomcat 5. 5. The idea of removing synchronization to gain performance is absurd. Who needs the performance? People like us, who have 2000-3000 concurrent users on each webserver. But people who have 2000-3000 concurrent users, have also many concurrent requests, even from the same user, so instead of gaining performance we are gaining CRASHES. This bug killed 8 (!!!) webservers yesterday. 6. Consider the flurry in the tomcat users community, if the above points + your refusal to provide a three LOCs fix gonna make tomcat 5 UNUSEABLE. -- 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 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 21:41 --- Look, the basic problem is that the underlying implementation used to support attribute holders is being used in error according to it's documentation (java.util.HashMap documentation). It doesn't just leave the data in an inconstistent state, but rather crashes systems. If the developer has to synchronize access to the session or application or context every where attributes are being set then why not change the base application (Tomcat) to do this alreadybasically the application, context, and session are useless if nothing can be stored in them. So, they have to be synchronized anyways, so this should be done at the Tomcat level. 5.5.x and 5.0.x really need to be fixed because it doesn't make sense not to. Basically I'm getting this from the conversation (and anyone else should be).the spec says it's up to the developer to synchronizethe developer has to synchronize every where the attributes are set and get.so what is the difference if Tomcat does it or the developer does it? Plus, does the spec also say it's up to the developer to synchronize request, context, and session attributes? It's been a while since I have read the servlet spec, but I have the 2.3 version on disk and will skim over it again, but even if the spec says itit doesn't make sense not to synchronize code that has to be synchronized one way or another anyways. -- 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 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 21:58 --- Something I'm curious about. If EL is used on in a JSP and a session object accessed and manipulated is this synchronized? What package should I look in for that to check? -- 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 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 [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]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 22:08 --- So I verified that at least the 5.5.9 code only synchronized the setAttribute and not also the getAttributewhy? -- 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 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 22:22 --- (In reply to comment #12) So I verified that at least the 5.5.9 code only synchronized the setAttribute and not also the getAttributewhy? to quote Remy Maucherat: it was an experiment and he added back synchrnozation on write operations to the map in the 5.5 branch... Actually it doesn't make any sense because you need both get and set to be synchronized, to have the desired effect, so I think we should consider this a part of the experiment. -- 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 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 22:40 --- Well at least ApplicationContext.java and ApplicationRequest.java are synchronizing their attributes in both cases put/get. So, that is one thing not to worry about, but there are other issues, and I'm betting the EL accessing code isn't synchronizing because looking at the code for jasper2 and looking at the runtime file PageContextImpl.java in the scoped getAttribute which calls the scoped doGetAttribute it does not synchronize the code either. So, basically what that says is if a JSP developer were to use jsp:useBean and creates a session bean then there are going to be problems because as soon as this happens an unsynchronized call is taking place. Thing that makes this debate over whether to change it or not silly is that in the scoped calls the application and request code is already synchronized at the class level so synchronizing only on the session at this point seems weird. Regardlessif this tiny three line change doesn't take place then there are more lines in Tomcat that apparently need to be changed, because this bug causes other issues. -- 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 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 23:23 --- Why not keep everybody happy, simply make the session management class a configurable option at both Server and Context level, if the TC developers wish to experiment they can configure the un-synchronized access they so desire. -- 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]
svn commit: r279435 - in /tomcat/site/trunk: build.xml xdocs/articles/ xdocs/articles/benchmark_summary.pdf xdocs/articles/performance.pdf
Author: markt
Date: Wed Sep 7 15:07:26 2005
New Revision: 279435
URL: http://svn.apache.org/viewcvs?rev=279435view=rev
Log:
Configure build so entire docs dir is generated from xdocs dir and build script
Added:
tomcat/site/trunk/xdocs/articles/
tomcat/site/trunk/xdocs/articles/benchmark_summary.pdf (with props)
tomcat/site/trunk/xdocs/articles/performance.pdf (with props)
Modified:
tomcat/site/trunk/build.xml
Modified: tomcat/site/trunk/build.xml
URL:
http://svn.apache.org/viewcvs/tomcat/site/trunk/build.xml?rev=279435r1=279434r2=279435view=diff
==
--- tomcat/site/trunk/build.xml (original)
+++ tomcat/site/trunk/build.xml Wed Sep 7 15:07:26 2005
@@ -58,13 +58,21 @@
/fileset
/copy
+!-- Copy static PDFs --
+copytodir=${docs.dest} filtering=no
+fileset dir=${docs.src}
+include name=**/*.pdf/
+/fileset
+/copy
+
!-- Copy CSS stylesheets and download CGI --
copytodir=${docs.dest} filtering=no
fileset dir=${docs.src}
include name=**/*.css/
-include name=download.cgi/
+include name=**/*.cgi/
/fileset
/copy
+
/target
Added: tomcat/site/trunk/xdocs/articles/benchmark_summary.pdf
URL:
http://svn.apache.org/viewcvs/tomcat/site/trunk/xdocs/articles/benchmark_summary.pdf?rev=279435view=auto
==
Binary file - no diff available.
Propchange: tomcat/site/trunk/xdocs/articles/benchmark_summary.pdf
--
svn:mime-type = application/octet-stream
Added: tomcat/site/trunk/xdocs/articles/performance.pdf
URL:
http://svn.apache.org/viewcvs/tomcat/site/trunk/xdocs/articles/performance.pdf?rev=279435view=auto
==
Binary file - no diff available.
Propchange: tomcat/site/trunk/xdocs/articles/performance.pdf
--
svn:mime-type = application/octet-stream
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r279437 [2/2] - /tomcat/site/trunk/docs/
Modified: tomcat/site/trunk/docs/index.html URL: http://svn.apache.org/viewcvs/tomcat/site/trunk/docs/index.html?rev=279437r1=279436r2=279437view=diff == --- tomcat/site/trunk/docs/index.html (original) +++ tomcat/site/trunk/docs/index.html Wed Sep 7 15:13:19 2005 @@ -2,7 +2,7 @@ !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; html head -titleThe Jakarta Site - Apache Tomcat/title +titleApache Tomcat - Apache Tomcat/title meta value=Marc A. Saegesser name=author / meta value=[EMAIL PROTECTED] name=email / meta value=Yoav Shapira name=author / @@ -12,14 +12,21 @@ table cellspacing=0 width=100% border=0 !--PAGE HEADER-- tr -td colspan=2 -!--JAKARTA LOGO-- -a href=http://jakarta.apache.org/; -img border=0 alt=The Jakarta Project align=left src=http://jakarta.apache.org/images/jakarta-logo.gif; / -/a +td !--PROJECT LOGO-- -a href=http://jakarta.apache.org/tomcat/; -img border=0 alt=The Apache Tomcat Project align=right src=./images/tomcat.gif / +a href=http://tomcat.apache.org/; +img border=0 alt=Tomcat Logo align=left src=./images/tomcat.gif / +/a +/td +td +font face=arial,helvetica,sanserif +h1Apache Tomcat/h1 +/font +/td +td +!--APACHE LOGO-- +a href=http://www.apache.org/; +img border=0 alt=Apache Logo align=right src=http://www.apache.org/images/asf-logo.gif; / /a /td /tr @@ -41,82 +48,59 @@ li a href=./index.htmlHome/a /li -li -a href=./bugreport.htmlBug Database/a -/li -li -a href=./resources.htmlResources/a -/li -li -a href=./irc.htmlIRC/a -/li -li -a href=./faq/FAQ/a -/li /ul p -strongDocumentation/strong +strongDownload/strong /p ul li -a href=./tomcat-5.5-doc/index.htmlApache Tomcat 5.5/a +a href=./whichversion.htmlWhich version?/a /li li -a href=./tomcat-5.0-doc/index.htmlApache Tomcat 5.0/a +a href=./download-55.cgiApache Tomcat 5.5/a /li li -a href=./tomcat-4.1-doc/index.htmlApache Tomcat 4.1/a +a href=./download-41.cgiApache Tomcat 4.1/a /li li -a href=./tomcat-3.3-doc/index.htmlApache Tomcat 3.3/a +a href=./download-33.cgiApache Tomcat 3.3/a +/li +li +a href=http://archive.apache.org/dist/;Archives/a /li /ul p -strongDownload/strong +strongProblems?/strong /p ul li -a href=http://jakarta.apache.org/site/downloads/downloads_tomcat-5.cgi;Current Releases/a -/li -li -a href=http://jakarta.apache.org/site/downloads/downloads_tomcat-5.cgi;Apache Tomcat 5.x/a +a href=./findhelp.htmlFind help/a /li li -a href=http://jakarta.apache.org/site/downloads/downloads_tomcat-4.cgi;Apache Tomcat 4.x/a +a href=./faq/FAQ/a /li li -a href=http://jakarta.apache.org/site/downloads/downloads_tomcat-3.cgi;Apache Tomcat 3.x/a +a href=./mail.htmlMailing Lists/a /li -/ul -p -strongArchives/strong -/p -ul li -a href=./tomcat-4.0-doc/index.htmlApache Tomcat 4.0/a +a href=./bugreport.htmlBug Database/a /li li -a href=./tomcat-3.2-doc/index.htmlApache Tomcat 3.2/a +a href=./irc.htmlIRC/a /li /ul p -strongJakarta/strong +strongDocumentation/strong /p ul li -a href=./../index.htmlFront Page/a -/li -li -a href=http://jakarta.apache.org/site/news.html;News amp; Status/a -/li -li -a href=http://jakarta.apache.org/site/mission.html;Mission/a +a href=./tomcat-5.5-doc/index.htmlApache Tomcat 5.5/a /li li -a href=http://jakarta.apache.org/site/guidelines.html;Guidelines Notes/a +a href=./tomcat-4.1-doc/index.htmlApache Tomcat 4.1/a /li li -a href=http://jakarta.apache.org/site/faqs.html;FAQs/a +a href=./tomcat-3.3-doc/index.htmlApache Tomcat 3.3/a /li /ul p @@ -124,16 +108,13 @@ /p ul li -a href=http://jakarta.apache.org/site/getinvolved.html;Overview/a -/li -li -a href=http://jakarta.apache.org/site/cvsindex.html;CVS Repositories/a +a href=./getinvolved.htmlOverview/a /li li -a href=http://jakarta.apache.org/site/mail.html;Mailing Lists/a +a href=./svnindex.htmlSVN Repositories/a /li li -a href=http://jakarta.apache.org/site/library.html;Reference Library/a +a href=./lists.htmlMailing Lists/a /li /ul p @@ -141,16 +122,22 @@ /p ul li -a href=http://jakarta.apache.org/site/whoweare.html;Who We Are/a +a href=./whoweare.htmlWho We Are/a +/li +li +a href=./heritage.htmlHeritage/a /li li -a href=http://jakarta.apache.org/site/acknowledgements.html;Acknowledgements/a +a href=http://www.apache.org;Apache Home/a /li li -a href=http://jakarta.apache.org/site/contact.html;Contact/a +a href=./resources.htmlResources/a +/li +li +a href=./contact.htmlContact/a /li li -a href=http://jakarta.apache.org/site/legal.html;Legal/a +a href=./legal.htmlLegal/a /li /ul /td @@ -256,9 +243,8 @@ /table -pThe releases are described in more detail below to help you determine -which one is right for you. More details about each release can be found in -the associated release notes./p +pTo help you determine which release is right for you, the +a href=whichversion.htmlreleases are described in more detail/a./p pPlease note that
Re: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
[EMAIL PROTECTED] wrote: 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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 23:43 --- I strongly agree with Craig, et al to error on the side of a more robust implemention by using synchronization on the side of Tomcat. I think doing otherwise would be doing a high-wire act without a net. There are too many places for a developer to miss handling the threading correctly to leave this as is. Somehow, I cannot access bugzilla right now. DNS failure or something. Can someone close this as invalid and end this pointless debate ? Otherwise, I'll do it first thing when I have access :) Thanks, Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Draft TLP site
I have made a checkout of tomcat/site/trunk available at http://www.apache.org/~markt/tomcattlp/ The downloads don't work (I think because of where this is hosted but I haven't looked at it). I'll update this as work progresses. Any help with the TODOs will be appreciated. Comments on the structure are also welcome. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re:ACTUAL EMAIL .... - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
--- Remy Maucherat [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: 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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 23:43 --- I strongly agree with Craig, et al to error on the side of a more robust implemention by using synchronization on the side of Tomcat. I think doing otherwise would be doing a high-wire act without a net. There are too many places for a developer to miss handling the threading correctly to leave this as is. Somehow, I cannot access bugzilla right now. DNS failure or something. Can someone close this as invalid and end this pointless debate ? Otherwise, I'll do it first thing when I have access :) Thanks, Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Remy, How old are you actually? I'm asking because I believe you're reacting on feeling and not realistically looking at the bigger issue sort of like your feelings are hurt. We're not trying to attack someone personally here. There is an issue, and it's either with this one small section of code or a bunch of other sections. 1) How can JSP developers using jsp:useBean scope=session synchronize their code other than % % 2) How can JSP developers using EL synchronize their code 3) There is more to this than it's by spec. There are other issues in other Tomcat code that need to be addressed if this code is left as is. I think you need to discuss this with others and you need to look at all of the different use cases of the different facets of Tomcat...the tomcat project itself not even including the other issues which exist in other jakarta projects because of this. Maybe some other Tomcat developers need to comment. Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
[EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 21:29 --- After we finish clarifying who's is bigger (and mine is best case average), we could return to the bug. 1. The bug isn't invalid, so I reopen it. You can set it to WONTFIX, but not to INVALID. Indeed, WONTFIX looks to me like a reasonable resolution. 2. Applications working well with tomcat 4, resin or probably any other servlet container do not work with tomcat 5.0.x or tomcat 5.5.x. Thus tomcat 5 seems to be not compatible to the servlet spec (or be the only one compatible), if not in the language of the specification itself, but in the intension of it. So tomcat 5 can be considered BROKEN. Fine with me. 3. The bug applies to tomcat 5.5.x as well, because ... added back synchrnozation on write operations to the map in the 5.5 branch... doesn't fix anything, since the read operation are the problem and MUST be synchronized. Well, actually, I think you should bring that up with Sun, which have made a questionable/unsafe implementation of the collection IMO. A reasonable fix I would consider, however (showing I am not saying no to your bug report just for fun), is using another collection implementation, or tweaking that one, whatever works. After all, all that is missing is something like an e != e.next in HashMap.get. But of course, we're the OSS project, so we're always the ones being bugged to death, rather than proprietary software vendors :( Synchronizing the writes will also fix problems, since I think the underlying structure of the hashmap went bad due to a concurrency of reads. Try it before whining. Thanks. 5. The idea of removing synchronization to gain performance is absurd. Who needs the performance? People like us, who have 2000-3000 concurrent users on each webserver. But people who have 2000-3000 concurrent users, have also many concurrent requests, even from the same user, so instead of gaining performance we are gaining CRASHES. This bug killed 8 (!!!) webservers yesterday. I have extremely few problems with this. 6. Consider the flurry in the tomcat users community, if the above points + your refusal to provide a three LOCs fix gonna make tomcat 5 UNUSEABLE. Funny. The only flurry is the one you have created, and that I will have to ignore. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 00:42 --- (In reply to comment #17) I don't think anyone is looking to place blame here. I don't care what was originally in the Tomcat code and what is there now or why it was changed. This simply comes down to a legitimate issue that needs to be resolved. It's not even a minor issue frankly, it's a pretty substantial one, regardless of the fact that it apparently hasn't caused huge problems for everyone. I'm not even sure if I've been bitten by this either, but I have seen on the list numerous people speaking of running out of Tomcat threads and setting their connections to the max. If this issue were causing problems they might be having it and not even realize it. If the spec needs to be fixed, no problem, contact who needs to be contacted and let them know. But that DOES NOT mean you serialize and wait for them to do their thing. There is a solution here that, to my understanding, isn't contrary to the spec as it exists today anyway, so not following through with it is kind of silly. I'm sure any number of people would be willing to submit a patch for this if it's an issue of not having time, but to be arguing about whether it should be fixed or not doesn't seem to be reasonable on this one. I agreesynchronizing these calls isn't going to be contrary to the spec in no way at all. -- 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: Draft TLP site
On 9/7/05, Mark Thomas [EMAIL PROTECTED] wrote: I have made a checkout of tomcat/site/trunk available at http://www.apache.org/~markt/tomcattlp/ The downloads don't work (I think because of where this is hosted but I haven't looked at it). snip/ The webserver needs to view the scripts as executable content. chmod'ing the cgi's o+x should do it. -Rahul I'll update this as work progresses. Any help with the TODOs will be appreciated. Comments on the structure are also welcome. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
Remy Maucherat wrote: Synchronizing the writes will also fix problems, since I think the underlying structure of the hashmap went bad due to a concurrency of reads. Try it before whining. Thanks. Just a quick clarification. Did you mean to write ...Synchronizing the *reads* will also fix problems...? If concurrent reads is the problem, then don't the reads need to be synchronised? I thought from one of your earlier posts that the writes were already synchronised. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
[EMAIL PROTECTED] wrote: I'm not even sure if I've been bitten by this either, but I have seen on the list numerous people speaking of running out of Tomcat threads and setting their connections to the max. If this issue were causing problems they might be having it and not even realize it. It's trivial to see using a thraed dump. Please, don't try lame FUD. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Draft TLP site
Rahul Akolkar wrote: On 9/7/05, Mark Thomas [EMAIL PROTECTED] wrote: The downloads don't work (I think because of where this is hosted but I haven't looked at it). The webserver needs to view the scripts as executable content. chmod'ing the cgi's o+x should do it. Thanks. I spotted that after I posted but changing it doesn't seem to have fixed it. It is getting late - I'll look again with fresh eyes tomorrow. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
Mark Thomas wrote: Just a quick clarification. Did you mean to write ...Synchronizing the *reads* will also fix problems...? If concurrent reads is the problem, then don't the reads need to be synchronised? I thought from one of your earlier posts that the writes were already synchronised. Not in the 5.0.x build he's using. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 [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]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 01:08 --- I wonder if the new java.util.concurrent classes could be used instead of simple HashMap? http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ConcurrentHashMap.html but that would mean total dependence on j2se 1.5 and that would be a problem for supporting j2se 1.4, though a backport is being worked on here http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/ other reading here: http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html I think that sort of thing would provide a nice solution for speed + reliability. Using this as the underlaying base would/should fix issues with EL access too. -- 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: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
Remy Maucherat wrote: Mark Thomas wrote: Just a quick clarification. Did you mean to write ...Synchronizing the *reads* will also fix problems...? If concurrent reads is the problem, then don't the reads need to be synchronised? I thought from one of your earlier posts that the writes were already synchronised. Not in the 5.0.x build he's using. Indeed. But do we need to sync the reads in 5.5.x as well or is it enough just to do the writes? I am confused as you said concurrent reads were the issue but syncing the writes would fix it. Sorry if I am being dense here ;) Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r279457 - in /tomcat/site/trunk/xdocs: download-33.cgi download-41.cgi download-55.cgi download.cgi
Author: markt Date: Wed Sep 7 16:24:56 2005 New Revision: 279457 URL: http://svn.apache.org/viewcvs?rev=279457view=rev Log: Set scripts as executable and explicity set correct line endings Modified: tomcat/site/trunk/xdocs/download-33.cgi (contents, props changed) tomcat/site/trunk/xdocs/download-41.cgi (contents, props changed) tomcat/site/trunk/xdocs/download-55.cgi (contents, props changed) tomcat/site/trunk/xdocs/download.cgi (contents, props changed) Modified: tomcat/site/trunk/xdocs/download-33.cgi URL: http://svn.apache.org/viewcvs/tomcat/site/trunk/xdocs/download-33.cgi?rev=279457r1=279456r2=279457view=diff == --- tomcat/site/trunk/xdocs/download-33.cgi (original) +++ tomcat/site/trunk/xdocs/download-33.cgi Wed Sep 7 16:24:56 2005 @@ -1,6 +1,6 @@ -#!/bin/sh -# Wrapper script around mirrors.cgi script -# (we must change to that directory in order for python to pick up the -# python includes correctly) -cd /www/www.apache.org/dyn/mirrors -/www/www.apache.org/dyn/mirrors/mirrors.cgi $* +#!/bin/sh +# Wrapper script around mirrors.cgi script +# (we must change to that directory in order for python to pick up the +# python includes correctly) +cd /www/www.apache.org/dyn/mirrors +/www/www.apache.org/dyn/mirrors/mirrors.cgi $* Propchange: tomcat/site/trunk/xdocs/download-33.cgi -- svn:eol-style = LF Propchange: tomcat/site/trunk/xdocs/download-33.cgi -- svn:executable = * Modified: tomcat/site/trunk/xdocs/download-41.cgi URL: http://svn.apache.org/viewcvs/tomcat/site/trunk/xdocs/download-41.cgi?rev=279457r1=279456r2=279457view=diff == --- tomcat/site/trunk/xdocs/download-41.cgi (original) +++ tomcat/site/trunk/xdocs/download-41.cgi Wed Sep 7 16:24:56 2005 @@ -1,6 +1,6 @@ -#!/bin/sh -# Wrapper script around mirrors.cgi script -# (we must change to that directory in order for python to pick up the -# python includes correctly) -cd /www/www.apache.org/dyn/mirrors -/www/www.apache.org/dyn/mirrors/mirrors.cgi $* +#!/bin/sh +# Wrapper script around mirrors.cgi script +# (we must change to that directory in order for python to pick up the +# python includes correctly) +cd /www/www.apache.org/dyn/mirrors +/www/www.apache.org/dyn/mirrors/mirrors.cgi $* Propchange: tomcat/site/trunk/xdocs/download-41.cgi -- svn:eol-style = LF Propchange: tomcat/site/trunk/xdocs/download-41.cgi -- svn:executable = * Modified: tomcat/site/trunk/xdocs/download-55.cgi URL: http://svn.apache.org/viewcvs/tomcat/site/trunk/xdocs/download-55.cgi?rev=279457r1=279456r2=279457view=diff == --- tomcat/site/trunk/xdocs/download-55.cgi (original) +++ tomcat/site/trunk/xdocs/download-55.cgi Wed Sep 7 16:24:56 2005 @@ -1,6 +1,6 @@ -#!/bin/sh -# Wrapper script around mirrors.cgi script -# (we must change to that directory in order for python to pick up the -# python includes correctly) -cd /www/www.apache.org/dyn/mirrors -/www/www.apache.org/dyn/mirrors/mirrors.cgi $* +#!/bin/sh +# Wrapper script around mirrors.cgi script +# (we must change to that directory in order for python to pick up the +# python includes correctly) +cd /www/www.apache.org/dyn/mirrors +/www/www.apache.org/dyn/mirrors/mirrors.cgi $* Propchange: tomcat/site/trunk/xdocs/download-55.cgi -- svn:eol-style = LF Propchange: tomcat/site/trunk/xdocs/download-55.cgi -- svn:executable = * Modified: tomcat/site/trunk/xdocs/download.cgi URL: http://svn.apache.org/viewcvs/tomcat/site/trunk/xdocs/download.cgi?rev=279457r1=279456r2=279457view=diff == --- tomcat/site/trunk/xdocs/download.cgi (original) +++ tomcat/site/trunk/xdocs/download.cgi Wed Sep 7 16:24:56 2005 @@ -1,6 +1,6 @@ -#!/bin/sh -# Wrapper script around mirrors.cgi script -# (we must change to that directory in order for python to pick up the -# python includes correctly) -cd /www/www.apache.org/dyn/mirrors -/www/www.apache.org/dyn/mirrors/mirrors.cgi $* +#!/bin/sh +# Wrapper script around mirrors.cgi script +# (we must change to that directory in order for python to pick up the +# python includes correctly) +cd /www/www.apache.org/dyn/mirrors +/www/www.apache.org/dyn/mirrors/mirrors.cgi $* Propchange: tomcat/site/trunk/xdocs/download.cgi
Re: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
[EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 01:08 --- I wonder if the new java.util.concurrent classes could be used instead of simple HashMap? http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ConcurrentHashMap.html but that would mean total dependence on j2se 1.5 and that would be a problem for supporting j2se 1.4, though a backport is being worked on here http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/ other reading here: http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html I think that sort of thing would provide a nice solution for speed + reliability. Using this as the underlaying base would/should fix issues with EL access too. This would be a bad solution, because there are too many writes in many cases. From what I see, the regular HashMap.get will return null without further trouble (since that is all that is needed) as long as no resize occurs. This makes the problem fixable by creating a non resizable HashMap. Another possibility, which I consider very likely, is that concurrent resizes are the only problem, and in that case syncing only on writes is already enough. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r279458 - in /tomcat/site/trunk/docs: download-33.cgi download-41.cgi download-55.cgi download.cgi
Author: markt Date: Wed Sep 7 16:26:41 2005 New Revision: 279458 URL: http://svn.apache.org/viewcvs?rev=279458view=rev Log: Update props for generated docs Modified: tomcat/site/trunk/docs/download-33.cgi (contents, props changed) tomcat/site/trunk/docs/download-41.cgi (contents, props changed) tomcat/site/trunk/docs/download-55.cgi (contents, props changed) tomcat/site/trunk/docs/download.cgi (contents, props changed) Modified: tomcat/site/trunk/docs/download-33.cgi URL: http://svn.apache.org/viewcvs/tomcat/site/trunk/docs/download-33.cgi?rev=279458r1=279457r2=279458view=diff == --- tomcat/site/trunk/docs/download-33.cgi (original) +++ tomcat/site/trunk/docs/download-33.cgi Wed Sep 7 16:26:41 2005 @@ -1,6 +1,6 @@ -#!/bin/sh -# Wrapper script around mirrors.cgi script -# (we must change to that directory in order for python to pick up the -# python includes correctly) -cd /www/www.apache.org/dyn/mirrors -/www/www.apache.org/dyn/mirrors/mirrors.cgi $* +#!/bin/sh +# Wrapper script around mirrors.cgi script +# (we must change to that directory in order for python to pick up the +# python includes correctly) +cd /www/www.apache.org/dyn/mirrors +/www/www.apache.org/dyn/mirrors/mirrors.cgi $* Propchange: tomcat/site/trunk/docs/download-33.cgi -- svn:eol-style = LF Propchange: tomcat/site/trunk/docs/download-33.cgi -- svn:executable = * Modified: tomcat/site/trunk/docs/download-41.cgi URL: http://svn.apache.org/viewcvs/tomcat/site/trunk/docs/download-41.cgi?rev=279458r1=279457r2=279458view=diff == --- tomcat/site/trunk/docs/download-41.cgi (original) +++ tomcat/site/trunk/docs/download-41.cgi Wed Sep 7 16:26:41 2005 @@ -1,6 +1,6 @@ -#!/bin/sh -# Wrapper script around mirrors.cgi script -# (we must change to that directory in order for python to pick up the -# python includes correctly) -cd /www/www.apache.org/dyn/mirrors -/www/www.apache.org/dyn/mirrors/mirrors.cgi $* +#!/bin/sh +# Wrapper script around mirrors.cgi script +# (we must change to that directory in order for python to pick up the +# python includes correctly) +cd /www/www.apache.org/dyn/mirrors +/www/www.apache.org/dyn/mirrors/mirrors.cgi $* Propchange: tomcat/site/trunk/docs/download-41.cgi -- svn:eol-style = LF Propchange: tomcat/site/trunk/docs/download-41.cgi -- svn:executable = * Modified: tomcat/site/trunk/docs/download-55.cgi URL: http://svn.apache.org/viewcvs/tomcat/site/trunk/docs/download-55.cgi?rev=279458r1=279457r2=279458view=diff == --- tomcat/site/trunk/docs/download-55.cgi (original) +++ tomcat/site/trunk/docs/download-55.cgi Wed Sep 7 16:26:41 2005 @@ -1,6 +1,6 @@ -#!/bin/sh -# Wrapper script around mirrors.cgi script -# (we must change to that directory in order for python to pick up the -# python includes correctly) -cd /www/www.apache.org/dyn/mirrors -/www/www.apache.org/dyn/mirrors/mirrors.cgi $* +#!/bin/sh +# Wrapper script around mirrors.cgi script +# (we must change to that directory in order for python to pick up the +# python includes correctly) +cd /www/www.apache.org/dyn/mirrors +/www/www.apache.org/dyn/mirrors/mirrors.cgi $* Propchange: tomcat/site/trunk/docs/download-55.cgi -- svn:eol-style = LF Propchange: tomcat/site/trunk/docs/download-55.cgi -- svn:executable = * Modified: tomcat/site/trunk/docs/download.cgi URL: http://svn.apache.org/viewcvs/tomcat/site/trunk/docs/download.cgi?rev=279458r1=279457r2=279458view=diff == --- tomcat/site/trunk/docs/download.cgi (original) +++ tomcat/site/trunk/docs/download.cgi Wed Sep 7 16:26:41 2005 @@ -1,6 +1,6 @@ -#!/bin/sh -# Wrapper script around mirrors.cgi script -# (we must change to that directory in order for python to pick up the -# python includes correctly) -cd /www/www.apache.org/dyn/mirrors -/www/www.apache.org/dyn/mirrors/mirrors.cgi $* +#!/bin/sh +# Wrapper script around mirrors.cgi script +# (we must change to that directory in order for python to pick up the +# python includes correctly) +cd /www/www.apache.org/dyn/mirrors +/www/www.apache.org/dyn/mirrors/mirrors.cgi $* Propchange: tomcat/site/trunk/docs/download.cgi -- svn:eol-style = LF
Re: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
Mark Thomas wrote: Remy Maucherat wrote: Indeed. But do we need to sync the reads in 5.5.x as well or is it enough just to do the writes? I am confused as you said concurrent reads were the issue but syncing the writes would fix it. No, concurrent reads are not the issue. The problem is that when the HashMap structure is corrupted by concurrent writes (either a put causing a resize, or a remove), then any read might loop. I believe as long as the HashMap structure remains consistent, all the next fields for the entries (which is the problematic field) will have a correct value at the end of the resize/remove, so an infinite loop on get is then not possible. What this issue tells me, also, is that using the default size for the attributes HashMap may be inappropriate (it is best to avoid resizes, and the question is how much they happen - if at all, maybe it is remove which is most often used). Sorry if I am being dense here ;) No problem :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36534] - Context relative URLs returned by ServletContext.getResource() for the same path are not equal
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
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=36534.
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=36534
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFIX |
--- Additional Comments From [EMAIL PROTECTED] 2005-09-07 19:47 ---
Good point about toString(). I have a solution for that as well. Just override
org.apache.naming.resources.DirContextURLStreamHandler.toExternalForm() and
have
it ignore the authority part of the URL, as follows (this is copied from
java.net.URLStreamHandler.toExternalForm(), with authority part ignored):
/**
* Converts a codeURL/code of a specific protocol to a
* codeString/code.
*
* @param u the URL.
* @return a string representation of the codeURL/code argument.
*/
protected String toExternalForm(URL u) {
// pre-compute length of StringBuffer
int len = u.getProtocol().length() + 1;
if (u.getPath() != null) {
len += u.getPath().length();
}
if (u.getQuery() != null) {
len += 1 + u.getQuery().length();
}
if (u.getRef() != null)
len += 1 + u.getRef().length();
StringBuffer result = new StringBuffer(len);
result.append(u.getProtocol());
result.append(:);
if (u.getPath() != null) {
result.append(u.getPath());
}
if (u.getQuery() != null) {
result.append('?');
result.append(u.getQuery());
}
if (u.getRef() != null) {
result.append(#);
result.append(u.getRef());
}
return result.toString();
}
It is important that URLs returned by ServletContext.getResource() that are
equal have equals() return TRUE. This works for all other kinds of URLs.
I hadn't noticed you were the one who filed the bug. Besides skipping
the result.append(:);
Not sure I understand: the : following the protocol is necessary,
so that the printable representation of the context generated URLs
starts with jndi:.
you should simply apply the fix, it's a very
good solution.
I'm still having problems with CVS, which are preventing me from
committing my fix.
If you can commit this on my behalf, I'd appreciate it.
The complete fix consists of the above diff and the following patch
in org.apache.catalina.core.ApplicationContext:
try {
resources.lookup(path);
return new URL
-(jndi, null, 0, getJNDIUri(hostName, fullPath),
- new DirContextURLStreamHandler(resources));
+(jndi, , 0, getJNDIUri(hostName, fullPath),
+ new DirContextURLStreamHandler(resources));
} catch (Exception e) {
// Ignore
}
Thanks,
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]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 04:27 --- As discussed on tomcat-dev after I reexamined StandardSession code further, adequate synchrnoization seems to be in place in the current Tomcat 5.5 code so that the infinite loop situation described in this issue does not occur. Please do not reopen the 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]
Re: DO NOT REPLY [Bug 36534] - Context relative URLs returned by ServletContext.getResource() for the same path are not equal
Jan Luehe wrote:
Remy Maucherat wrote:
I hadn't noticed you were the one who filed the bug. Besides skipping
the result.append(:);
Not sure I understand: the : following the protocol is necessary,
so that the printable representation of the context generated URLs
starts with jndi:.
Right, it's not related to the port number. Doh.
you should simply apply the fix, it's a very
good solution.
I'm still having problems with CVS, which are preventing me from
committing my fix.
If you can commit this on my behalf, I'd appreciate it.
The complete fix consists of the above diff and the following patch
in org.apache.catalina.core.ApplicationContext:
try {
resources.lookup(path);
return new URL
-(jndi, null, 0, getJNDIUri(hostName, fullPath),
- new DirContextURLStreamHandler(resources));
+(jndi, , 0, getJNDIUri(hostName, fullPath),
+ new DirContextURLStreamHandler(resources));
} catch (Exception e) {
// Ignore
}
Ok.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 05:25 --- (In reply to comment #15) Why not keep everybody happy, simply make the session management class a configurable option at both Server and Context level, if the TC developers wish to experiment they can configure the un-synchronized access they so desire. Actually, the session management code *is* already configurable, albeit not trivially. You can include a Manager element inside your Context element and create a custom implementation of the Manager interface that returns session instances (probably subclassed from StandardSession) that do the locking for you. The key question remains what the default behavior should be, and/or whether there should be an easy boolean setting to turn this particular capability on or off. -- 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 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
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=36541. 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=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 05:32 --- (In reply to comment #8) (In reply to comment #7) I would agree that neither implementation is buggy -- it is entirely legal for a servlet container to avoid letting an application corrupt its interna data structures. It's too bad that the current Tomcat developers care more about performance than they care about reliability. Of course. Thankfully, you guys have glassfish now for good reliability, so you don't have to deal with these loony Tomcat developers anymore ;) Apparently it is indeed a good thing :-). The appropriate patch was just committed to the Glassfish repository. If people want an open source implementation of the servlet spec where the developers listen to users on issues like this, you might want to browse over to: https://glassfish.dev.java.net and take a look. If you aren't going to change it back to the 4.1 implementation (with synchronization locks around the accesses), please take my name out of the @author tag for org.apache.catalina.session.StandardSession -- this code does *not* represent anything I wish to be associated with. Sure, I have no problem with that if it's your wish. This (removing my name from the @author tag on StandardSession), both here and everywhere else in the Tomcat code base, would indeed be my wish. -- 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]
Yurisha R Gathiram/SwissRe is out of the office.
I will be out of the office starting 2005/09/01 and will not return until 2005/09/13. For urgent queries, please contact Claude du Plessis on 011 489-5702 or [EMAIL PROTECTED] Please note that this email has not been forwarded to anyone. I will respond to your email on my return. Kind regards, Yurisha This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
