DO NOT REPLY [Bug 26752] New: - java.util.ConcurrentModificationException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26752. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26752 java.util.ConcurrentModificationException Summary: java.util.ConcurrentModificationException Product: Tomcat 5 Version: 5.0.18 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am running standalone tomcat 5.0.18 with java 1.4.1-b2 Whenever tomcat starts, it prints out following errors and 500 replies. It makes me reload my web app and then it runs well. java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification (AbstractList.java:444) at java.util.AbstractList$Itr.next(AbstractList.java:417) at java.util.AbstractCollection.remove(AbstractCollection.java:250) at org.apache.coyote.RequestGroupInfo.removeRequestProcessor (RequestGroupInfo.java:17) at org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:96) at org.apache.coyote.http11.Http11Protocol$MXPoolListener.threadEnd (Http11Protocol.java:620) at org.apache.tomcat.util.threads.ThreadPool.removeThread (ThreadPool.java:279) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:727) at java.lang.Thread.run(Thread.java:536) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wrong Address
You've sent a message to an email address that does not exist in the txeurope.com server. Please check the address and send your email again. Thanks TXEurope.com Postmaster - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5715] - response.setContentType() in Filter.doFilter not changed content type
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5715. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5715 response.setContentType() in Filter.doFilter not changed content type [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 14:28 --- The Filter is setting the content type, but then the JSP is next in the pipeline and then sets the content type overriding what was set by the filter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5952] - Refence to $JAVACMD in tomcat.conf incorrect in RPM dist
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5952. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5952 Refence to $JAVACMD in tomcat.conf incorrect in RPM dist [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 14:31 --- (AFAIK) The tomcat team is no longer maintaining RPMS for installations - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5998] - Exception hiding when a JspExceptioin is thrown by a tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5998. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5998 Exception hiding when a JspExceptioin is thrown by a tag [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 14:32 --- This is fixed in later tomcat versions, wont be addressed in 4.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 6659] - HttpUtils.getRequestURL gives incorrect URL with web.xml redirected error pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6659. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6659 HttpUtils.getRequestURL gives incorrect URL with web.xml redirected error pages [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 14:40 --- Based on the writeup, this appears to be a bug/change in the implementation of HttpUtils. HttpUtils lives under javax.sun.*. Because of this, tomcat team is not allowed to make this change. A change would need to go through Sun's servlet feedback. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7588] - Session cannot be established if there are multiple session cookies
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7588. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7588 Session cannot be established if there are multiple session cookies [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 14:43 --- *** This bug has been marked as a duplicate of 10419 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10419] - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 14:43 --- *** Bug 7588 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8100] - Session Tracking and HttpURLConnection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8100. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8100 Session Tracking and HttpURLConnection [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 14:46 --- Based on the comments and tomcats current bahavior - marking as worksforme. Please reopen with .war file test cases against 4.1.30 (or better). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9107] - error in or incomplete documentation ?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9107. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9107 error in or incomplete documentation ? [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 14:51 --- Please use tomcat-user for configuration help. The link is http://www.galatea.com/flashguides/apache-tomcat-24-unix.xml is not maintained by the tomcat team. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9921] - JDBCRealm doesn't work with more service definition
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9921. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9921 JDBCRealm doesn't work with more service definition [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 14:53 --- This appears to be a configuration exercise. Please use tomcat-user list for assistance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10249] - Tomcat hangs with Interclient JDBC driver
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10249. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10249 Tomcat hangs with Interclient JDBC driver [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 14:57 --- The latest version of tomcat 4.1 is using the newer versions of pool and dbcp. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10558] - encodeURL form submit doesn't include hidden form variables
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10558. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10558 encodeURL form submit doesn't include hidden form variables [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 14:59 --- closing based on most recent comments - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10595] - Security Constraints not processed according to spec.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10595. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10595 Security Constraints not processed according to spec. [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 15:01 --- Based on the comments, this is a spec problem/interpretation of the spec. Closing based on Craig's comments since he very closey related to the spec team. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11197] - Filters and JSP.3.2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11197. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11197 Filters and JSP.3.2 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 15:04 --- *** This bug has been marked as a duplicate of 5715 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5715] - response.setContentType() in Filter.doFilter not changed content type
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5715. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5715 response.setContentType() in Filter.doFilter not changed content type [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 15:04 --- *** Bug 11197 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11753] - Synchronous startup script - startup.sh should wait until Tomcat is fully started
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11753. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11753 Synchronous startup script - startup.sh should wait until Tomcat is fully started [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 15:07 --- The statrup scripts don;t have the ability to know when tomcat is done starting up. If this functionality is really needed - embedding tomcat would be the way to go. Otherwise this is an enhancement request.(Which would be ignored without an corresponding patch) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11755] - Possible to hang new instance if old instance is not yet fully shut down
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11755. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11755 Possible to hang new instance if old instance is not yet fully shut down [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 15:08 --- There is a kill option in the shutdown scripts to ensure tomcat is stopped. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26752] - java.util.ConcurrentModificationException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26752. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26752 java.util.ConcurrentModificationException [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 15:08 --- The fix for this is in CVS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12184] - FORM based authentication / j_security_check not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12184. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12184 FORM based authentication / j_security_check not working [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 15:10 --- This looks like a configuration exercise, please use tomcat-user list for help if this is still not ficed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12263] - response.sendRedirect won't send to Tomcat SSL
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12263. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12263 response.sendRedirect won't send to Tomcat SSL [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 15:13 --- Proabably fixed (in lastest release) based on Remy's comments. Reopen if still problem with restatement and more detailed config. Note: If using mod_webapp - this will be marked as WONTFIX since mod_webapp is deprecated and unsupported by the tomcat team. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12428] - request.getUserPrincipal(): Misinterpretation of specification?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12428. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12428 request.getUserPrincipal(): Misinterpretation of specification? [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 15:14 --- Ya - this is a problem but tomcat is compatible with the spec. (So its a spec problem) The pricipal only needs to be set on protected URLs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12428] - request.getUserPrincipal(): Misinterpretation of specification?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12428. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12428 request.getUserPrincipal(): Misinterpretation of specification? [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 15:15 --- doh - wrong status - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12428] - request.getUserPrincipal(): Misinterpretation of specification?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12428. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12428 request.getUserPrincipal(): Misinterpretation of specification? [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 15:15 --- fix status to INVALID, not FIXED. (Sorry for the extra emails) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26760] New: - bean:define / issue.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26760
bean:define / issue.
Summary: bean:define / issue.
Product: Tomcat 5
Version: 5.0.18
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Please look at this code:
---
%@ taglib uri='/WEB-INF/struts-bean.tld' prefix='bean' %
%if (1 == 1) {%
bean:define id=tmp_caption value=tab.caption toScope=request /
%} else {%
bean:define id=tmp_caption value=val.pluralDesc toScope=request /
%}%
--
This code is not compilable by current jasper.
I know that bean:define has the following issue:
USAGE NOTE - There is a restriction in the JSP 1.1 Specification that disallows
using the same value for an id attribute more than once in a single JSP page.
Therefore, you will not be able to use bean:define for the same bean name more
than once in a single page.
But:
This one is compiled:
%@ taglib uri='/WEB-INF/struts-bean.tld' prefix='bean' %
bean:define id=tmp_caption value=tab.caption toScope=request /
bean:define id=tmp_caption value=val.pluralDesc toScope=request /
can you please provide a little comment on what kind of bug this is? a jasper or
struts?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26760] - bean:define / issue.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26760. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26760 bean:define / issue. --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 17:11 --- I've also posted this bug against Struts component, so if you want to see their comments - look here http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26761 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10419] - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions [EMAIL PROTECTED] changed: What|Removed |Added URL|http://www.freiheit.com/user|http://vicdor.org/~hzeller/S |s/hzeller/SessionBugDemonstr|essionBugDemonstration.java |ation.java | --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 20:16 --- Since the URL to the original demonstration servlet of this issue wasn't reachable anymore (this bug is now open for 1.5 years..), I've moved it to a new location. You can find it at http://vicdor.org/~hzeller/SessionBugDemonstration.java now. While re-reading the comments after a while I noticed that referencing the bugs 1 and 2 in my first comment is a bit misleading since bugzilla tries to link to the literal number. They actually stand for the two bugs I've committed regarding two related aspects of faulty session handling in tomcat, namely Bug #10418 and this Bug #10419. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10418] - logic whether URL needs to be encoded in HttpServletResponse.encodeURL() broken
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10418. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10418 logic whether URL needs to be encoded in HttpServletResponse.encodeURL() broken [EMAIL PROTECTED] changed: What|Removed |Added URL|http://www.freiheit.com/user|http://vicdor.org/~hzeller/S |s/hzeller/SessionBugDemonstr|essionBugDemonstration.java |ation.java | Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 21:27 --- Since the original SessionBugDemonstration hasn't been reachable, I've moved it to http://vicdor.org/~hzeller/SessionBugDemonstration.java Please note, that this Bug is also related to #10419; problems with faulty clients like IE that may as well send invalid session IDs in cookies (see comments there) could be effectively thwarted if tomcat would choose to encode URLs in that case. I still think that the behaviour is faulty and it is still not fixed. The _requested_ session ID is an ID that comes from the client and might not necessarily be a valid ID (the browser continues to send cookies as long as it is not shutdown). So consider a web application that has a cookie that timed out. Later the user chooses to not accept any new cookies and enters the web application again. So this is not 'in the middle' of something that cookies are disabled (as Remy Maucherat states in comment at 2002-07-03 07:55) but between two usages of the same application. The web application creates a new session but gets a 'requested' session ID from the old cookie still lying around .. and chooses not to encode URLs based on that fact -- even though the session-ID it got has nothing to do with the session ID newly created. However, since the URLs are not encoded and the browser does not accept the new cookie, the application will simply not work because it will never see its newly creates session id again. As long as the application has not received the _first valid_ cookie from the browser it must encode its URLs. Every application should (conservativly) start encoding its URLs until it knows that it gets the session ID from the cookie; ITS session id, not SOME. Right now, tomcat optimistically assumes that if there is _some_ JSESSIONID-cookie then everything will go fine.. I had to do several workarounds in different applications already because of this (like http://cvs.sourceforge.net/viewcvs.py/j-wings/wings/src/org/wings/session/SessionServlet.java?annotate=1.25#385 ) As application developer you often stumble over this bug when you actually test your application if it works with cookies enabled and disabled -- you've to restart your browser everytime you invalidate a session ... Or if you don't restart your browser that often but use it for weeks (ok, this is probably unlikely on windows but on Un*x I do this all the time :-) Since there is no comment that explains that this is _not_ a bug and since this bug actually requires to do workarounds at the application level (see above), I'll reopen it again. If you think, the solution I provided is to expensive I'll dig through the sources again and find another one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wrong Address
You've sent a message to an email address that does not exist in the txeurope.com server. Please check the address and send your email again. Thanks TXEurope.com Postmaster - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_Jk2 - Default Worker
Good morning Costin. Thanks for the time given to replying. I agree with the ideas you have given, of decoupling URI's from workers explicitly tied to a communications protocol, but in reality this connectivity is supported and actually gives the minimum workable configuration. But given that a default architecture is but a 'guess', I see the programming to be 'cleaner' without such defaults and rather provide a 'default' configuration file that would achieve the same end. The present situation hides the basic building blocks of Mod_Jk2 and leads to the majority of questions in regard to how to reconfigure the module. Remove the ability of 'workers' to directly accept requests and force all URI's through an lb type, and the current default approach would be entirely appropriate. NormW wrote: Good morning All. The default 'worker', which is hard-wired into Mod_Jk2, is 'lb:lb', and is, for most users I believe, a wrong guess at best, since the majority of users are probably not using mod_jk2 in load-balancing mode. The 'guess' means that mod_jk2 creates uri objects assigned to either a load-balancer that doesn't exist , a load-balancer that is not hooked into anything or a load-balancer that is not even wanted. For example, the following uri's are created automatically: :-) I agree that lb is a missleading name, as is the whole worker concept. The real intent is for lb to represent one tomcat cluster ( of one or many servers ), and for routing to be directed to different clusters instead of individual machines. Even if you have a single tomcat - I think it is still better to make the mapping based on the tomcat instance, and not on the various protocols used to connect. The overhead of having lb is very small, and IMO it's well worth it given the simplification in code and the extra features. I also think the right direction is to decouple the worker ( as a particular protcol to connect to a tomcat instance ) from the notion of routing requests to a particular instance or cluster, which may use multipe protocols and workers. nameurigroup context * null null null *// lb:lb / Given the present arrangement, I can understand (if not support) the lb:lb uri entry above but the one assigned to a 'null' group with a uri of 'null' seems to be a bug. There is no means to determine the existence of the 'lb:lb' worker, but suffice to say, my setup doesn't want or need it anyway. (As an aside, perhaps this might be an extension to /jkstatus/ ?) I think the code created the lb:lb automatically unless one is defined exeplicitely. The goal was to have each tomcat instance ( or cluster ) associated with an lb, with a reasonable default to minimize trivial configuration. Then each lb would have one or multiple protocols pointing at different tomcat instances. A more valid approach would be to identify, via the workers2.properties file, which worker of those configured is to be considered the 'default'. It would also become the 'default' worker/group for [uri] sections not having a worker/group entry when created, and a variation of the JkUriSet parameter could also allow use of the 'default' worker, for example: JkUriSet worker default The existing code makes allowance for a defaultWorker property in the [workerEnv] section of memory, and I would like to submit the attached [patch as a step in such an arrangement. If this option isn't used within the workers2.properties file, then the module reverts to current operation. The parameter proposed would look as follows and retain the current default for wEnv-defaultWorker: I'm not very comfortable with this ( I'm close to -1, but if other people think it's a good idea I can change it to -0). As noted, the proposed patch subtracts nothing from the present position, while allowing access to the parameter if required. It kinds of moves us backwards, to the mess of protocols and load balancers. Architecturally, Mod_Jk2 isn't a 'mess' by any description, it has mostly been rendered incomprehensible by hiding it's few building blocks. I'm ok with any renaming or clarification or defaults - as long as we keep or increase the current separation between protocols ( i.e. ajp-like workers ) and clusters/instances - or however you want to call the lb-like workers. That tie-up exists because the worker name was derived from the protocol. Ideally the protocol should have been in the channel, leaving the 'worker' to handle _a_ request, and lb to decide which worker to get it... assuming there is more than one Tomcat to receive it. However, it still doesn't make much sense to have a balancer capability in front of a single worker. All mapping should be made between URIs and lb ( clusters/instances ), and each lb can have multiple protocols ( ajp ) associated. It would be great if we just create a separate interface to make it clear
DataViz Sales - Auto Response
Please note: Your e-mail to DataViz was NOT received! Due to the increasing amount of SPAM and unsolicited e-mail received at this address, we no longer accept inquires submitted directly to this e-mail address. We ask that anyone wishing to contact us please do so through a form on our website. We apologize for the inconvenience, but this will benefit both you and our sales and customer service representatives, as they can respond much more quickly to your inquiry. Please visit the link below to re-submit your request. For your convenience, your original post is listed below. http://www.dataviz.com/contactdataviz Sincerely, The DataViz Sales Department Original Message Follows Good morning Costin. Thanks for the time given to replying. I agree with the ideas you have given, of decoupling URI's from workers explicitly tied to a communications protocol, but in reality this connectivity is supported and actually gives the minimum workable configuration. But given that a default architecture is but a 'guess', I see the programming to be 'cleaner' without such defaults and rather provide a 'default' configuration file that would achieve the same end. The present situation hides the basic building blocks of Mod_Jk2 and leads to the majority of questions in regard to how to reconfigure the module. Remove the ability of 'workers' to directly accept requests and force all URI's through an lb type, and the current default approach would be entirely appropriate. NormW wrote: Good morning All. The default 'worker', which is hard-wired into Mod_Jk2, is 'lb:lb', and is, for most users I believe, a wrong guess at best, since the majority of users are probably not using mod_jk2 in load-balancing mode. The 'guess' means that mod_jk2 creates uri objects assigned to either a load-balancer that doesn't exist , a load-balancer that is not hooked into anything or a load-balancer that is not even wanted. For example, the following uri's are created automatically: :-) I agree that lb is a missleading name, as is the whole worker concept. The real intent is for lb to represent one tomcat cluster ( of one or many servers ), and for routing to be directed to different clusters instead of individual machines. Even if you have a single tomcat - I think it is still better to make the mapping based on the tomcat instance, and not on the various protocols used to connect. The overhead of having lb is very small, and IMO it's well worth it given the simplification in code and the extra features. I also think the right direction is to decouple the worker ( as a particular protcol to connect to a tomcat instance ) from the notion of routing requests to a particular instance or cluster, which may use multipe protocols and workers. nameurigroup context * null null null *// lb:lb / Given the present arrangement, I can understand (if not support) the lb:lb uri entry above but the one assigned to a 'null' group with a uri of 'null' seems to be a bug. There is no means to determine the existence of the 'lb:lb' worker, but suffice to say, my setup doesn't want or need it anyway. (As an aside, perhaps this might be an extension to /jkstatus/ ?) I think the code created the lb:lb automatically unless one is defined exeplicitely. The goal was to have each tomcat instance ( or cluster ) associated with an lb, with a reasonable default to minimize trivial configuration. Then each lb would have one or multiple protocols pointing at different tomcat instances. A more valid approach would be to identify, via the workers2.properties file, which worker of those configured is to be considered the 'default'. It would also become the 'default' worker/group for [uri] sections not having a worker/group entry when created, and a variation of the JkUriSet parameter could also allow use of the 'default' worker, for example: JkUriSet worker default The existing code makes allowance for a defaultWorker property in the [workerEnv] section of memory, and I would like to submit the attached [patch as a step in such an arrangement. If this option isn't used within the workers2.properties file, then the module reverts to current operation. The parameter proposed would look as follows and retain the current default for wEnv-defaultWorker: I'm not very comfortable with this ( I'm close to -1, but if other people think it's a good idea I can change it to -0). As noted, the proposed patch subtracts nothing from the present position, while
DataViz Sales - Auto Response
Please note: Your e-mail to DataViz was NOT received! Due to the increasing amount of SPAM and unsolicited e-mail received at this address, we no longer accept inquires submitted directly to this e-mail address. We ask that anyone wishing to contact us please do so through a form on our website. We apologize for the inconvenience, but this will benefit both you and our sales and customer service representatives, as they can respond much more quickly to your inquiry. Please visit the link below to re-submit your request. For your convenience, your original post is listed below. http://www.dataviz.com/contactdataviz Sincerely, The DataViz Sales Department Original Message Follows Please note: Your e-mail to DataViz was NOT received! Due to the increasing amount of SPAM and unsolicited e-mail received at this address, we no longer accept inquires submitted directly to this e-mail address. We ask that anyone wishing to contact us please do so through a form on our website. We apologize for the inconvenience, but this will benefit both you and our sales and customer service representatives, as they can respond much more quickly to your inquiry. Please visit the link below to re-submit your request. For your convenience, your original post is listed below. http://www.dataviz.com/contactdataviz Sincerely, The DataViz Sales Department Original Message Follows Good morning Costin. Thanks for the time given to replying. I agree with the ideas you have given, of decoupling URI's from workers explicitly tied to a communications protocol, but in reality this connectivity is supported and actually gives the minimum workable configuration. But given that a default architecture is but a 'guess', I see the programming to be 'cleaner' without such defaults and rather provide a 'default' configuration file that would achieve the same end. The present situation hides the basic building blocks of Mod_Jk2 and leads to the majority of questions in regard to how to reconfigure the module. Remove the ability of 'workers' to directly accept requests and force all URI's through an lb type, and the current default approach would be entirely appropriate. NormW wrote: Good morning All. The default 'worker', which is hard-wired into Mod_Jk2, is 'lb:lb', and is, for most users I believe, a wrong guess at best, since the majority of users are probably not using mod_jk2 in load-balancing mode. The 'guess' means that mod_jk2 creates uri objects assigned to either a load-balancer that doesn't exist , a load-balancer that is not hooked into anything or a load-balancer that is not even wanted. For example, the following uri's are created automatically: :-) I agree that lb is a missleading name, as is the whole worker concept. The real intent is for lb to represent one tomcat cluster ( of one or many servers ), and for routing to be directed to different clusters instead of individual machines. Even if you have a single tomcat - I think it is still better to make the mapping based on the tomcat instance, and not on the various protocols used to connect. The overhead of having lb is very small, and IMO it's well worth it given the simplification in code and the extra features. I also think the right direction is to decouple the worker ( as a particular protcol to connect to a tomcat instance ) from the notion of routing requests to a particular instance or cluster, which may use multipe protocols and workers. nameurigroup context * null null null *// lb:lb / Given the present arrangement, I can understand (if not support) the lb:lb uri entry above but the one assigned to a 'null' group with a uri of 'null' seems to be a bug. There is no means to determine the existence of the 'lb:lb' worker, but suffice to say, my setup doesn't want or need it anyway. (As an aside, perhaps this might be an extension to /jkstatus/ ?) I think the code created the lb:lb automatically unless one is defined exeplicitely. The goal was to have each tomcat instance ( or cluster ) associated with an lb, with a reasonable default to minimize trivial configuration. Then each lb would have one or
DataViz Sales - Auto Response
Please note: Your e-mail to DataViz was NOT received! Due to the increasing amount of SPAM and unsolicited e-mail received at this address, we no longer accept inquires submitted directly to this e-mail address. We ask that anyone wishing to contact us please do so through a form on our website. We apologize for the inconvenience, but this will benefit both you and our sales and customer service representatives, as they can respond much more quickly to your inquiry. Please visit the link below to re-submit your request. For your convenience, your original post is listed below. http://www.dataviz.com/contactdataviz Sincerely, The DataViz Sales Department Original Message Follows Please note: Your e-mail to DataViz was NOT received! Due to the increasing amount of SPAM and unsolicited e-mail received at this address, we no longer accept inquires submitted directly to this e-mail address. We ask that anyone wishing to contact us please do so through a form on our website. We apologize for the inconvenience, but this will benefit both you and our sales and customer service representatives, as they can respond much more quickly to your inquiry. Please visit the link below to re-submit your request. For your convenience, your original post is listed below. http://www.dataviz.com/contactdataviz Sincerely, The DataViz Sales Department Original Message Follows Please note: Your e-mail to DataViz was NOT received! Due to the increasing amount of SPAM and unsolicited e-mail received at this address, we no longer accept inquires submitted directly to this e-mail address. We ask that anyone wishing to contact us please do so through a form on our website. We apologize for the inconvenience, but this will benefit both you and our sales and customer service representatives, as they can respond much more quickly to your inquiry. Please visit the link below to re-submit your request. For your convenience, your original post is listed below. http://www.dataviz.com/contactdataviz Sincerely, The DataViz Sales Department Original Message Follows Good morning Costin. Thanks for the time given to replying. I agree with the ideas you have given, of decoupling URI's from workers explicitly tied to a communications protocol, but in reality this connectivity is supported and actually gives the minimum workable configuration. But given that a default architecture is but a 'guess', I see the programming to be 'cleaner' without such defaults and rather provide a 'default' configuration file that would achieve the same end. The present situation hides the basic building blocks of Mod_Jk2 and leads to the majority of questions in regard to how to reconfigure the module. Remove the ability of 'workers' to directly accept requests and force all URI's through an lb type, and the current default approach would be entirely appropriate. NormW wrote: Good morning All. The default 'worker', which is hard-wired into Mod_Jk2, is 'lb:lb', and is, for most users I believe, a wrong guess at best, since the majority of users are probably not using mod_jk2 in load-balancing mode. The 'guess' means that mod_jk2 creates uri objects assigned to either a load-balancer that doesn't exist , a load-balancer that is not hooked into anything or a load-balancer that is not even wanted. For example, the following uri's are created automatically: :-) I agree that lb is a missleading name, as is the whole worker concept. The real intent is for lb to represent one tomcat cluster ( of one or many servers ), and for routing to be directed to different clusters instead of individual machines. Even if you have a single tomcat - I think it is still better to make the mapping based on the tomcat instance, and not on the various protocols used to connect. The overhead of having lb is very small,
Your mail has been rejected
It appears that your message to DataViz, Inc. was bouncing between our server and yours. Generally, this will happen because you have an out-of-office e-mail reply activated or you submitted a form on our web site multiple times. Your e-mail address has been added to a bounce list. Any messages sent from an e-mail address on this list will be digested for 24 hours to stop this bouncing. At the end of the 24 hours, your e-mail address will be removed from the bounce list automatically. Therefore no further action on your part is necessary. Please contact Shaun Berner at (203) 874-0085 x3037 if you have any additional questions. The DataViz Web Team Original Message Follows Please note: Your e-mail to DataViz was NOT received! Due to the increasing amount of SPAM and unsolicited e-mail received at this address, we no longer accept inquires submitted directly to this e-mail address. We ask that anyone wishing to contact us please do so through a form on our website. We apologize for the inconvenience, but this will benefit both you and our sales and customer service representatives, as they can respond much more quickly to your inquiry. Please visit the link below to re-submit your request. For your convenience, your original post is listed below. http://www.dataviz.com/contactdataviz Sincerely, The DataViz Sales Department Original Message Follows Please note: Your e-mail to DataViz was NOT received! Due to the increasing amount of SPAM and unsolicited e-mail received at this address, we no longer accept inquires submitted directly to this e-mail address. We ask that anyone wishing to contact us please do so through a form on our website. We apologize for the inconvenience, but this will benefit both you and our sales and customer service representatives, as they can respond much more quickly to your inquiry. Please visit the link below to re-submit your request. For your convenience, your original post is listed below. http://www.dataviz.com/contactdataviz Sincerely, The DataViz Sales Department Original Message Follows Please note: Your e-mail to DataViz was NOT received! Due to the increasing amount of SPAM and unsolicited e-mail received at this address, we no longer accept inquires submitted directly to this e-mail address. We ask that anyone wishing to contact us please do so through a form on our website. We apologize for the inconvenience, but this will benefit both you and our sales and customer service representatives, as they can respond much more quickly to your inquiry. Please visit the link below to re-submit your request. For your convenience, your original post is listed below. http://www.dataviz.com/contactdataviz Sincerely, The DataViz Sales Department Original Message Follows Good morning Costin. Thanks for the time given to replying. I agree with the ideas you have given, of decoupling URI's from workers explicitly tied to a communications protocol, but in reality this connectivity is supported and actually gives the minimum workable configuration. But given that a default architecture is but a 'guess', I see the programming to be 'cleaner' without such defaults and rather provide a 'default' configuration file that would achieve the same end. The present situation hides the basic building blocks of Mod_Jk2 and leads to the majority of questions in regard to how to reconfigure the module. Remove the ability of 'workers' to directly accept requests and force all URI's through an lb type, and the current default approach would be entirely appropriate. NormW wrote: Good morning All. The default 'worker', which is hard-wired into Mod_Jk2, is 'lb:lb', and is, for most users I believe, a wrong guess at best, since the majority of users are probably not using mod_jk2 in load-balancing mode.
