DO NOT REPLY [Bug 36995] - duplicate session ids
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=36995. 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=36995 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-10-11 09:09 --- (In reply to comment #1) I hava look inside also inside 5.5.x code (ManagerBase.generateSessionId()) and think the duplication risk is there. But the risk is small, as random generator works really good. I have test with Linux Suse 9.3 and have no chance to reproduce your test result. Can you please send your testscripts and os information? This does not make any sense. The risk does not exist, and the uniqueness check is just there to make insecure people more secure. I am actually tired of it, and would want it removed. -- 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 37018] New: - Document how to use tomcat-SSL with a pkcs11 token
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=37018. 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=37018 Summary: Document how to use tomcat-SSL with a pkcs11 token Product: Tomcat 5 Version: 5.5.9 Platform: Other URL: http://java.sun.com/j2se/1.5.0/docs/guide/security/p11gu ide.html OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Connector:Coyote AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Since jdk1.5 has a sun.security.pkcs11.SunPKCS11 implementing java.security.Provider, it should be possible to no longer store private keys on the server computer's harddisk, but on a USB token or alike (being willing to accept that SSL may become very slow...) Others appear to have asked for this http://marc.theaimsgroup.com/?l=tomcat-userm=111471470228516w=2 more also in http://forum.java.sun.com/thread.jspa?threadID=256018messageID=3838346 -- 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 36905] - Tomcat WebDAV characters bug
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=36905. 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=36905 --- Additional Comments From [EMAIL PROTECTED] 2005-10-11 13:07 --- Created an attachment (id=16655) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16655action=view) Screen dump of directorylisting with filename containing semi-colon. -- 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 36905] - Tomcat WebDAV characters bug
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=36905. 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=36905 --- Additional Comments From [EMAIL PROTECTED] 2005-10-11 13:07 --- Created an attachment (id=16656) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16656action=view) Screen-dump of error-msg when I click the filename with semi-colon. -- 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 36905] - Tomcat WebDAV characters bug
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=36905. 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=36905 --- Additional Comments From [EMAIL PROTECTED] 2005-10-11 13:10 --- I have discovered a simular problem that seems to be related to this bug. I place a file with semi-colon in the filename under the Tomcat http server. When I am linking to that file (test;01.png) i get the requested resource is not available. Take a look at the attached screendumps. Screen1 shows a directory listing of the file in question. Screen2 shows the error-msg when i click the filename. This is not a problem in Apache 2.0.53 I tested and found this problem using IE 6.0 and Firefox 1.0.7 against Tomcat 5.5.12 -- 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 36995] - duplicate session ids
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=36995. 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=36995 --- Additional Comments From [EMAIL PROTECTED] 2005-10-11 14:01 --- Created an attachment (id=16657) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16657action=view) A simple test case to check for duplicate session ids. -- 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 36995] - duplicate session ids
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=36995. 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=36995 --- Additional Comments From [EMAIL PROTECTED] 2005-10-11 14:02 --- We have Suse 8.2 with kernel 2.4.20-64GB-SMP on our servers. Java version is 1.4.2_03 and Tomcat 4.1.29. As the chances for the described scenario are slim, I suggest to reduce the value of ManagerBase.SESSION_ID_BYTES from 16 to 2 or 3 for testing. This should increase the chances of duplicates returned by ManagerBase.generateSessionId() without affecting the behaviour of Tomcat. Additionally, I put a Thread.yield() below the end of the sychronized block in ManagerBase.createSession(), to provoke the racing time condition, further increasing the chances for the scenario. Then I started Tomcat with the JSP page session.jsp: %@ page language=java %%= request.getSession().getId() % The test application performs repeated request from different threads, recoding the returned session ids and checking for duplicates. Even with the reduced random range it might take several runs to stumble into a duplicate. I'm sure there are better ways to test it, it is just a simple test. I'm not saying this is an urgent problem, or that it happens all the time, I merely think that it can happen, because random numbers, however large the range might be, are not unique by themselves, are they? And if it can happen, it will happen, eventually. Or 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 29526] - Cannot undeploy and deploy war file with on the same context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29526. 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=29526 [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 37020] New: - antiJARLocking and antiResourceLocking with many lib jars causes performance degradation and reload failure.
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=37020. 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=37020 Summary: antiJARLocking and antiResourceLocking with many lib jars causes performance degradation and reload failure. Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Here is a catch-22. We want to use deployer to deploy web applications to target servers. It formalises the process of build a little more. However, deployer does not work well on Windows as JARs get left behind. Furthermore another bug I submitted yesterday shows that deploying, restarting the Windows service and then undeploying breaks. That restart bug aside, in order to even get deploy and undeploy to work we have to use antiJARLocking=true antiResourceLocking=true on our context. I added this just the other day and I noticed that starting Tomcat took a whole lot longer than usual (nearly 1 minute), and that compiling class changes to my development Tomcat did not cause the usual web application reload (as indicated by reloadable=true on the context). I decided that the only thing I changed was the antiJARLocking=true antiResourceLocking=true attributes. I took them off today and Tomcat starts up in 20s. Furthermore, compiling class changes works again. I thought about why this might be and we have 18M of lib JARs. In order for the anti locking to work I notice that copies are made to a temp folder. I can only assume therefore that having so many JARs in a web application lib combined with using the anti locking features causes this huge degradation in ability to develop and test. I've made sure this is definately the problem by adding and removing the antiJARLocking=true antiResourceLocking=true attributes a few times, and it always varies from 58s and no reloading with them set to true and 20s and reloading ok with them false. -- 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 36994] - httpsession.getId() throws ISE after invalidation
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=36994. 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=36994 --- Additional Comments From [EMAIL PROTECTED] 2005-10-11 17:15 --- I agree with Lars. I use a Map (stored as an attribute of the ServletContext) to keep track of the active http sessions. Using Tomcat 5.5.9 I didn't have any problem logging-out, but with Tomcat 5.5.12 when I try to invalidate a session I get an ISE (getId: Session already invalidated). (In reply to comment #0) After a http session is invalidated a call to getId() throws an IllegalStateException(already invalidated). I think this doesn't conform to the servlet spec that doesn't say anything about an ISE in the api doc. All ISEs that can be thrown by the session-methods are explicit listed. Beside this it is very essential to have the sessionId at least during HttpSessionBindingListener.valueUnbound() if this method is called during the invalidation. The api doc of valueUnbound() says: Notifies the object that it is being unbound from a session and identifies the session. The session is identified by its Id, but if the Id is not accessible anymore... The ISE was inserted in Version 5.5.10: excerpt from the changelog: Re-add patch causing Session.getId to throw an ISE, and make all internal components use a safe getIdInternal Thanks Lars -- 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: [RESULT][VOTE] Tomcat 5.5.12 is stable
Probably a late answer, but when you're saying that have been no changes to the sourcecode since alpha, you mean, that http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 is still open for 5.5.12? So the bug is resolved/fixed but actually unfixed for next 6 month? Leon On 10/9/05, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, The 5.5.12 stability vote is now over, and the release is stable. The following votes were cast for stable: Jeanfrancois Arcand Allistair Crossley Henri Gomez Jim Jagielski (not sure if this one is binding in the strictest sense of the word) Remy Maucherat Peter Rossbach Yoav Shapira Mladen Turk There were no beta or alpha votes. I'll go update the web site. There have been no code changes since the alpha release, so if you already have the 5.5.12-alpha distribution you don't have to go download a new distro. Thank you, Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][VOTE] Tomcat 5.5.12 is stable
Hi, --- Leon Rosenberg [EMAIL PROTECTED] wrote: Probably a late answer, but when you're saying that have been no changes to the sourcecode since alpha, you mean, that http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 is still open for 5.5.12? No, that's not what I mean. As the 5.5.12 changelog indicates, issue 36541 is fixed in that release. It was included in the 5.5.12-alpha distro, and so it's in the stable release as well. So the bug is resolved/fixed but actually unfixed for next 6 month? No, you misunderstood. As an aside, even if the 36541 fix were not included in 5.5.12, I would disagree with actually unfixed and next 6 month as neither would be accurate. But these are separate issues for a separate thread if you want to rant about how Bugzilla is used or about how frequently we cut releases. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat ApplicationDispatcher forward handling
We have a question about QueryString handling in tomcat. We have a simple question; we noticed that tomcat carries querystring forward on forward requests if the current forward querystring is NULL only. Is this the correct behavior and if so; were is this documented? We've been through the Servlet 2.4 spec and can't find a definition of this behavior. The specification indicates that javax.servlet.forward.query_string should reflect the initial client requested query string; however the specification seems quiet about request.getQueryString's behavior. Any insight would be helpful. Thanks! -Original Message- From: Yoav Shapira [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 11, 2005 11:05 AM To: Tomcat Developers List Subject: Re: [RESULT][VOTE] Tomcat 5.5.12 is stable Hi, --- Leon Rosenberg [EMAIL PROTECTED] wrote: Probably a late answer, but when you're saying that have been no changes to the sourcecode since alpha, you mean, that http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 is still open for 5.5.12? No, that's not what I mean. As the 5.5.12 changelog indicates, issue 36541 is fixed in that release. It was included in the 5.5.12-alpha distro, and so it's in the stable release as well. So the bug is resolved/fixed but actually unfixed for next 6 month? No, you misunderstood. As an aside, even if the 36541 fix were not included in 5.5.12, I would disagree with actually unfixed and next 6 month as neither would be accurate. But these are separate issues for a separate thread if you want to rant about how Bugzilla is used or about how frequently we cut releases. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][VOTE] Tomcat 5.5.12 is stable
On 10/11/05, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, --- Leon Rosenberg [EMAIL PROTECTED] wrote: Probably a late answer, but when you're saying that have been no changes to the sourcecode since alpha, you mean, that http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 is still open for 5.5.12? No, that's not what I mean. As the 5.5.12 changelog indicates, issue 36541 is fixed in that release. It was included in the 5.5.12-alpha distro, and so it's in the stable release as well. Superb :-) Sorry, I should have looked into the changelog first. So the bug is resolved/fixed but actually unfixed for next 6 month? No, you misunderstood. As an aside, even if the 36541 fix were not included in 5.5.12, I would disagree with actually unfixed and next 6 month as neither would be accurate. But these are separate issues for a separate thread if you want to rant about how Bugzilla is used or about how frequently we cut releases. Mea culpa Yoav Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36994] - httpsession.getId() throws ISE after invalidation
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=36994. 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=36994 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-10-11 19:19 --- This is now required by the servlet spec, so it can't be changed by Tomcat. See: http://jcp.org/aboutJava/communityprocess/maintenance/jsr154/154errata.txt If the Servlet Expert Group decides to change this at some future point, then Tomcat can consider removing the ISE. Until then, the only place to complain about this is: [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 37035] New: - Prevent temp\ directory disappearing when tar.gz is used on Windows
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=37035. 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=37035 Summary: Prevent temp\ directory disappearing when tar.gz is used on Windows Product: Tomcat 5 Version: 5.5.12 Platform: Other OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P2 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] If a user: - is on Windows - downloads the tar.gz distribution - unpacks with WinZIP then Tomcat breaks in odd ways. This is because the temp\ directory is empty in the distribution, and WinZIP's default behaviour is not to create directories if they are empty. I know this is a combination of WinZIP stupidity and odd user behaviour, but there is an easy way to avoid the problem: add a temp\README.txt file so the directory is non-empty. There was a temp\README.txt in 4.1 days, which read: This temp directory is used by the JVM for temporary file storage. The JVM is configured to use this as its java.io.tmpdir in the catalina.sh and catalina.bat scripts. Tomcat is configured to use this temporary directory rather than its default for security reasons. The temp directory must exist for Tomcat to work correctly. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: More helpful reporting of exceptions in JSPs
The 'correct' way to do this is to create an enhancement request in bugzilla and attach your patch to it. Mark -Original Message- From: Tim Fennell [mailto:[EMAIL PROTECTED] Sent: Sunday, October 09, 2005 10:50 PM To: tomcat-dev@jakarta.apache.org Subject: More helpful reporting of exceptions in JSPs Hi, I'll apologize in advance if this is the wrong place to post this, or if this has been covered before. I had a good read through the Tomcat docs and faqs, searched the bug database, and googled around on the topic, but could not really find anything. I've been using Tomcat for a while, and in general have found it as good a servlet/JSP container as any I've used. With one exception (no pun intended). A long time ago I started out using WebLogic, and the one thing that I loved about WebLogic, that is missing from Tomcat, is that when an Exception occurred in a JSP it would tell you what line number *in the JSP* generated the exception, and show you a snippet of code around the offending line. For quite a while I'd figured that the way Tomcat was built prevented this from being easy/possible, but I didn't look. Well, I finally got around to looking, and it only took me a couple of hours to implement it. Which makes me wonder if there is some other reason that this isn't done in Tomcat/Jasper? At any rate, I have code that will do this now, and I think it'd be a great productivity boost for anyone else developing JSPs on Tomcat. It amounts to small patches to two files. The first is org.apache.jasper.compiler.Compiler to make it hang on to the parse tree (pageNodes) if in development mode, and a getter to make this accessible. The second is to org.apache.jasper.servlet.JspServletWrapper to do the grunt work of mapping a stack frame from the exception back to the line in the JSP that it came from. It's all coded up to function only when in development mode, and is reasonably well commented. Would any of the committers be interested in taking a look at this if I put together a patch and posted it here? Cheers, -Tim Fennell http://stripes.mc4j.org - 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]
