Important
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Part-2.txt .exe (in Part-2.zip) The uncleanable file is deleted. - Important! -- Virus Warning Message (on uusnwa0p) -- Part-2.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30770] New: - Crash on missing user-agent / compression enabled
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=30770. 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=30770 Crash on missing user-agent / compression enabled Summary: Crash on missing user-agent / compression enabled Product: Tomcat 5 Version: 5.0.27 Platform: All OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Connector:HTTP AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When accessing tomcat (in standalone mode and compression=on) the server refuses to handle any request if there is no user-agent transferred. In catalina.out there is an exception noted: SCHWERWIEGEND: Error finishing response java.lang.NullPointerException at org.apache.coyote.http11.Http11Processor.isCompressable(Http11Processor.java:1379) at org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1441) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:892) at org.apache.coyote.Response.action(Response.java:180) at org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffer.java:388 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:836) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:536) The problem can be reproduced with the konqueror browser, there is an option not to send browser identification. If browser-identification is send everything goes right, if the switch is changed the error does occurr. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
possible bug in jspc
Hi, I've been chasing an inconsistency in the behaviour wrt jsp error page execution. in this case the error page is evaluated and flushed to the response html:link forward=boguslink logic:iterate name=currentLoggers id=logger in this case the error page is evaluated but is not flushed to the response logic:iterate name=currentLoggers id=logger html:link forward=boguslink I checked the struts tags and they're fine, I also checked on weblogic and the error page is flushed to response in both cases which makes me think it's a problem with the tomcat jsp compiler. bug? should I add it bugzilla? cheers Nathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs index.xml
yoavs 2004/08/20 04:21:04 Modified:webapps/docs index.xml Log: Minor typo fix, thanks Jan. Revision ChangesPath 1.17 +1 -1 jakarta-tomcat-catalina/webapps/docs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/index.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- index.xml 19 Aug 2004 19:43:03 - 1.16 +++ index.xml 20 Aug 2004 11:21:04 - 1.17 @@ -18,7 +18,7 @@ section name=Introduction pThis is the top-level entry point of the documentation bundle for the -strongApaache Jakarta Tomcat/strong Servlet/JSP container. Tomcat version 5 implements the +strongApache Jakarta Tomcat/strong Servlet/JSP container. Tomcat version 5 implements the Servlet 2.4 and JavaServer Pages 2.0 specifications from the a href=http://www.jcp.org;Java Community Process/a, and includes many additional features that make it a useful platform for developing and deploying - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30771] New: - Error registering contexts; with multiple services on fast box
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=30771. 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=30771 Error registering contexts; with multiple services on fast box Summary: Error registering contexts; with multiple services on fast box Product: Tomcat 5 Version: 5.0.27 Platform: Other OS/Version: FreeBSD Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The attached server.xml has 5 service defined, each with its own Connector, Engine and Host. I get a ConcurrentModificationException fault when starting Tomcat that breaks the context registration. The stack trace is shown in the attached cataline.out. My feeling is that this issue only occurs on a fast machine which is registering a whole series of services and there is unthread-safe code somewhere in the CoyoteConnector code or the underlying MBean system. I used the server-minimal.xml model to originate my server.xml (e.g. having Connector port=8013 /) but I found that including more attributes to that Connector entity (the standard attributes suggested in the default server.xml) caused the Error registering contexts fault to go away. This workaround does not work on the reproducible case I have prepared; my hunch is that this fault is highly time dependent - as I think it must a threading issues. My environment: FreeBSD 5.2.1 JDK 1.4.2 (patched for FreeBSD) Tomcat 5.0.27 Hardware: AMD Athlon XP 2800+, RAM 447MB Reproducible Case Do these things on a clean tomcat install: 1. cd CATALINA_HOME 2. mkdir -p testsite1/htdocs/WEB-INF 3. cp a clean web.xml testsite1/htdocs/WEB-INF 4. cp -r testsite1 testsite2 5. cp -r testsite1 testsite3 6. cp -r testsite1 testsite4 7. cp -r testsite1 testsite5 8. Replace conf/server.xml with the one I have attached to this case. 9. Start Tomcat 10. Inspect the catalina.out The symptom others may find this fault with (if you don't spot the Error registering contexts in catalina.out) is that the site that fails will return this HTTP header (which is a consequence of that site not being initialised properly): # curl -I http://localhost:8013/test.jsp HTTP/1.1 400 No Host matches server name localhost Transfer-Encoding: chunked Date: Fri, 20 Aug 2004 11:22:50 GMT Server: Apache-Coyote/1.1 Connection: close - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30771] - Error registering contexts; with multiple services on fast box
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=30771. 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=30771 Error registering contexts; with multiple services on fast box --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 11:29 --- Created an attachment (id=12497) catalina.out showing stack trace - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30771] - Error registering contexts; with multiple services on fast box
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=30771. 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=30771 Error registering contexts; with multiple services on fast box --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 11:30 --- Created an attachment (id=12498) server.xml for the reproducible case - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where's 4.1.31?
Hi, You can't expect a 4.1.31 anytime soon. It's in a maintenance mode where only Spec violations and security flaws are the things that would get a new release out. We suggest the same thing we've been suggesting for a while now, upgrade to 5.x. Yoav Shapira Millennium Research Informatics -Original Message- From: Tom Anderson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 19, 2004 9:32 PM To: Tomcat Developers List Subject: Where's 4.1.31? There have been some important bug fixes in the baseline since April that haven't made it to a release version yet. Are there plans to release another version of Tomcat 4.1? The changes I am interested in some fixes that were done by Glenn and Markt but some thought they might be too risky. But I applaud those changes since they could allow me to discard my own internal patches that I have had to make to address these same problems.Some of the problems/fixes I'm talking about are: 1. Inefficient database queries for persistent sessions 2. Session expiration problems caused by differing interpretations of the getLastAccessedTime() method 3. NPEs in StoreBase 4. Remove non-serializable attributes from sessions 5. Changed classes throw InvalidClassExceptions on de-serialization These seem like pretty significant issues to me and I doubt I'm the only one to have encountered them. Can I expect a new release any time soon? ~Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common/endorsed classLoader
Costin Manolache wrote: To make things a bit more interesting, I believe there are some checks in JDK1.4 to prevent you to override rt.jar classes. That's what endorsed really does, allow you to bypass those checks. I don't think we managed to get xerces and jaxp to load from a classloader even with delegation disabled. Xerces would certainly load. Do you really need Xerces' JAXP rather than that in 1.4? -- Jess Holle
Re: common/endorsed classLoader
Jess Holle wrote: Costin Manolache wrote: To make things a bit more interesting, I believe there are some checks in JDK1.4 to prevent you to override rt.jar classes. That's what endorsed really does, allow you to bypass those checks. I don't think we managed to get xerces and jaxp to load from a classloader even with delegation disabled. Xerces would certainly load. Do you really need Xerces' JAXP rather than that in 1.4? Yes, because in 1.4, Crimson is used and doesn't support XML schema. That's the only good reason we have to use Xerces when validating a web.xml. Note thatn in 1.5, Xerces packages have been renamed to com.sun.org.apache.xerces.*, which will resolve a lot of problem (ex: you should be able to bundle any xerces version in your war). I didn't test it yet -- Jeanfrancois -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common/endorsed classLoader
Jeanfrancois Arcand wrote: Jess Holle wrote: Costin Manolache wrote: To make things a bit more interesting, I believe there are some checks in JDK1.4 to prevent you to override rt.jar classes. That's what endorsed really does, allow you to bypass those checks. I don't think we managed to get xerces and jaxp to load from a classloader even with delegation disabled. Xerces would certainly load. Do you really need Xerces' JAXP rather than that in 1.4? Yes, because in 1.4, Crimson is used and doesn't support XML schema. That's the only good reason we have to use Xerces when validating a web.xml. Note thatn in 1.5, Xerces packages have been renamed to com.sun.org.apache.xerces.*, which will resolve a lot of problem (ex: you should be able to bundle any xerces version in your war). I didn't test it yet Xerces does not have to be endorsed or even be *the* endorsed JAXP XML implementation to be used for purposes like validating XML schema. One can simply directly use the given JAXP factory class -- or better yet use a loader that first tries for the 1.5 repackaged JAXP factory and then reverts to the standard Xerces class naming or some such. If this is not feasible (e.g. if the digester, etc, code involved simply grabs the currently defined JAXP implementation), one could always just have a given classloader force Xerces to be the JAXP implementation for everything within it (by redirecting request for the given meta-inf/services entries to define Xerces as the XML implementation). Such a classloader could also have the smarts not to do this in Java 1.5 Now if the 1.5 JAXP interfaces themselves render the current Xerces inoperable that is a bigger issue -- and one which I would have to chalk up as a serious design flaw in JAXP, i.e. one should not grow interfaces in such a way as to break all existing implementations -- rather one should add a sub-interface and provide APIs to request the sub-interface, etc. I sincerely hope Sun has not mis-stepped in such a major way with something as central as JAXP... -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security SecurityUtil.java
jfarcand2004/08/20 07:28:38
Modified:catalina/src/share/org/apache/catalina/security Tag:
TOMCAT_5_0 SecurityUtil.java
Log:
Fix for Bugzilla 30602: Subject is not available during the first call to the
servlet which use the basic authentication.
All Servlet TCKs passed with Security enabled
Submitted by: Josip Jureta at videotron.ca
Revision ChangesPath
No revision
No revision
1.11.2.1 +9 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityUtil.java
Index: SecurityUtil.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityUtil.java,v
retrieving revision 1.11
retrieving revision 1.11.2.1
diff -u -r1.11 -r1.11.2.1
--- SecurityUtil.java 26 May 2004 15:53:20 - 1.11
+++ SecurityUtil.java 20 Aug 2004 14:28:38 - 1.11.2.1
@@ -251,16 +251,18 @@
if (session != null){
subject =
(Subject)session.getAttribute(Globals.SUBJECT_ATTR);
+}
-if (subject == null){
-subject = new Subject();
-
-if (principal != null){
-subject.getPrincipals().add(principal);
-}
-session.setAttribute(Globals.SUBJECT_ATTR, subject);
+if (subject == null){
+subject = new Subject();
+
+if (principal != null){
+subject.getPrincipals().add(principal);
}
}
+
+if (session != null)
+session.setAttribute(Globals.SUBJECT_ATTR, subject);
}
Subject.doAsPrivileged(subject, pea, null);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
jfarcand2004/08/20 07:29:12 Modified:webapps/docs Tag: TOMCAT_5_0 changelog.xml Log: Update Revision ChangesPath No revision No revision 1.70.2.3 +3 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.70.2.2 retrieving revision 1.70.2.3 diff -u -r1.70.2.2 -r1.70.2.3 --- changelog.xml 11 Aug 2004 00:52:39 - 1.70.2.2 +++ changelog.xml 20 Aug 2004 14:29:11 - 1.70.2.3 @@ -22,6 +22,9 @@ subsection name=Catalina changelog + fix +bug30602/bug: Subject is not available during the first call to the servlet which use the basic authentication (jfarcand) + /fix /changelog /subsection - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30602] - Subject is not available during the first call to the servlet which use the basic authentication
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=30602. 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=30602 Subject is not available during the first call to the servlet which use the basic authentication [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 14:31 --- Fixed. Will be available in the next release of Tomcat 5. Merci :-) -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where's 4.1.31?
Yoav, I haven't RM'd a release yet but if you or another RM-pro is willing to show me what is involved I might be willing to wear the hat for 4.1.31. Here is how I understand the process: - tag and create a release canidate - email to announce@ - wait 48 hours for show stoppers - delcare the RC a release - email to announce@, update jakarta site I'd even be willing to document this process if it is not already. [EMAIL PROTECTED] -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 9:13 AM To: Tomcat Developers List Subject: RE: Where's 4.1.31? Hi, You can't expect a 4.1.31 anytime soon. It's in a maintenance mode where only Spec violations and security flaws are the things that would get a new release out. We suggest the same thing we've been suggesting for a while now, upgrade to 5.x. Yoav Shapira Millennium Research Informatics - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where's 4.1.31?
The offer to do this is great, but I am more than a little curious: Why would anyone bother with a 4.1.x upgrade at this point? 5.0.27 is faster, more stable, etc, at this point as best I can tell. -- Jess Holle Keith Wannamaker wrote: Yoav, I haven't RM'd a release yet but if you or another RM-pro is willing to show me what is involved I might be willing to wear the hat for 4.1.31. Here is how I understand the process: - tag and create a release canidate - email to announce@ - wait 48 hours for show stoppers - delcare the RC a release - email to announce@, update jakarta site I'd even be willing to document this process if it is not already. [EMAIL PROTECTED] -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 9:13 AM To: Tomcat Developers List Subject: RE: Where's 4.1.31? Hi, You can't expect a 4.1.31 anytime soon. It's in a maintenance mode where only Spec violations and security flaws are the things that would get a new release out. We suggest the same thing we've been suggesting for a while now, upgrade to 5.x. Yoav Shapira Millennium Research Informatics - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security SecurityUtil.java
jfarcand2004/08/20 07:43:17
Modified:catalina/src/share/org/apache/catalina/security
SecurityUtil.java
Log:
Port fix for bug 30602
Revision ChangesPath
1.12 +9 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityUtil.java
Index: SecurityUtil.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityUtil.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- SecurityUtil.java 26 May 2004 15:53:20 - 1.11
+++ SecurityUtil.java 20 Aug 2004 14:43:17 - 1.12
@@ -251,16 +251,18 @@
if (session != null){
subject =
(Subject)session.getAttribute(Globals.SUBJECT_ATTR);
+}
-if (subject == null){
-subject = new Subject();
-
-if (principal != null){
-subject.getPrincipals().add(principal);
-}
-session.setAttribute(Globals.SUBJECT_ATTR, subject);
+if (subject == null){
+subject = new Subject();
+
+if (principal != null){
+subject.getPrincipals().add(principal);
}
}
+
+if (session != null)
+session.setAttribute(Globals.SUBJECT_ATTR, subject);
}
Subject.doAsPrivileged(subject, pea, null);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where's 4.1.31?
Hi, The process is already somewhat documented. For example, http://cvs.apache.org/~yoavs/tomcatReleaseManager.html is my personal notes, and http://jakarta.apache.org/commons/releases/ is mostly Jakarta-general, not specific to Commons. It deviates from the process you posted in that we usually label a release alpha or beta, leave it out in the wild for a bit to give users a chance to use it, and then call it stable (with a new announcement). Tomcat RMing is more complicated than others due to the relative complexity of the product itself compared to most Apache products. There are many ways to screw it up as I've found out myself with my first couple of releases. In addition specifically for this, you'd have to backport patches committed to CVS HEAD to the TOMCAT_4_1 branch, which has significantly different code in many key modules. But that's not the issue here. I'd probably be willing to do the release if we decide one is needed. The issue is how long we maintain things. We don't want to be in the business of maintaining old branches forever. There's been a stable Tomcat 5 for more than a year now, and the past few months we've been closing Tomcat 4.1 bugs with the statement that it's not actively maintained and users should upgrade. This is of course a standard practice in many organizations. I don't want to introduce life into the 4.1 branch, have users using 4.1.31, filing new bugs against it, etc. We have very limited support resources as-is and it makes no sense to stretch them to old branches. Yoav Shapira Millennium Research Informatics -Original Message- From: Keith Wannamaker [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 10:34 AM To: Tomcat Developers List Subject: RE: Where's 4.1.31? Yoav, I haven't RM'd a release yet but if you or another RM-pro is willing to show me what is involved I might be willing to wear the hat for 4.1.31. Here is how I understand the process: - tag and create a release canidate - email to announce@ - wait 48 hours for show stoppers - delcare the RC a release - email to announce@, update jakarta site I'd even be willing to document this process if it is not already. [EMAIL PROTECTED] -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 9:13 AM To: Tomcat Developers List Subject: RE: Where's 4.1.31? Hi, You can't expect a 4.1.31 anytime soon. It's in a maintenance mode where only Spec violations and security flaws are the things that would get a new release out. We suggest the same thing we've been suggesting for a while now, upgrade to 5.x. Yoav Shapira Millennium Research Informatics - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where's 4.1.31?
Hi Jess, in our case we don't have the resources at this point in time to certify our product with a completely new code base. I'm sure different people have different reasons. Keith -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 10:38 AM To: Tomcat Developers List Subject: Re: Where's 4.1.31? The offer to do this is great, but I am more than a little curious: Why would anyone bother with a 4.1.x upgrade at this point? 5.0.27 is faster, more stable, etc, at this point as best I can tell. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where's 4.1.31?
Because a 4.1.x upgrade is not an api change. There is much more testing involved in upgrading to a new major version than a point release. The problem is finding the time to review the (possible)effects of 5.x on your installation and all your applications when you could roll out a point release with much less effort. Charlie -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 10:38 AM To: Tomcat Developers List Subject: Re: Where's 4.1.31? The offer to do this is great, but I am more than a little curious: Why would anyone bother with a 4.1.x upgrade at this point? 5.0.27 is faster, more stable, etc, at this point as best I can tell. -- Jess Holle Keith Wannamaker wrote: Yoav, I haven't RM'd a release yet but if you or another RM-pro is willing to show me what is involved I might be willing to wear the hat for 4.1.31. Here is how I understand the process: - tag and create a release canidate - email to announce@ - wait 48 hours for show stoppers - delcare the RC a release - email to announce@, update jakarta site I'd even be willing to document this process if it is not already. [EMAIL PROTECTED] -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 9:13 AM To: Tomcat Developers List Subject: RE: Where's 4.1.31? Hi, You can't expect a 4.1.31 anytime soon. It's in a maintenance mode where only Spec violations and security flaws are the things that would get a new release out. We suggest the same thing we've been suggesting for a while now, upgrade to 5.x. Yoav Shapira Millennium Research Informatics - 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 30774] New: - mod_jk2: It is not possible to set the AJP port to anything other than the default of 8009
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=30774.
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=30774
mod_jk2: It is not possible to set the AJP port to anything other than the default of
8009
Summary: mod_jk2: It is not possible to set the AJP port to
anything other than the default of 8009
Product: Tomcat 5
Version: 5.0.27
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: Major
Priority: Other
Component: Native:JK
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I need to run the Apache/Tomcat link using AJP on port 41503, using mod_jk2.so.
Using the following configuration:
# workers2.properties
#
[shm]
file=${serverRoot}/logs/shm.file
size=1048576
# define the worker
[status:status]
[channel.socket:localhost:41503]
host=localhost
port=41503
[ajp13:localhost:41503]
channel=channel.socket:localhost:41503
# Uri mapping
[uri:/jkstatus/*]
worker=status:status
[uri:/servlet/*]
worker=ajp13:localhost:41503
I've also tried several variations of the above.
# jk2.properties
# Override the default port for the socketChannel
channelSocket.port=41503
The /jkstatus page works as expected, and looks ok:
id namehosturi group context
0 nullnullnull
0 /jkstatus/* * /jkstatus/* status:status /
0 /servlet/* * /servlet/* ajp13:localhost:41503 /
0 * * nullnullnull
0 */ * / lb:lb /
Object name PropertyValue
config: file${serverRoot}/conf/workers2.properties
shm:file${serverRoot}/logs/shm.file
size1048576
ajp13:localhost:41503 channel channel.socket:localhost:41503
channel.socket:localhost:41503 hostlocalhost
port41503
uri:/jkstatus/* worker status:status
uri:/servlet/* worker ajp13:localhost:41503
NameValue
fs /
ps :
so so
archi386
serverRoot /wispers/opt/apache/ellis/external
file/wispers/opt/apache/ellis/external/conf/workers2.properties
shm:.file /wispers/opt/apache/ellis/external/logs/shm.file
shm:.size 1048576
channel.socket:localhost:41503.host localhost
channel.socket:localhost:41503.port 41503
ajp13:localhost:41503.channel channel.socket:localhost:41503
uri:/jkstatus/*.worker status:status
uri:/servlet/*.worker ajp13:localhost:41503
However, trying /servlet yields (in Apache's error_log):
[Fri Aug 20 16:03:44 2004] [notice] Apache/2.0.50 (Unix) mod_jk2/2.0.2 DAV/2
configured -- resuming normal operations
[Fri Aug 20 16:03:44 2004] [error] mod_jk child init 1 0
[Fri Aug 20 16:03:49 2004] [error] channelSocket.open() connect failed
localhost:8009 146 Connection refused
[Fri Aug 20 16:03:49 2004] [error] ajp13.connect() failed ajp13:localhost:41503
[Fri Aug 20 16:03:49 2004] [error] ajp13.service() failed to connect endpoint
errno=146 Connection refused
[Fri Aug 20 16:03:49 2004] [error] ajp13.service() Error forwarding
ajp13:localhost:41503 1 1
[Fri Aug 20 16:03:49 2004] [error] mod_jk.handler() Error connecting to tomcat
12
It's still trying to connect on port 8009!
I guess everyone else in the world is just using port 8009!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where's 4.1.31?
Hi Yoav, thanks for the release documentation. Do you mind if I check this in to jt-4.0? I think it would be very helpful. I am aware that 5.0 uses significantly different code which is in itself a good reason for continuing maintenance releases of 4.1. Backporting patches would be a nice side-improvement if it were done, but I think there have been enough fixes to 4.1 itself to warrant a new release without said backports. From a procedural standpoint, it is my understanding that the only vote needed is one to label a rc (ie beta or stable). Is that correct? If so, I'd like to be the 4.1.31 RM and I will go to work on syncing the release notes and get an rc out this weekend. Keith -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 10:44 AM To: Tomcat Developers List Subject: RE: Where's 4.1.31? Hi, The process is already somewhat documented. For example, http://cvs.apache.org/~yoavs/tomcatReleaseManager.html is my personal notes, and http://jakarta.apache.org/commons/releases/ is mostly Jakarta-general, not specific to Commons. It deviates from the process you posted in that we usually label a release alpha or beta, leave it out in the wild for a bit to give users a chance to use it, and then call it stable (with a new announcement). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30775] New: - tomcat will not find setter methods of a tag's superclass
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=30775. 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=30775 tomcat will not find setter methods of a tag's superclass Summary: tomcat will not find setter methods of a tag's superclass Product: Tomcat 5 Version: 5.0.27 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] - say you have a tld that defines a tag mylist and attribute called pageNumber. In the MyListTag you need a setter method called setPageNumber. Well, let's say that MyListTag extends an abstract class called ListTag and defines a non-abstract method called setPageNumber. You think you're ok.but you're not! Tomcat will not find the setter method in the superclass. - you must explicity define setPageNumber in the subclass...yuck! - Resin handles this perfectly fine and so should you guys! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where's 4.1.31?
Keith Wannamaker wrote: Hi Jess, in our case we don't have the resources at this point in time to certify our product with a completely new code base. Hmmm... As someone who distributes Tomcat 4.1.x and 5.0.x to a broad customer base I see Tomcat 5.0.x certification as a 100% necessity for the future/present and see the incremental effort of verifying a new 4.1.x release as wasted when it could be focused on a 5.0.x verification against past and current releases of our own product. Then again I believe I have a pretty good record of all changes that were required to our product for Tomcat 5 for future releases that could be backed into previous ones... I'm sure different people have different reasons. Yes, I echo Yoav's sentiment, though that the community needs to focus on 5.0.x and beyond and really help push mindshare away from 3.x and 4.x releases. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where's 4.1.31?
Cox, Charlie wrote: Because a 4.1.x upgrade is not an api change. There is much more testing involved in upgrading to a new major version than a point release. The problem is finding the time to review the (possible)effects of 5.x on your installation and all your applications when you could roll out a point release with much less effort. Unless your app is not moving into the future this should have already been done with 5.x by this point (just possibly not yet deployed) -- right? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30775] - tomcat will not find setter methods of a tag's superclass
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=30775. 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=30775 tomcat will not find setter methods of a tag's superclass --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 16:26 --- well, I actually found out that Tomcat does work ok with inheritance. Apparently, tomcat doesn't like an attribute on a tag called pageNumber. It will complain the the setter method is not found, even though it's there. It also complains about pageNum. pageN, pageNo, pageNu, pageNumb all work fine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where's 4.1.31?
Hi, I agree with Jess, this is the wrong direction in principle. We're encouraging users to stick with 4.1.x if we do this release. Normally we have just an informal if everyone is OK with this, I'd like to push out release X on this day and then a vote on labeling it as stable. The latter being the only official vote. But in this case, I'd want to have a more general vote of should we have 4.1.x maintenance releases, given the reasons stated earlier in this thread. If we have such a vote, and if it passes, and if you decide to go ahead with this release, then you will probably assume responsibility for bugs filed against 4.1.x. This is of course unofficial, but nonetheless this type of arrangement exists with Tomcat 3.3.x. None of us care much for the 4.1.x issues now, except that Mark moved the relevant Connector-related issues from 4.1.x to 5.0.x so that they don't get dropped. This type of move, which I didn't like originally, should definitely be stopped if 4.1.x is still in active development as indicated by regular releases. Man this is a bummer going into the weekend ;) Yoav Shapira Millennium Research Informatics -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 12:15 PM To: Tomcat Developers List Subject: Re: Where's 4.1.31? Keith Wannamaker wrote: Hi Jess, in our case we don't have the resources at this point in time to certify our product with a completely new code base. Hmmm... As someone who distributes Tomcat 4.1.x and 5.0.x to a broad customer base I see Tomcat 5.0.x certification as a 100% necessity for the future/present and see the incremental effort of verifying a new 4.1.x release as wasted when it could be focused on a 5.0.x verification against past and current releases of our own product. Then again I believe I have a pretty good record of all changes that were required to our product for Tomcat 5 for future releases that could be backed into previous ones... I'm sure different people have different reasons. Yes, I echo Yoav's sentiment, though that the community needs to focus on 5.0.x and beyond and really help push mindshare away from 3.x and 4.x releases. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where's 4.1.31?
I've said too much on this already, but if you really need 4.1.x and bug fixes thereto, then why not take Tomcat 4.1.30 and patch it as necessary to address bugs of sufficient concern and deliver that to your customer/user base? That seems like a better solution for all than a 4.1.31 release. -- Jess Holle Shapira, Yoav wrote: Hi, I agree with Jess, this is the wrong direction in principle. We're encouraging users to stick with 4.1.x if we do this release. Normally we have just an informal if everyone is OK with this, I'd like to push out release X on this day and then a vote on labeling it as stable. The latter being the only official vote. But in this case, I'd want to have a more general vote of should we have 4.1.x maintenance releases, given the reasons stated earlier in this thread. If we have such a vote, and if it passes, and if you decide to go ahead with this release, then you will probably assume responsibility for bugs filed against 4.1.x. This is of course unofficial, but nonetheless this type of arrangement exists with Tomcat 3.3.x. None of us care much for the 4.1.x issues now, except that Mark moved the relevant Connector-related issues from 4.1.x to 5.0.x so that they don't get dropped. This type of move, which I didn't like originally, should definitely be stopped if 4.1.x is still in active development as indicated by regular releases. Man this is a bummer going into the weekend ;) Yoav Shapira Millennium Research Informatics - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where's 4.1.31?
Shapira, Yoav wrote: Hi, I agree with Jess, this is the wrong direction in principle. We're encouraging users to stick with 4.1.x if we do this release. Normally we have just an informal if everyone is OK with this, I'd like to push out release X on this day and then a vote on labeling it as stable. The latter being the only official vote. But in this case, I'd want to have a more general vote of should we have 4.1.x maintenance releases, given the reasons stated earlier in this thread. If we have such a vote, and if it passes, You have my -1 for a release. Althrough I agree with peoples that can't move to Tomcat 5, Tomcat 5 has been available for more that 1 year. That will be good for Tomcat if people migrate from 4.1.x to 5 and find bugs (that way they will not be carried into 5.5/6). and if you decide to go ahead with this release, then you will probably assume responsibility for bugs filed against 4.1.x. This is of course unofficial, but nonetheless this type of arrangement exists with Tomcat 3.3.x. 3.3.x has been maintained because of the fork between 3.3 and 4.x. There is no longer such tension now None of us care much for the 4.1.x issues now, except that Mark moved the relevant Connector-related issues from 4.1.x to 5.0.x so that they don't get dropped. This type of move, which I didn't like originally, should definitely be stopped if 4.1.x is still in active development as indicated by regular releases. Your time is more important on 5.x IMO :-) --Jeanfrancois Man this is a bummer going into the weekend ;) Yoav Shapira Millennium Research Informatics -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 12:15 PM To: Tomcat Developers List Subject: Re: Where's 4.1.31? Keith Wannamaker wrote: Hi Jess, in our case we don't have the resources at this point in time to certify our product with a completely new code base. Hmmm... As someone who distributes Tomcat 4.1.x and 5.0.x to a broad customer base I see Tomcat 5.0.x certification as a 100% necessity for the future/present and see the incremental effort of verifying a new 4.1.x release as wasted when it could be focused on a 5.0.x verification against past and current releases of our own product. Then again I believe I have a pretty good record of all changes that were required to our product for Tomcat 5 for future releases that could be backed into previous ones... I'm sure different people have different reasons. Yes, I echo Yoav's sentiment, though that the community needs to focus on 5.0.x and beyond and really help push mindshare away from 3.x and 4.x releases. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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 30775] - tomcat will not find setter methods of a tag's superclass
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=30775. 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=30775 tomcat will not find setter methods of a tag's superclass --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 16:59 --- ok, pageNo doesn't work either...must be anything that starts with page - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where's 4.1.31?
Patching Tomcat 4.1.30 is pretty much what I have done. I spent a lot of effort getting our installation working in a stable way. And a lot of that effort was in applying patches similar to the ones that are in the baseline but have never been released. As far as moving to Tomcat 5.x, I have a ton of applications running on 4.1.x and moving them forward is no small task for me. In fact, the effort of stabilizing Tomcat 4.1.x has me gun shy. I will probably wait a year or so more until I know things are REALLY good and stable first. Eventually I will have to bite the bullet and do so but I thought it might be nice to get a 4.1.31 release (which adds a ton of stability fixes) in the interim so I could remove my custom patches. Charlie Cox hit it on the head with his response: Because a 4.1.x upgrade is not an api change. There is much more testing involved in upgrading to a new major version than a point release. The problem is finding the time to review the (possible)effects of 5.x on your installation and all your applications when you could roll out a point release with much less effort. I appreciate everyone's feedback and understand why you don't want to release a new 4.1.x. I don't necessarily agree it's a good thing since there are a lot of installations of 4.1 out there that would benefit, but I can live with it. Maybe I'll be back next year with questions about 5.1. ;-) Sorry for rocking the boat and thanks, ~Tom On Aug 20, 2004, at 10:35 AM, Jess Holle wrote: I've said too much on this already, but if you really need 4.1.x and bug fixes thereto, then why not take Tomcat 4.1.30 and patch it as necessary to address bugs of sufficient concern and deliver that to your customer/user base? That seems like a better solution for all than a 4.1.31 release. -- Jess Holle Shapira, Yoav wrote: Hi, I agree with Jess, this is the wrong direction in principle. We're encouraging users to stick with 4.1.x if we do this release. Normally we have just an informal if everyone is OK with this, I'd like to push out release X on this day and then a vote on labeling it as stable. The latter being the only official vote. But in this case, I'd want to have a more general vote of should we have 4.1.x maintenance releases, given the reasons stated earlier in this thread. If we have such a vote, and if it passes, and if you decide to go ahead with this release, then you will probably assume responsibility for bugs filed against 4.1.x. This is of course unofficial, but nonetheless this type of arrangement exists with Tomcat 3.3.x. None of us care much for the 4.1.x issues now, except that Mark moved the relevant Connector-related issues from 4.1.x to 5.0.x so that they don't get dropped. This type of move, which I didn't like originally, should definitely be stopped if 4.1.x is still in active development as indicated by regular releases. Man this is a bummer going into the weekend ;) Yoav Shapira Millennium Research Informatics - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] 4.1.31 maintenance release
Hi, I propose to apply pending bugzilla 4.1 patches and issue a 4.1.31 release. The existance of unreleased committed fixes, unapplied patches, and multiple requests for 4.1.31 on tomcat-dev clearly represent an interest in a maintenance relase of 4.1.31. I volunteer to be the RM for this release. Voting will run till Monday night due to the weekend, then I will tally the results. ballot The 4.1.31 maintenance release should happen: [ ] Yes [ ] No /ballot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where's 4.1.31?
Hi Jeanfrancois, we share enthusiasm but not opinions. I believe since there are pending 4.1 patches in bugzilla and committed 4.1 fixes then there is clearly an interest in preserving the 4.1 tree in maintenance mode, and that means maintenance releases. My understanding of the jakarta PMC guidelines is that a release plan is a lazy majority vote, so your -1 would trigger a majority vote on a 4.1.31 release. So, I will issue a vote on this release. Keith -Original Message- From: Jeanfrancois Arcand [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 12:46 PM To: Tomcat Developers List Subject: Re: Where's 4.1.31? You have my -1 for a release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] 4.1.31 maintenance release
Hi, ballot The 4.1.31 maintenance release should happen: [ ] Yes [ X ] No /ballot -1 on this release. Reasons have been stated in detail in the other thread, but to summarize this branch is no longer maintained and users should upgrade to 5.x or custom-patch if they have an emergency. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where's 4.1.31?
I really hate comments like this. I'm glad you have plenty of free time to upgrade to 5.x. When Tomcat 5.x was released, I was already midstream in replacing IIS/ASP with Tomcat 4.1 and I'm happy to be able to do just that. Now we're focusing on business needs and less on upgrading something that is already 100% more stable and less buggy than IIS. So right now from a business perspective, upgrading because it's there is not a reason to upgrade. If I perceive that 4.x is slow for my application, then I have a reason to upgrade. If I need the new listeners, status monitor, or other enhancements, then I will consider an upgrade. This is about filling a need, which 4.x does for me right now. 5.x would fill that need as well (probably improved performance - I'll need to test it) but offers nothing that I must have right now. Am I concerned about performance? Yes. Is the current 4.1 performance bad? No. There are nice-to-haves, but not enough to trump my current workload. Nothing against 5.x, but it's not a priority for me yet. I'm impartial about another 4.1 release(no problems for me), and I don't expect it to be supported forever, however I get annoyed by people assuming that I have already implemented a newer version without realizing the potential effort required. We'll get there as time allows or requirements demand but not just because it's available. Charlie -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 12:16 PM To: Tomcat Developers List Subject: Re: Where's 4.1.31? Cox, Charlie wrote: Because a 4.1.x upgrade is not an api change. There is much more testing involved in upgrading to a new major version than a point release. The problem is finding the time to review the (possible)effects of 5.x on your installation and all your applications when you could roll out a point release with much less effort. Unless your app is not moving into the future this should have already been done with 5.x by this point (just possibly not yet deployed) -- right? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] 4.1.31 maintenance release
ballot The 4.1.31 maintenance release should happen: [X] Yes [ ] No /ballot Just such a thing has been on my mind for a while. Whilst in an ideal world everyone would migrate to 5.x, I have seen many organisations prefer to stay on earlier versions of software for a variety of reasons. I think a 4.1.31 release would be of benefit to these users. Given that there is some interest in this release and Keith is prepared to take on the role of RM I am happy to support it. I don't see this as detracting from the 5.x branch, rather supporting those users who, for whatever reason, are unable/unwilling to upgrade. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30768] - Servlet Filter setCharacterEncoding not work and Enable JAAS mechanism
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=30768. 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=30768 Servlet Filter setCharacterEncoding not work and Enable JAAS mechanism --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 18:21 --- I can't see anything in the source that would cause this. Please attach your server.xml and web.xml so I can see how things are configured. I am going to have to try and reproduce this before I try fixing it. A WAR for the simplest app that has this bug would be very helpful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30771] - Error registering contexts; with multiple services on fast box
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=30771. 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=30771 Error registering contexts; with multiple services on fast box [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 18:28 --- *** This bug has been marked as a duplicate of 29671 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29671] - Context don't start with multiple HTTP 1.1 connectors
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=29671. 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=29671 Context don't start with multiple HTTP 1.1 connectors [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 18:28 --- *** Bug 30771 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 4.1.31 maintenance release
ballot The 4.1.31 maintenance release should happen: [X] Yes [ ] No /ballot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes CookieExample.java HelloWorldExample.java JndiServlet.java RequestHeaderExample.java RequestInfoExample.java RequestParamExample.java SessionExample.java servletToJsp.java
markt 2004/08/20 11:42:27 Modified:webapps/examples/WEB-INF/classes CookieExample.java HelloWorldExample.java JndiServlet.java RequestHeaderExample.java RequestInfoExample.java RequestParamExample.java SessionExample.java servletToJsp.java Log: Fix bug 6218. Provide support for renaming the examples context without breaking the examples Also removed unused imports ID'd by Eclipse. Revision ChangesPath 1.4 +13 -13 jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/CookieExample.java Index: CookieExample.java === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/CookieExample.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- CookieExample.java23 Apr 2002 15:17:25 - 1.3 +++ CookieExample.java20 Aug 2004 18:42:26 - 1.4 @@ -3,7 +3,6 @@ */ import java.io.*; -import java.text.*; import java.util.*; import javax.servlet.*; import javax.servlet.http.*; @@ -36,18 +35,19 @@ out.println(/head); out.println(body); - // relative links - -// XXX -// making these absolute till we work out the -// addition of a PathInfo issue - -out.println(a href=\/examples/servlets/cookies.html\); -out.println(img src=\/examples/images/code.gif\ height=24 + +// Can't use relative links as the addition of pathinfo to the URI +// breaks relative links. Therefore use absolute links but don't hard +// code the context name so webapp can be deployed as different context +// and will still work. +String context = request.getContextPath(); + +out.println(a href=\ + context + /servlets/cookies.html\); +out.println(img src=\ + context + /images/code.gif\ height=24 + width=24 align=right border=0 alt=\view code\/a); -out.println(a href=\/examples/servlets/index.html\); -out.println(img src=\/examples/images/return.gif\ height=24 + -width=24 align=right border=0 alt=\return\/a); +out.println(a href=\ + context + /servlets/index.html\); +out.println(img src=\ + context + /images/return.gif\ + +height=24 width=24 align=right border=0 alt=\return\ + +/a); out.println(h3 + title + /h3); 1.3 +14 -16 jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/HelloWorldExample.java Index: HelloWorldExample.java === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/HelloWorldExample.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- HelloWorldExample.java29 Nov 2001 18:27:25 - 1.2 +++ HelloWorldExample.java20 Aug 2004 18:42:26 - 1.3 @@ -3,7 +3,6 @@ */ import java.io.*; -import java.text.*; import java.util.*; import javax.servlet.*; import javax.servlet.http.*; @@ -35,21 +34,20 @@ out.println(/head); out.println(body bgcolor=\white\); - // note that all links are created to be relative. this - // ensures that we can move the web application that this - // servlet belongs to to a different place in the url - // tree and not have any harmful side effects. - -// XXX -// making these absolute till we work out the -// addition of a PathInfo issue - - out.println(a href=\/examples/servlets/helloworld.html\); -out.println(img src=\/examples/images/code.gif\ height=24 + +// Can't use relative links as the addition of pathinfo to the URI +// breaks relative links. Therefore use absolute links but don't hard +// code the context name so webapp can be deployed as different context +// and will still work. +String context = request.getContextPath(); + + out.println(a href=\ + context + /servlets/helloworld.html\); +out.println(img src=\ + context + /images/code.gif\ height=24 + width=24 align=right border=0 alt=\view code\/a); -out.println(a href=\/examples/servlets/index.html\); -out.println(img src=\/examples/images/return.gif\ height=24 + -width=24 align=right border=0 alt=\return\/a); +out.println(a href=\ + context + /servlets/index.html\); +out.println(img src=\ + context + /images/return.gif\ + +height=24 width=24 align=right border=0 alt=\return\ + +/a); + out.println(h1 + title + /h1);
Karma for jakarta-servlet-*
There are some bugs in the examples I want to fix. AFAIK we can fix these but we can't change any of the API stuff - right? Anyway, how do I go about getting karma for these packages? Thanks, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 6218] - Relative links broken for servlets
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=6218. 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=6218 Relative links broken for servlets [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 18:46 --- This has been fixed in CVS for TC4. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Karma for jakarta-servlet-*
Mark, I can't give you karma, but one thing I recommend is you post the patch here first so the spec leads can take a look to make sure the previous specs is not impacted by the changes. Just recommending.no need to vote ;-) Thanks -- Jeanfrancois Mark Thomas wrote: There are some bugs in the examples I want to fix. AFAIK we can fix these but we can't change any of the API stuff - right? Anyway, how do I go about getting karma for these packages? Thanks, Mark - 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: Karma for jakarta-servlet-*
Hi, I thought karma for these modules was restricted to members of the servlet expert group. So we can post patches to Bugzilla and they'll apply them. Yoav Shapira Millennium Research Informatics -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 2:44 PM To: 'Tomcat Developers List' Subject: Karma for jakarta-servlet-* There are some bugs in the examples I want to fix. AFAIK we can fix these but we can't change any of the API stuff - right? Anyway, how do I go about getting karma for these packages? Thanks, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where's 4.1.31?
Cox, Charlie wrote: I really hate comments like this. I'm glad you have plenty of free time to upgrade to 5.x. Sorry to rankle you, but let's be honest -- if you want to be able to move forward you have to keep looking ahead. Either your app is so portable (and likely thus rather simple) that feel you can just snag the latest servlet engine du jour and use it -- or you keep an eye to (and some testing time slated for) future versions of servlet engines (and other components) you use. If your app is in pure maintenance mode and you're not moving it forward, then by all means pull back 1 patch at a time as appropriate. So right now from a business perspective, upgrading because it's there is not a reason to upgrade. If I perceive that 4.x is slow for my application, then I have a reason to upgrade. If I need the new listeners, status monitor, or other enhancements, then I will consider an upgrade. Getting all the bug fixes that would be in a hypothetical 4.1.31 (and setting yourself up to get those that would be in a hypothetical 4.1.32 and those that are already in 5.0.27 for that matter) are quite possibly ample reasons for one to upgrade -- and are a lot more than because it is there. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Remove - There is no user by that name at this server.
Remove - There is no user by that name at this server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Remove - There is no user by that name at this server.
Remove - There is no user by that name at this server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Remove - There is no user by that name at this server.
Remove - There is no user by that name at this server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Remove - There is no user by that name at this server.
Remove - There is no user by that name at this server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Remove - There is no user by that name at this server.
Remove - There is no user by that name at this server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Remove - There is no user by that name at this server.
Remove - There is no user by that name at this server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Remove - There is no user by that name at this server.
Remove - There is no user by that name at this server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Remove - There is no user by that name at this server.
Remove - There is no user by that name at this server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Remove - There is no user by that name at this server.
Remove - There is no user by that name at this server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Remove - There is no user by that name at this server.
Remove - There is no user by that name at this server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30778] New: - Cannot split open and close action tags across included files
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=30778. 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=30778 Cannot split open and close action tags across included files Summary: Cannot split open and close action tags across included files Product: Tomcat 5 Version: 5.0.27 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] It appears that Jasper is trying to validate a file included via the include directive instead of waiting to validate the parent page after inclusions have been performed. Here's a simple test case (just dump the pages into webapps/ROOT): split.jsp: -- %@ page contentType=text/plain % %@ include file=splitHeader.jspf % Body %@ include file=splitFooter.jspf % splitHeader.jspf: - jsp:useBean id=now class=java.util.Date Header splitFooter.jspf: - Footer /jsp:useBean This results in: org.apache.jasper.JasperException: /split.jsp(3,0) /splitHeader.jspf(1,46) Unterminated lt;jsp:useBean tag org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:39) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:407) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:90) org.apache.jasper.compiler.Parser.processIncludeDirective(Parser.java:339) org.apache.jasper.compiler.Parser.parseIncludeDirective(Parser.java:372) org.apache.jasper.compiler.Parser.parseDirective(Parser.java:475) org.apache.jasper.compiler.Parser.parseElements(Parser.java:1539) org.apache.jasper.compiler.Parser.parse(Parser.java:126) org.apache.jasper.compiler.ParserController.doParse(ParserController.java:220) org.apache.jasper.compiler.ParserController.parse(ParserController.java:101) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:203) org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) For comparison, here's what WLS 8.1 SP3 outputs: Header Body Footer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30775] - tomcat will not find setter methods of a tag's superclass
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=30775. 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=30775 tomcat will not find setter methods of a tag's superclass [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 20:05 --- actually this is my bad. I had a getter that returned an int and a setter that takes a String. The beans api won't recognize the two methods in this case, only one of them. Sorry about that... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30778] - Cannot split open and close action tags across included files
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=30778. 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=30778 Cannot split open and close action tags across included files [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 20:36 --- According JSP.1.3.3 of 2.0 spec, the start and end tags must be in the same file. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 4.1.31 maintenance release
ballot The 4.1.31 maintenance release should happen: [ X ] Yes [ ] No /ballot I would benefit directly from many of the fixes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30780] New: - JSTL tags don't work for jsp (xml) documents
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=30780.
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=30780
JSTL tags don't work for jsp (xml) documents
Summary: JSTL tags don't work for jsp (xml) documents
Product: Tomcat 5
Version: 5.0.27
Platform: PC
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hi,
JTSL tags don't work as expected in an xml formatted jsp file.
e.g.
my page starts off
jsp:root xmlns:jsp=http://java.sun.com/JSP/Page; version=2.0
xmlns:jsai=/tld/jsai
xmlns:spring=/spring
xmlns:c=http://java.sun.com/jsp/jstl/core;
the http://java.sun.com/jsp/jstl/core namespace is bound to c: as a prefix
later in my document I have:
spring:bind path=searcher.itemVendor
c:if test=${status.error}font
color=red${status.errorMessage}/font/c:if
/spring:bind
This doesn't work unless I enter it as:
spring:bind path=searcher.itemVendor
c:if test=${status.error} xmlns:c=http://java.sun.com/jsp/jstl/core;
font color=red${status.errorMessage}/font/c:if
/spring:bind
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30780] - JSTL tags don't work for jsp (xml) documents
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=30780. 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=30780 JSTL tags don't work for jsp (xml) documents --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 21:06 --- By the rules of xml namespaces there is no difference between the two. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30780] - JSTL tags don't work for jsp (xml) documents
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=30780. 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=30780 JSTL tags don't work for jsp (xml) documents --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 21:29 --- Can you attach a reproducible test case (war) that also contains the remaining taglibs bound to jsai and spring? I'm pretty positive this is working, otherwise some of the examples in the jsp-examples WAR would also fail, since they nest JSTL tags inside other custom tags without having to redeclare the c namespace. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11561] - JNDI problem with jdk1.4
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=11561. 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=11561 JNDI problem with jdk1.4 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 22:06 --- A simple test lookup works for me using the latest CVS source. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30780] - JSTL tags don't work for jsp (xml) documents
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=30780. 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=30780 JSTL tags don't work for jsp (xml) documents --- Additional Comments From [EMAIL PROTECTED] 2004-08-20 22:23 --- Hi, Sorry yes it is working. The JSTL 1.1 jars didn't get transferred to my WEB-INF/lib directory. The xml format doesn't throw an error when it can't find jars. (or rather when the declared namespace isn't bound to a tag lib which is correct from both a conceptual pov and complies with the JSP 2.0 spec ) I found my problem when I converted an xml jsp to a regular jsp to try to see why the example worked but my page didn't. The regular jsp threw an exception. by changing my namespace declaration to: xmlns:c=urn:jsptld:http://java.sun.com/jsp/jstl/core; I get an error if I mispell the uri or if the taglib isn't available. Sorry for the wasted time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 4.1.31 maintenance release
Its maintained if there is a committer who will apply the patches. Mark has been very good at doing this. For large companies - it takes (a lot) time to upgrade versions. I'm still stuck on 4.0.4 for all of my servers. (Soon to be 5 if all goes well) Stability is more important than speed and features. It took a lot of versions of 4.1 and 5.0 before it was stable. Even the first stable releases still had minor problems that got reported, were true and would have been problems for my environment. We stayed on 4.0.4 forever because all of the bugs that existed for that version (and old non-coyote connector) did not affect us. If there are people willing to maintain the branch, I think its worthwhile to have a release. -Tim Shapira, Yoav wrote: Hi, ballot The 4.1.31 maintenance release should happen: [ ] Yes [ X ] No /ballot -1 on this release. Reasons have been stated in detail in the other thread, but to summarize this branch is no longer maintained and users should upgrade to 5.x or custom-patch if they have an emergency. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: catalina seesion-id prediction (fwd)
Hi Zvi, Thank you for sending the paper. It's interesting, well-researched, and makes good points. Congratulations on completing it and presumably your PhD soon ;) I have a few comments: - In Tomcat, java.security.SecureRandom and not java.util.Random is the default generator, so as described in the first paragraph of section 5.2 a general PRNG attack will not be effective against an out-of-the-box Tomcat. - Your analysis of the toString method's weakness is fascinating. It is indeed a JVM implementation matter, as it's always a native method, and as such it's less in the scope of the Tomcat implementator and more in that of the JVM implementor. - You omitted the following details, which are significant in my opinion to the analysis as it applies to Tomcat. Tomcat: -- Encourages the user to specify a custom entropy value easily as a String. This value would not available to an attacker. Our documentation suggests using this attribute in security-conscious environment. Furthermore, this value may be derived from a program (including /dev/random) and changed with every run of the server. -- Allows the user to plug in any implementation they wish of java.util.Random to fit their security requirements. -- Allows the user to substitute any Manager implementation they wish and completely implement the session ID generation scheme as their security requirements dictate. It is only fair to mention these pluses as you analyze the minuses of Tomcat's session ID generation scheme. Because of these options, I personally think we've made a great tradeoff between security for the common user and flexbility for security-conscious servers. I don't anticipate any action or changes in our implementation resulting from your paper. - The final point is minor, but I wanted to mention it as your bibliography is otherwise nicely done: you have no reference to the Tomcat site itself (jakarta.apache.org/Tomcat). That would be appreciated. I'm copying the tomcat-dev list on this message, so that the discussion is logged in our archives. Please feel free to subscribe (send email to [EMAIL PROTECTED]) to the list and discuss this paper further. I am of course not posting the paper to the list, as it's your property, but I'm sure other developers will find it interesting as well should you be inclined to post it. Thanks again ;) Yoav Shapira --- Zvi Gutterman [EMAIL PROTECTED] wrote: Hello, I want to make sure I get to the right people. thanks, Zvi. -- Forwarded message -- Date: Wed, 18 Aug 2004 16:45:55 +0300 (IDT) From: Zvi Gutterman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: catalina seesion-id prediction Hello, My name is Zvi Gutterman and I am a PhD student from the Hebrew university in Jerusalem, Israel. Together with my advisor, prof. Dahlia Malkhi, we studied the Catalina session-id generation algorithm. Our results (see attached paper) show that Jakarta servers not using /dev/random may be vulnerable to session id prediction. The paper will be presented in the RSA 2005 conference (to be held in Feb 2005). You may want to consider a change in the session-id generation scheme. If you need any help or want to discuss our prediction algorithm I will be happy to assist. regards, Zvi. ATTACHMENT part 2 application/pdf name=ServletsAttack.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat-dev Digest 20 Aug 2004 14:34:27 -0000 Issue 2211
hi Michael Thanks for your suggestion. But after taking a look at opensta, I think it cannot work as my wish. I hope I can record all traffic on server side, because it is not convinient to deploy sush system on client side. Any other suggestion :=) best wishes, xudong --- You don't have to go inside Tomcat to do such thing. I think you can use some external tools to do this. For example, a free open source tool -- OpenSTA from http://www.opensta.org You can record all traffic to the server, modify your script to do certain session, and play back. --Michael -Original Message- From: xudong [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 18, 2004 8:00 PM To: [EMAIL PROTECTED] Subject: capture HTML pages under TOMCAT hi all, I want to do such a thing: Capture all HTTP request/response according to a specified session id under Tomcat. Then I could find the backgrounds of errors by *play* these pages. I think I have to understand the architecture of Tomcat first, then find the way to add some plugin(maybe change Tomcat's source codes directly). Am I right? But where I could find the related documents about the architecture of Tomcat? Any suggestion will be very important for me. Thanks. best wishes, xudong - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
billbarker2004/08/20 19:51:37
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
Check that the browser actually sent a user-agent header before using it.
Fix for Bug #30770
Reported By: Elmar Haneke [EMAIL PROTECTED]
Revision ChangesPath
1.104 +15 -11
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.103
retrieving revision 1.104
diff -u -r1.103 -r1.104
--- Http11Processor.java 12 Aug 2004 21:46:41 - 1.103
+++ Http11Processor.java 21 Aug 2004 02:51:37 - 1.104
@@ -1154,12 +1154,14 @@
request.getMimeHeaders().getValue(user-agent);
// Check in the restricted list, and adjust the http11
// and keepAlive flags accordingly
-String userAgentValue = userAgentValueMB.toString();
-for (int i = 0; i restrictedUserAgents.length; i++) {
-if (restrictedUserAgents[i].match(userAgentValue)) {
-http11 = false;
-keepAlive = false;
-break;
+if(userAgentValueMB != null) {
+String userAgentValue = userAgentValueMB.toString();
+for (int i = 0; i restrictedUserAgents.length; i++) {
+if (restrictedUserAgents[i].match(userAgentValue)) {
+http11 = false;
+keepAlive = false;
+break;
+}
}
}
}
@@ -1376,12 +1378,14 @@
if (noCompressionUserAgents != null) {
MessageBytes userAgentValueMB =
request.getMimeHeaders().getValue(user-agent);
-String userAgentValue = userAgentValueMB.toString();
+if(userAgentValueMB != null) {
+String userAgentValue = userAgentValueMB.toString();
-// If one Regexp rule match, disable compression
-for (int i = 0; i noCompressionUserAgents.length; i++)
-if (noCompressionUserAgents[i].match(userAgentValue))
-return false;
+// If one Regexp rule match, disable compression
+for (int i = 0; i noCompressionUserAgents.length; i++)
+if (noCompressionUserAgents[i].match(userAgentValue))
+return false;
+}
}
// Check if suffisant len to trig the compression
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30770] - Crash on missing user-agent / compression enabled
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=30770. 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=30770 Crash on missing user-agent / compression enabled [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-08-21 02:53 --- Fixed now in the CVS, and should appear in the next Tomcat release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
billbarker2004/08/20 21:44:37 Modified:webapps/docs Tag: TOMCAT_5_0 changelog.xml Log: Document patch Revision ChangesPath No revision No revision 1.70.2.4 +3 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.70.2.3 retrieving revision 1.70.2.4 diff -u -r1.70.2.3 -r1.70.2.4 --- changelog.xml 20 Aug 2004 14:29:11 - 1.70.2.3 +++ changelog.xml 21 Aug 2004 04:44:37 - 1.70.2.4 @@ -30,6 +30,9 @@ subsection name=Coyote changelog + fix + bug30770/bug: Check that the browser actually sent a user-agent header before using it. (billbarker) + /fix /changelog /subsection - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 4.1.31 maintenance release
I think we long ago agreed not to vote -1 just because you want somebody to work on a different codebase :-) If Keith has an itch in 4.1 branch - and if he can find 2 more +1 votes, than it's his right to have a release, and the 4.1 branch will become maintained. A branch is maintained if there are committers interested to maintain it - not if someone else decides it shouldn't be maintained and they should do something else. 4.1 is stable and works good enough - yes, 5.x is faster and has better architecture, but some people don't like to change production systems very often, and it is very good for them to know that what they are using is still maintained ( we're not msft to make money by forcing people to upgrade ) Costin Shapira, Yoav wrote: Hi, ballot The 4.1.31 maintenance release should happen: [ ] Yes [ X ] No /ballot -1 on this release. Reasons have been stated in detail in the other thread, but to summarize this branch is no longer maintained and users should upgrade to 5.x or custom-patch if they have an emergency. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
