Re: change in session activity tracking between Tomcat 4.1/5.0 and Tomcat 5.5
Hello Jan, Thank you again for your reply. Jan Luehe wrote: I see what you are getting at, and I agree that the servlet spec could be much clearer about this. Unfortunately, this ambiguous wording as been around for the longest time. That is why I was surprised to find the change in Tomcat 5, and no mention in the commit log, Bugzilla or this mailing list that it was misinterpreted and therefore fixed. If the mere presence of a JSESSIONID in the request were considered session access, how would you treat the case where a request did not carry any JSESSIONID, and a servlet created a new session by a call to HttpServletRequest.getSession()? According to your interpretation of SRV.7.6, the session would not be considered accessed until a subsequent request that carried its JSESSIONID was received by the container. Yes, that would also be my interpretation of what the API says: Returns: a long representing the last time the client sent a request associated with this session I would expect it having said something like the following in your interpretation: Returns the last time this session object was accessed, as the number of milliseconds since midnight January 1, 1970 GMT, and marked by the time the container received the request. or Returns: a long representing the last time the session object was accessed I don't believe this was the original spec authors' intention. I will double-check with the Servlet EG to make sure we're all in agreement on this. I suppose they changed their minds a few times on what this method should do and that led to the ambiguity. Thank you for double-checking, I'm looking forward to hearing their reply. Regards, Dies Koper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Bug report
I'm really confused. I didn't take care. Thanks for your replies. Regards, Dimitri De : charly [mailto:[EMAIL PROTECTED] Envoyé : jeudi 17 août 2006 19:56 À : Tomcat Developers List Objet : Re: Bug report Its very normal that Tomcat stops if there is code in a webapp which forces Tomcat or the JVM to stop: System.exit(-1); Karl-Heinz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 40282] New: - Boolean bean property not found due to Introspector limitation
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=40282.
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=40282
Summary: Boolean bean property not found due to Introspector
limitation
Product: Tomcat 5
Version: 5.5.17
Platform: Other
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
There is a bug in the java.beans.Introspector which means that it cannot find
the read method for a property of Boolean type (because it looks for the get
prefix, not the is prefix). This is arguably the expected behaviour of the
Introspector, however since the java.beans.PropertyDescriptor acts differently
(it can identify the property read method), this inconsistency hints it's a bug.
Also, with the advent of autoboxing, developers are supposed to be able to free
themselves from primitive types.
The commons EL library is affected by this bug, so using an interface like: -
public interface Bean {
Boolean isEnabled();
}
and an expression like: -
${bean.enabled}
fails with an ELException saying that the property could not be found (see
attached log snippet).
WebLogic does not suffer from this problem, presumably because they implement
their own EL parser (don't use commons.el) which doesn't use the Introspector. I
have written a suggested workaround for this problem which would allow the
commons.el library to continue its use of the Introspector, but deal with this
flaw (see attached). The AdditionalIntrospection could be used in the
BeanInfoManager.initialise() method, like so: -
PropertyDescriptor [] pds = mBeanInfo.getPropertyDescriptors ();
pds = AdditionalIntrospection.findMissingMethods(mBeanClass, pds); // new step
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 40282] - Boolean bean property not found due to Introspector limitation
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=40282. 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=40282 --- Additional Comments From [EMAIL PROTECTED] 2006-08-18 10:21 --- Btw, I was intending to raise this on the commons product, el component (e.g. like bug 37592), but I don't seem to have this option because Commons is missing from the Product field. Can an admin change the product/component here? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 40282] - Boolean bean property not found due to Introspector limitation
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=40282. 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=40282 --- Additional Comments From [EMAIL PROTECTED] 2006-08-18 10:21 --- Created an attachment (id=18730) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18730action=view) Log snippet showing the exception received when trying to access a Boolean type property -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 40282] - Boolean bean property not found due to Introspector limitation
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=40282. 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=40282 --- Additional Comments From [EMAIL PROTECTED] 2006-08-18 10:22 --- Created an attachment (id=18731) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18731action=view) Suggested new class that can be used to fill out the methods that the Introspector missed. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project tomcat-tc6 (in module tomcat-tc6) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project tomcat-tc6 has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 5 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-tc6 : Java Servlet 2.5 Server Pages JSP 2.1 implementation (for
...
Full details are available at:
http://vmgump.apache.org/gump/public/tomcat-tc6/tomcat-tc6/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-INFO- Failed with reason build failed
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-tc6/tomcat-tc6/gump_work/build_tomcat-tc6_tomcat-tc6.html
Work Name: build_tomcat-tc6_tomcat-tc6 (Type: Build)
Work ended in a state of : Failed
Elapsed: 37 secs
Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main
-Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only
-Dtomcat-native.tar.gz=/usr/local/gump/public/workspace/tomcat-tc6/README.txt
-Dcommons-logging-api.jar=/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-18082006.jar
-Dtomcat-dbcp.jar=/usr/local/gump/public/workspace/tomcat-tc6/tomcat-deps/tomcat-jdbc-18082006.jar
-Djasper-jdt.jar=/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar
[Working Directory: /usr/local/gump/public/workspace/tomcat-tc6]
CLASSPATH:
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/tomcat-tc6/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/javamail-1.4/mail.jar:/usr/local/gump/packages/javamail-1.4/lib/mailapi.jar:/usr/local/gump/packages/jaf-1.1ea/activation.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-18082006.jar:/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar:/usr/local/gump/public/workspace/tomcat-tc6/tomcat-deps/tomcat-jdbc-18082006.jar
-
[javac] public void init(FilterConfig filterConfig) {
[javac] ^
[javac]
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:126:
cannot find symbol
[javac] symbol : class ServletRequest
[javac] location: class compressionFilters.CompressionFilter
[javac] public void doFilter ( ServletRequest request, ServletResponse
response,
[javac]^
[javac]
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:126:
cannot find symbol
[javac] symbol : class ServletResponse
[javac] location: class compressionFilters.CompressionFilter
[javac] public void doFilter ( ServletRequest request, ServletResponse
response,
[javac]^
[javac]
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:127:
cannot find symbol
[javac] symbol : class FilterChain
[javac] location: class compressionFilters.CompressionFilter
[javac] FilterChain chain ) throws IOException,
ServletException {
[javac] ^
[javac]
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:127:
cannot find symbol
[javac] symbol : class ServletException
[javac] location: class compressionFilters.CompressionFilter
[javac] FilterChain chain ) throws IOException,
ServletException {
[javac] ^
[javac]
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:205:
cannot find symbol
[javac] symbol : class FilterConfig
[javac] location: class compressionFilters.CompressionFilter
[javac]
[EMAIL PROTECTED]: Project tomcat-tc6 (in module tomcat-tc6) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project tomcat-tc6 has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 5 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-tc6 : Java Servlet 2.5 Server Pages JSP 2.1 implementation (for
...
Full details are available at:
http://vmgump.apache.org/gump/public/tomcat-tc6/tomcat-tc6/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-INFO- Failed with reason build failed
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-tc6/tomcat-tc6/gump_work/build_tomcat-tc6_tomcat-tc6.html
Work Name: build_tomcat-tc6_tomcat-tc6 (Type: Build)
Work ended in a state of : Failed
Elapsed: 37 secs
Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main
-Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only
-Dtomcat-native.tar.gz=/usr/local/gump/public/workspace/tomcat-tc6/README.txt
-Dcommons-logging-api.jar=/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-18082006.jar
-Dtomcat-dbcp.jar=/usr/local/gump/public/workspace/tomcat-tc6/tomcat-deps/tomcat-jdbc-18082006.jar
-Djasper-jdt.jar=/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar
[Working Directory: /usr/local/gump/public/workspace/tomcat-tc6]
CLASSPATH:
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/tomcat-tc6/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/javamail-1.4/mail.jar:/usr/local/gump/packages/javamail-1.4/lib/mailapi.jar:/usr/local/gump/packages/jaf-1.1ea/activation.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-18082006.jar:/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar:/usr/local/gump/public/workspace/tomcat-tc6/tomcat-deps/tomcat-jdbc-18082006.jar
-
[javac] public void init(FilterConfig filterConfig) {
[javac] ^
[javac]
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:126:
cannot find symbol
[javac] symbol : class ServletRequest
[javac] location: class compressionFilters.CompressionFilter
[javac] public void doFilter ( ServletRequest request, ServletResponse
response,
[javac]^
[javac]
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:126:
cannot find symbol
[javac] symbol : class ServletResponse
[javac] location: class compressionFilters.CompressionFilter
[javac] public void doFilter ( ServletRequest request, ServletResponse
response,
[javac]^
[javac]
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:127:
cannot find symbol
[javac] symbol : class FilterChain
[javac] location: class compressionFilters.CompressionFilter
[javac] FilterChain chain ) throws IOException,
ServletException {
[javac] ^
[javac]
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:127:
cannot find symbol
[javac] symbol : class ServletException
[javac] location: class compressionFilters.CompressionFilter
[javac] FilterChain chain ) throws IOException,
ServletException {
[javac] ^
[javac]
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:205:
cannot find symbol
[javac] symbol : class FilterConfig
[javac] location: class compressionFilters.CompressionFilter
[javac]
DO NOT REPLY [Bug 40282] - Boolean bean property not found due to Introspector limitation
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=40282. 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=40282 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2006-08-18 11:06 --- Apologies, I see now that I should have raised this through the jira site (thats why the commons libraries are no longer available as products). Closed in favour of : https://issues.apache.org/jira/browse/EL-13 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r432556 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
Author: remm
Date: Fri Aug 18 04:33:12 2006
New Revision: 432556
URL: http://svn.apache.org/viewvc?rev=432556view=rev
Log:
- Also check the support attribute.
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java?rev=432556r1=432555r2=432556view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
Fri Aug 18 04:33:12 2006
@@ -224,7 +224,8 @@
}
if (request.getWrapper().getServlet() instanceof CometProcessor
- !response.isClosed()) {
+ !response.isClosed()
+ req.getAttribute(org.apache.tomcat.comet.support) ==
Boolean.TRUE) {
comet = true;
res.action(ActionCode.ACTION_COMET_BEGIN, null);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r432565 - in /tomcat/tc6.0.x/trunk: RELEASE-NOTES bin/setclasspath.bat bin/setclasspath.sh build.xml webapps/ROOT/index.html webapps/ROOT/index.jsp
Author: remm Date: Fri Aug 18 05:57:28 2006 New Revision: 432565 URL: http://svn.apache.org/viewvc?rev=432565view=rev Log: - Fix links. - Endorsed folder is now endorsed. Modified: tomcat/tc6.0.x/trunk/RELEASE-NOTES tomcat/tc6.0.x/trunk/bin/setclasspath.bat tomcat/tc6.0.x/trunk/bin/setclasspath.sh tomcat/tc6.0.x/trunk/build.xml tomcat/tc6.0.x/trunk/webapps/ROOT/index.html tomcat/tc6.0.x/trunk/webapps/ROOT/index.jsp Modified: tomcat/tc6.0.x/trunk/RELEASE-NOTES URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/RELEASE-NOTES?rev=432565r1=432564r2=432565view=diff == --- tomcat/tc6.0.x/trunk/RELEASE-NOTES (original) +++ tomcat/tc6.0.x/trunk/RELEASE-NOTES Fri Aug 18 05:57:28 2006 @@ -27,11 +27,10 @@ === Dependency Changes: === -Tomcat 5.5 is designed to run on J2SE 5.0 and later, and requires -configuration to run on J2SE 1.4. Make sure to read the RUNNING.txt -file in the fulldocs downloadable file(s) if you are using J2SE 1.4. +Tomcat 6.0 is designed to run on JSE 5.0 and later, and requires +configuration to run on JSE 5.0. -In addition, Tomcat 5.5 uses the Eclipse JDT Java compiler for compiling +In addition, Tomcat 6.0 uses the Eclipse JDT Java compiler for compiling JSP pages. This means you no longer need to have the complete Java Development Kit (JDK) to run Tomcat, but a Java Runtime Environment (JRE) is sufficient. The Eclipse JDT Java compiler is bundled with the @@ -64,24 +63,19 @@ = Bundled APIs: = -A standard installation of Tomcat 5.5 makes all of the following APIs available -for use by web applications (by placing them in common/lib or shared/lib): -* commons-el.jar (Commons Expression Language 1.0) +A standard installation of Tomcat 6.0 makes all of the following APIs available +for use by web applications (by placing them in lib): +* catalina.jar (Tomcat Catalina implementation) +* catalina-ant.jar (Tomcat Catalina Ant tasks) * commons-logging-api.jar (Commons Logging API 1.0.x) -* jasper-compiler.jar (Jasper 2 Compiler) -* jasper-compiler-jdt.jar (Eclipse JDT Java compiler) -* jasper-runtime.jar (Jasper 2 Runtime) -* jsp-api.jar (JSP 2.0 API) -* naming-common.jar (JNDI Context implementation) -* naming-factory.jar (JNDI object factories for J2EE ENC support) -* naming-factory-dbcp.jar (DataSource implementation based on commons-dbcp) -* naming-resources.jar (JNDI DirContext implementations) -* servlet-api.jar (Servlet 2.4 API) - -Installing the compatibility package will add the following to the list, which are -needed when running on J2SE 1.4: -* jmx.jar (Java Management Extensions API 1.2 or later) -* xercesImpl.jar (Xerces XML Parser, version 2.6.2 or later) +* el-api.jar (EL 1.0 API) +* jasper.jar (Jasper 2 Compiler and Runtime) +* jasper-compiler-jdt.jar (Eclipse JDT 3.2 Java compiler) +* jasper-el.jar (Jasper 2 EL implementation) +* jsp-api.jar (JSP 2.1 API) +* servlet-api.jar (Servlet 2.5 API) +* tomcat-coyote.jar (Tomcat connectors and utility classes) +* tomcat-dbcp.jar (package renamed database connection pool based on Commons DBCP) You can make additional APIs available to all of your web applications by putting unpacked classes into a classes directory (not created by default), @@ -89,7 +83,7 @@ To override the XML parser implementation or interfaces, use the endorsed mechanism of the JVM. The default configuration defines JARs located in -common/endorsed as endorsed. +endorsed as endorsed. Modified: tomcat/tc6.0.x/trunk/bin/setclasspath.bat URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/bin/setclasspath.bat?rev=432565r1=432564r2=432565view=diff == --- tomcat/tc6.0.x/trunk/bin/setclasspath.bat (original) +++ tomcat/tc6.0.x/trunk/bin/setclasspath.bat Fri Aug 18 05:57:28 2006 @@ -46,7 +46,7 @@ :okBasedir rem Set the default -Djava.endorsed.dirs argument -set JAVA_ENDORSED_DIRS=%BASEDIR%\common\endorsed +set JAVA_ENDORSED_DIRS=%BASEDIR%\endorsed rem Set standard CLASSPATH rem Note that there are no quotes as we do not want to introduce random Modified: tomcat/tc6.0.x/trunk/bin/setclasspath.sh URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/bin/setclasspath.sh?rev=432565r1=432564r2=432565view=diff == --- tomcat/tc6.0.x/trunk/bin/setclasspath.sh (original) +++ tomcat/tc6.0.x/trunk/bin/setclasspath.sh Fri Aug 18 05:57:28 2006 @@ -65,7 +65,7 @@ fi # Set the default -Djava.endorsed.dirs argument -JAVA_ENDORSED_DIRS=$BASEDIR/common/endorsed +JAVA_ENDORSED_DIRS=$BASEDIR/endorsed # Set standard CLASSPATH if [ $1 = debug -o $1 = javac ] ; then Modified: tomcat/tc6.0.x/trunk/build.xml URL:
possible mod_jk feature
I and other have run into issues where the socket between Apache and Tomcat (due to a in-between firewall) isn't closed as it should be... I'm digging further into this as far as why the timeout isn't being honored, but it got me thinking that a no reuse option might be nice. Basically, it prevents reuse from ever being set to TRUE... PS: Also to be done with mod_proxy_ajp as well, but that's a different list :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r432581 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/Constants.java
Author: remm Date: Fri Aug 18 06:41:19 2006 New Revision: 432581 URL: http://svn.apache.org/viewvc?rev=432581view=rev Log: - Fix version number. Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/Constants.java Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/Constants.java URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/Constants.java?rev=432581r1=432580r2=432581view=diff == --- tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/Constants.java (original) +++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/Constants.java Fri Aug 18 06:41:19 2006 @@ -22,7 +22,7 @@ public static final String Package = org.apache.catalina.core; public static final int MAJOR_VERSION = 2; -public static final int MINOR_VERSION = 4; +public static final int MINOR_VERSION = 5; public static final String JSP_SERVLET_CLASS = org.apache.jasper.servlet.JspServlet; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r432584 - in /tomcat/tc6.0.x/trunk: conf/server.xml java/org/apache/catalina/connector/CoyoteAdapter.java res/confinstall/server_1.xml
Author: remm
Date: Fri Aug 18 06:44:04 2006
New Revision: 432584
URL: http://svn.apache.org/viewvc?rev=432584view=rev
Log:
- Add the Jasper listener in the config.
- Fix (harmless) NPE when request processing doesn't proceed (ex: empty path).
Modified:
tomcat/tc6.0.x/trunk/conf/server.xml
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
tomcat/tc6.0.x/trunk/res/confinstall/server_1.xml
Modified: tomcat/tc6.0.x/trunk/conf/server.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/conf/server.xml?rev=432584r1=432583r2=432584view=diff
==
--- tomcat/tc6.0.x/trunk/conf/server.xml (original)
+++ tomcat/tc6.0.x/trunk/conf/server.xml Fri Aug 18 06:44:04 2006
@@ -15,6 +15,7 @@
!-- Comment these entries out to disable JMX MBeans support used for the
administration web application --
Listener className=org.apache.catalina.core.AprLifecycleListener /
+ Listener className=org.apache.catalina.core.JasperListener /
Listener className=org.apache.catalina.mbeans.ServerLifecycleListener /
Listener
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener /
!--Listener
className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/--
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java?rev=432584r1=432583r2=432584view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
Fri Aug 18 06:44:04 2006
@@ -218,16 +218,18 @@
// Parse and set Catalina and configuration specific
// request parameters
-if ( postParseRequest(req, request, res, response) ) {
+if (postParseRequest(req, request, res, response)) {
+
// Calling the container
connector.getContainer().getPipeline().getFirst().invoke(request, response);
-}
-if (request.getWrapper().getServlet() instanceof CometProcessor
- !response.isClosed()
- req.getAttribute(org.apache.tomcat.comet.support) ==
Boolean.TRUE) {
-comet = true;
-res.action(ActionCode.ACTION_COMET_BEGIN, null);
+if (request.getWrapper().getServlet() instanceof
CometProcessor
+ !response.isClosed()
+ req.getAttribute(org.apache.tomcat.comet.support)
== Boolean.TRUE) {
+comet = true;
+res.action(ActionCode.ACTION_COMET_BEGIN, null);
+}
+
}
if (!comet) {
Modified: tomcat/tc6.0.x/trunk/res/confinstall/server_1.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/res/confinstall/server_1.xml?rev=432584r1=432583r2=432584view=diff
==
--- tomcat/tc6.0.x/trunk/res/confinstall/server_1.xml (original)
+++ tomcat/tc6.0.x/trunk/res/confinstall/server_1.xml Fri Aug 18 06:44:04 2006
@@ -15,6 +15,7 @@
!-- Comment these entries out to disable JMX MBeans support used for the
administration web application --
Listener className=org.apache.catalina.core.AprLifecycleListener /
+ Listener className=org.apache.catalina.core.JasperListener /
Listener className=org.apache.catalina.mbeans.ServerLifecycleListener /
Listener
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener /
!--Listener
className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible mod_jk feature
Jim Jagielski wrote: I and other have run into issues where the socket between Apache and Tomcat (due to a in-between firewall) isn't closed as it should be... Yep, I have heared about things like that, on the Tomcat side the socket seems opened but it closed on the httpd side. The problem is that httpd will detect it and close the closed socket but nothing reaches the TC... Until a timeout occurs on the TC side (OS socket timeout). New requests cause new connections to be opened that results in threads increase (x2) in the TC with all the bad you could think of. I'm digging further into this as far as why the timeout isn't being honored, but it got me thinking that a no reuse option might be nice. Basically, it prevents reuse from ever being set to TRUE... Well the problem is how to detect that a bad close has happended. Cheers Jean-Frederic PS: Also to be done with mod_proxy_ajp as well, but that's a different list :) - 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 39684] - Test
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=39684. 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=39684 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID Target Milestone|--- | -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39768] - Make Tomcat more friendly for JTA within a JEE context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39768. 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=39768 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|--- | --- Additional Comments From [EMAIL PROTECTED] 2006-08-18 14:06 --- Tomcat is a Servlet/JSP container. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 40279] - ServletContext.getMinorVersion() returns 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=40279. 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=40279 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- | -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39805] - Annotations only working for public methods
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=39805. 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=39805 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- | --- Additional Comments From [EMAIL PROTECTED] 2006-08-18 14:08 --- This was fixed some time ago. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39804] - JspFactory.getDefaultFactory() returns null
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=39804. 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=39804 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- | --- Additional Comments From [EMAIL PROTECTED] 2006-08-18 14:08 --- This was fixed some time ago: a listener can be used in server.xml. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 40012] - Legacy EL Support not resolving variables correctly
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=40012. 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=40012 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- | --- Additional Comments From [EMAIL PROTECTED] 2006-08-18 14:10 --- Fixed in SVN -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 40012] - Legacy EL Support not resolving variables correctly
[EMAIL PROTECTED] wrote: Target Milestone|--- | I attempted adding a milestone to the project again, and for some reason, it finally decided to work. OTOH, I could not add a --- milestone (weird SQL error). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JIRA ?
Maybe JIRA should be used for TC 6 ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r432604 - in /tomcat/tc6.0.x/trunk/java/org/apache: el/lang/ELSupport.java jasper/servlet/JspServletWrapper.java
Author: remm
Date: Fri Aug 18 07:32:34 2006
New Revision: 432604
URL: http://svn.apache.org/viewvc?rev=432604view=rev
Log:
- Add two lost Jasper patches (which were applied to the old Jasper/TC6
repository).
- 38676
- 39803 (not sure if the fix is complete)
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/el/lang/ELSupport.java
tomcat/tc6.0.x/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java
Modified: tomcat/tc6.0.x/trunk/java/org/apache/el/lang/ELSupport.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/el/lang/ELSupport.java?rev=432604r1=432603r2=432604view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/el/lang/ELSupport.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/el/lang/ELSupport.java Fri Aug 18
07:32:34 2006
@@ -107,6 +107,10 @@
return false;
} else if (obj0 instanceof Boolean || obj1 instanceof Boolean) {
return coerceToBoolean(obj0).equals(coerceToBoolean(obj1));
+} else if (obj0.getClass().isEnum()) {
+return obj0.equals(coerceToEnum(obj1, obj0.getClass()));
+} else if (obj1.getClass().isEnum()) {
+return obj1.equals(coerceToEnum(obj0, obj1.getClass()));
}
if (isBigDecimalOp(obj0, obj1)) {
BigDecimal bd0 = (BigDecimal) coerceToNumber(obj0,
BigDecimal.class);
@@ -131,6 +135,21 @@
return obj0.equals(obj1);
}
}
+
+/**
+ * @param obj
+ * @param type
+ * @return
+ */
+public final static Enum coerceToEnum(final Object obj, Class type) {
+if (obj == null || .equals(obj)) {
+return null;
+}
+if (obj.getClass().isEnum()) {
+return (Enum) obj;
+}
+return Enum.valueOf(type, obj.toString());
+}
/**
* @param obj
@@ -286,6 +305,8 @@
return ;
} else if (obj instanceof String) {
return (String) obj;
+} else if (obj instanceof Enum) {
+return ((Enum) obj).name();
} else {
return obj.toString();
}
@@ -310,6 +331,9 @@
}
if (obj != null type.isAssignableFrom(obj.getClass())) {
return obj;
+}
+if (type.isEnum()) {
+return coerceToEnum(obj, type);
}
// new to spec
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java?rev=432604r1=432603r2=432604view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java
Fri Aug 18 07:32:34 2006
@@ -217,6 +217,7 @@
if (reload) {
tagHandlerClass = ctxt.load();
+reload = false;
}
} catch (FileNotFoundException ex) {
throw new JasperException(ex);
@@ -245,22 +246,23 @@
* Get a list of files that the current page has source dependency on.
*/
public java.util.List getDependants() {
- try {
- Object target;
- if (isTagFile) {
+try {
+Object target;
+if (isTagFile) {
if (reload) {
tagHandlerClass = ctxt.load();
+reload = false;
}
- target = tagHandlerClass.newInstance();
- } else {
- target = getServlet();
- }
- if (target != null target instanceof JspSourceDependent) {
-return ((java.util.List) ((JspSourceDependent)
target).getDependants());
- }
- } catch (Throwable ex) {
- }
- return null;
+target = tagHandlerClass.newInstance();
+} else {
+target = getServlet();
+}
+if (target != null target instanceof JspSourceDependent) {
+return ((java.util.List) ((JspSourceDependent)
target).getDependants());
+}
+} catch (Throwable ex) {
+}
+return null;
}
public boolean isTagFile() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA ?
I'm indifferent. It looks like all projects are moving in the direction of using JIRA and most likely Bugzilla will stop being supported by infrastructure [like CVS was]. So its probably a good time to move. Is there talk of infrastructure stopping support of bugzilla anytime? -Tim Remy Maucherat wrote: Maybe JIRA should be used for TC 6 ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA ?
+1 Remy Maucherat wrote: Maybe JIRA should be used for TC 6 ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal - Comet changes
my proposal is a little delayed, had a slight Fedora Core meltdown, still recovering Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: what am I thinking, all connectors, so far only the connectors supporting poll are valid candidates for comet :) I don't know how to redo the advertisement part of comet support without the special org.apache.tomcat.comet.support attribute, though. I dont think we need to, and I wasn't suggesting we need to. Just hide it from the developers, so that in a servlet you don't have to look for it etc. I think the CometServlet (if it has a final service method, and abstract event method, can simply throw/log a warning if the system is configured with a non comet support connector Filip - 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: possible mod_jk feature
Jim Jagielski wrote: I and other have run into issues where the socket between Apache and Tomcat (due to a in-between firewall) isn't closed as it should be... I'm digging further into this as far as why the timeout isn't being honored, but it got me thinking that a no reuse option might be nice. Basically, it prevents reuse from ever being set to TRUE... Makes no sense to me. In that case user can use mod_proxy and http protocol. AJP, or any other future protocol like HTTP-NG/MUX (http://www.w3.org/Protocols/HTTP-NG/Activity.html) that is designed to be persistent would always have to deal with badly designed firewalls. Anyhow, see my post about detecting the closed socket on APR dev list. Think I'm close to the portable solution, so this will satisfy almost all AJP(or any persistent protocol)-Firewall related problems. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA ?
Remy Maucherat wrote: Maybe JIRA should be used for TC 6 ? ++1 Further more, I would like to have that all across tomcat.apache.org, not only for TC6. -- Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible mod_jk feature
I was gonna suggest a worker.workername.reuse=True|False This is a very minor, non intrusive change since jk_ajp_*.c already has a struct that has a reuse flag, and it respects it, the code currently hard codes it to true. so people have the option to have non persistent connections. Many folks want to use mod_jk, and don't mind the connection overhead for not reusing connections and some features like LB and *.jsp patterns are not available in httpd 1.3/2.0, so folks want jk there, so they can't switch to http. Filip Mladen Turk wrote: Jim Jagielski wrote: I and other have run into issues where the socket between Apache and Tomcat (due to a in-between firewall) isn't closed as it should be... I'm digging further into this as far as why the timeout isn't being honored, but it got me thinking that a no reuse option might be nice. Basically, it prevents reuse from ever being set to TRUE... Makes no sense to me. In that case user can use mod_proxy and http protocol. AJP, or any other future protocol like HTTP-NG/MUX (http://www.w3.org/Protocols/HTTP-NG/Activity.html) that is designed to be persistent would always have to deal with badly designed firewalls. Anyhow, see my post about detecting the closed socket on APR dev list. Think I'm close to the portable solution, so this will satisfy almost all AJP(or any persistent protocol)-Firewall related problems. Regards, Mladen. - 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 40070] - APR causes JVM to crashon SEGV
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=40070. 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=40070 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2006-08-18 15:24 --- What can APR do to resist making memory access violations regardless of what Tomcat hands it in this particular case? Can it detect this and return an error rather than SIGSEGV and scuttling the process? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible mod_jk feature
Filip Hanik - Dev Lists wrote: I was gonna suggest a worker.workername.reuse=True|False This is a very minor, non intrusive change since jk_ajp_*.c already has a struct that has a reuse flag, and it respects it, the code currently hard codes it to true. It (or at least it should) favors this flag according to the returned flag from the Tomcat (JK_AJP13_END_RESPONSE). So, its up to Tomcat to decide the connection reusability, not mod_jk. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible mod_jk feature
On Aug 18, 2006, at 11:01 AM, Mladen Turk wrote: Jim Jagielski wrote: I and other have run into issues where the socket between Apache and Tomcat (due to a in-between firewall) isn't closed as it should be... I'm digging further into this as far as why the timeout isn't being honored, but it got me thinking that a no reuse option might be nice. Basically, it prevents reuse from ever being set to TRUE... Makes no sense to me. In that case user can use mod_proxy and http protocol. AJP, or any other future protocol like HTTP-NG/MUX (http://www.w3.org/Protocols/HTTP-NG/Activity.html) that is designed to be persistent would always have to deal with badly designed firewalls. Yeah, the recommendation for people who are hit by this is either (1) avoid AJP or (2) set MaxRequestsPerChild (in httpd) to 1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible mod_jk feature
On Aug 18, 2006, at 11:27 AM, Mladen Turk wrote: Filip Hanik - Dev Lists wrote: I was gonna suggest a worker.workername.reuse=True|False This is a very minor, non intrusive change since jk_ajp_*.c already has a struct that has a reuse flag, and it respects it, the code currently hard codes it to true. It (or at least it should) favors this flag according to the returned flag from the Tomcat (JK_AJP13_END_RESPONSE). So, its up to Tomcat to decide the connection reusability, not mod_jk. See Jean-Frederic's post about how/why this happens - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible mod_jk feature
On Aug 18, 2006, at 9:58 AM, Jean-frederic Clere wrote: Jim Jagielski wrote: I and other have run into issues where the socket between Apache and Tomcat (due to a in-between firewall) isn't closed as it should be... Yep, I have heared about things like that, on the Tomcat side the socket seems opened but it closed on the httpd side. The problem is that httpd will detect it and close the closed socket but nothing reaches the TC... Until a timeout occurs on the TC side (OS socket timeout). New requests cause new connections to be opened that results in threads increase (x2) in the TC with all the bad you could think of. Exactly. I'm digging further into this as far as why the timeout isn't being honored, but it got me thinking that a no reuse option might be nice. Basically, it prevents reuse from ever being set to TRUE... Well the problem is how to detect that a bad close has happended. Yep. Code-wise it's not trivial (not real tough, not just trivial) but from an Admin standpoint, they now when their setup causes this. So having a don't reuse flag would allow them to bypass this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible mod_jk feature
Jim Jagielski wrote: Makes no sense to me. Yeah, the recommendation for people who are hit by this is either (1) avoid AJP or (2) set MaxRequestsPerChild (in httpd) to 1 See my reply about AJP13_END_RESPONSE reuse flag. The Tomcat should be responsible for deciding if the connection will be reused or not. This flag is just like http keep-alive, but the problem is that Tomcat does not take advantage of this AJP protocol feature. Further more closing the connection in mod_jk would only make things worse, and will cause half-closed connections in Tomcat unless you set connectionTimeout, that OTOH requires CPING/CPONG for load balancer to work, etc. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.18 release
Filip Hanik - Dev Lists wrote: cool, I will cut the release Can you hold that up till Monday? I would like to test and cut the tcnative in front so that installer uses new binaries. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39803] - Unified EL impl doesn't support enums
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=39803. 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=39803 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- | --- Additional Comments From [EMAIL PROTECTED] 2006-08-18 18:20 --- Ok, after testing, Jacob's lost patch seems to implement enum support properly. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal - Comet changes
Filip Hanik - Dev Lists wrote: my proposal is a little delayed, had a slight Fedora Core meltdown, still recovering Soon, you're going to say it's all my fault. I am away without email next week, and I'm coming back on friday (in the evening). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible mod_jk feature
Mladen Turk wrote: Filip Hanik - Dev Lists wrote: I was gonna suggest a worker.workername.reuse=True|False This is a very minor, non intrusive change since jk_ajp_*.c already has a struct that has a reuse flag, and it respects it, the code currently hard codes it to true. It (or at least it should) favors this flag according to the returned flag from the Tomcat (JK_AJP13_END_RESPONSE). So, its up to Tomcat to decide the connection reusability, not mod_jk. not true, if tomcat sends reuse=false, it logs an error message and sets it to true Regards, Mladen. - 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: possible mod_jk feature
Mladen Turk wrote: Jim Jagielski wrote: Makes no sense to me. Yeah, the recommendation for people who are hit by this is either (1) avoid AJP or (2) set MaxRequestsPerChild (in httpd) to 1 See my reply about AJP13_END_RESPONSE reuse flag. The Tomcat should be responsible for deciding if the connection will be reused or not. This flag is just like http keep-alive, but the problem is that Tomcat does not take advantage of this AJP protocol feature. Further more closing the connection in mod_jk would only make things worse, and will cause half-closed connections in Tomcat unless you set connectionTimeout, that OTOH requires CPING/CPONG for load balancer to work, etc. it works fine, connections close Regards, Mladen. - 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: possible mod_jk feature
Filip Hanik - Dev Lists wrote: Mladen Turk wrote: See my reply about AJP13_END_RESPONSE reuse flag. it works fine, connections close So, is it working or not? You've send two contradictory posts to this thread :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible mod_jk feature
On Aug 18, 2006, at 12:40 PM, Mladen Turk wrote: The Tomcat should be responsible for deciding if the connection will be reused or not. This doesn't match, iirc, how the whole cache_timeout (or connection_pool_timeout) is done within mod_jk... Basically, what's needed is a way to make each AJP a one-shot. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible mod_jk feature
On Aug 18, 2006, at 3:37 PM, Mladen Turk wrote: Filip Hanik - Dev Lists wrote: Mladen Turk wrote: See my reply about AJP13_END_RESPONSE reuse flag. it works fine, connections close So, is it working or not? You've send two contradictory posts to this thread :) I think he's saying that if you set reuse to FALSE in mod_jk, Tomcat does the right thing and the connection closes. At least it does so in my tests... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JIRA ?
+0, but I agree with Mladen that we should migrate all TC version if we move to Jira. -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Friday, August 18, 2006 7:20 AM To: Tomcat Developers List Subject: JIRA ? Maybe JIRA should be used for TC 6 ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible mod_jk feature
Jim Jagielski wrote: On Aug 18, 2006, at 3:37 PM, Mladen Turk wrote: Filip Hanik - Dev Lists wrote: Mladen Turk wrote: See my reply about AJP13_END_RESPONSE reuse flag. it works fine, connections close So, is it working or not? You've send two contradictory posts to this thread :) I think he's saying that if you set reuse to FALSE in mod_jk, Tomcat does the right thing and the connection closes. At least it does so in my tests... that's correct, my post was to in response to your post about leaving half closed connections, its a non issue - 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: possible mod_jk feature
Jim Jagielski wrote: On Aug 18, 2006, at 12:40 PM, Mladen Turk wrote: The Tomcat should be responsible for deciding if the connection will be reused or not. This doesn't match, iirc, how the whole cache_timeout (or connection_pool_timeout) is done within mod_jk... Basically, what's needed is a way to make each AJP a one-shot. exactly, worker.workername.reuse=True|False I'll create a patch, and submit for review - 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: Proposal - Comet changes
Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: my proposal is a little delayed, had a slight Fedora Core meltdown, still recovering Soon, you're going to say it's all my fault. that's implicit :) I am away without email next week, and I'm coming back on friday (in the evening). enjoy your time, we'll try to mess up as much as we can while you're gone ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible mod_jk feature
Jim Jagielski wrote: On Aug 18, 2006, at 12:40 PM, Mladen Turk wrote: The Tomcat should be responsible for deciding if the connection will be reused or not. This doesn't match, iirc, how the whole cache_timeout (or connection_pool_timeout) is done within mod_jk... Basically, what's needed is a way to make each AJP a one-shot. Right, but it should be in the form: 1. mod_jk/mod_proxy_ajp connects 2. Tomcat responds if the connection 'should/should not' be closed after the response. This way we would not end up with half-closed socket problems. Further more, its part of AJP spec, so what's the problem of implementing it? Tomcat should have a directive that would tell to close the connection after the response has been send. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible mod_jk feature
On Aug 18, 2006, at 4:06 PM, Mladen Turk wrote: Jim Jagielski wrote: On Aug 18, 2006, at 12:40 PM, Mladen Turk wrote: The Tomcat should be responsible for deciding if the connection will be reused or not. This doesn't match, iirc, how the whole cache_timeout (or connection_pool_timeout) is done within mod_jk... Basically, what's needed is a way to make each AJP a one-shot. Right, but it should be in the form: 1. mod_jk/mod_proxy_ajp connects 2. Tomcat responds if the connection 'should/should not' be closed after the response. My reading is that the reuse flag is simply tagged to whether or not we rec'd anything (basically) at the END_RESPONSE phase. Even if we do, we still force a reuse (which is weird since we log the fact that we're not going to reuse it). We do set reuse to FALSE if we get a client error (and we have an abort-on-error set). In fact, that's how we mark it for closing. In any case, if reuse is FALSE, ajp_reset_endpoint does the right thing. So, IMO at JK_AJP13_END_RESPONSE, we should: 1. Not reset reuse to TRUE on a protocol error 2. Check for a 'r-never_reuse' flag and, if set, force reuse to FALSE. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat - IIS connector
There is an MSI installer available for jk-1.2.15. Are there plans for doing the same for jk-1.2.18? Regards, Alex Finch Alex Finch Srv/Spt On-Site Engineer Customer Support Software Global Business Unit Hewlett-Packard Company +1 800.960.9998 Phone [EMAIL PROTECTED] www.hp.com
Relation of jasper and servlet API to Tomcat
Greetings, Over the past 7+ months I have been maintaining Tomcat on Gentoo. I have now become a Gentoo developer so I can officially become the Tomcat maintainer on Gentoo. With that said, I have a couple of things I am curious about. First off, is there any reason Jasper and Servlet-API can't be projects of their own? With their own binary releases. Reason I ask is that it seems other apps use Jasper, not just Tomcat. With regard to servlet-api, it seems to be the only open source implementation. Sun has yet to release 2.4, only 2.3. So the only 2.4 servlet api I can find is the one in Tomcat. On Gentoo we have 3 packages built from the same Tomcat sources. If Tomcat has a revision bump, does that mean Jasper or Servlet API changes as well? If so we have to revision bump 3 packages instead of just Tomcat. Also if I make a patch for servlet-api for Tomcat, the same patch also applies to the servlet API package as well. So multiple copies of the same patch. Much less if someone emerges both servlet api and Tomcat they end up with two copies. Which sorta defeats what we do on Gentoo. Which is to install a resource like log4j, commons stuff etc, once, and symlink it where ever it's needed or used. So you don't end up with different versions and multiple copies of jars and etc all over the place. Ideally it would be great if Jasper and Servlet API were on their own. Different sources and binary releases. Then they could be bundled with releases of Tomcat just as other stuff is bundled. That would make more sense if Tomcat specific things changed among revisions, but did not change Jasper or servlet api stuff. If this has already been discussed, is in the works or etc. I apologize for not seeing it, or being aware of it. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Compiling and buildig naming-factory-dbcp.jar
For the most part the Tomcat compiled from source on Gentoo provides all, and does all the binary one does. With the exception of one jar, naming-factory-dbcp.jar. From looking at the build.xml file it seems that to build that jar, .java files are needed from three other commons packages. Some of those files are modified, and all compiled and put inside naming-factory-dbcp.jar. So basically I have been unable to build that jar due to only having access to Tomcat's sources. Anything Tomcat would download and compile via ant, possibly in jar format, as dependencies, are their own packages on Gentoo. So they are all compiled, prior to Tomcat. They are then linked into locations in Tomcat's sources so compiling will work. At this time it seems I would have to have the package pull in 4 sources, Tomcat, commons-collections, commons-pool, and commons-dbcp. Then unpack the last three inside Tomcat. So ant can find what it needs to build the naming-factory-dbcp.jar. For some reason that all just seems wrong. Why borrow/take the files from other sources and re-bundle them? Why not make Tomcat's own implementation of them? Or at least modify it so that jar could be build via access to .class files, not .java sources. If they were binary dependencies it would not be an issue. But since it's source dependencies, and then compiling and bundling of those sources. There just is not a clean or straight forward way for me to build that jar on Gentoo. I have not had a chance to dig much further than the ant build.xml file for that jar. I know a patch or addressing it is preferred to just a discussion or etc about it. Just for someone else to do the work. However I just wanted to get more info before diving any further. Thanks -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
DO NOT REPLY [Bug 37793] - org.apache.jasper.runtime.BodyContentImpl doesn't reset the 'cb' character array, causes memory leak
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=37793. 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=37793 --- Additional Comments From [EMAIL PROTECTED] 2006-08-18 21:59 --- Created an attachment (id=18735) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18735action=view) The attachment contains profiler snapshots showing char[] holding upto 205MB finally causing the container to go out of memory We are struggling with a similar issue with tomcat 5.0.30 and we are not in a position to upgrade the version . Our JSP pages are large and we are able to bring tomcat down very quickly with just 3-4 sessions browsing couple of pages.Memory is mostly held by char[] BodyContentImpl and GC tries to clean some memory but eventually the system goes out of memory as GC is not able to free anything held by char[]. The problem is seen in prod where memory is very high .We replicated in dev with tomcat5.0.30 running with the following settings: JAVAOPTS: -server -Djava.awt.headless=true -Xms64m -Xmx256m -Xloggc:logs/gc.out -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:NewSize=8m -XX:MaxNewSize=128m -XX:+DisableExplicitGC Profiler used in JProfiler. Will appreciate inputs to resolve this issue. Breaking down JSP pages can be looked at in the future but would involve significant effort/time/funding and at this point we need to resolve the issue without breaking down the JSP pages since the app is already in prod and is falling apart because of this problem. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 40257] - tomcat 5.0.28 to 5.5.17 upgrade - Tomcat Manager Context Deployment does not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40257. 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=40257 [EMAIL PROTECTED] changed: What|Removed |Added Severity|blocker |minor -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA ?
+0. If we do move to Jira then we should move all TC projects to Jira. Mark Remy Maucherat wrote: Maybe JIRA should be used for TC 6 ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA ?
Mark Thomas wrote: +0. If we do move to Jira then we should move all TC projects to Jira. Why exactly ? TC 6 has (almost) no bugs filed, so the transition seems far easier. For the others, there's a transition cost. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
