[Bug 56425] Unable to find unambiguous method in class String
https://issues.apache.org/bugzilla/show_bug.cgi?id=56425 --- Comment #4 from Violeta Georgieva violet...@apache.org --- Hi, This is the revision r1590121. Can you provide a test where you see the issue? Regards, Violeta -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1631950 - /tomcat/trunk/webapps/docs/config/cluster-manager.xml
Author: markt Date: Wed Oct 15 06:27:55 2014 New Revision: 1631950 URL: http://svn.apache.org/r1631950 Log: Whitespace police Modified: tomcat/trunk/webapps/docs/config/cluster-manager.xml Modified: tomcat/trunk/webapps/docs/config/cluster-manager.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/cluster-manager.xml?rev=1631950r1=1631949r2=1631950view=diff == --- tomcat/trunk/webapps/docs/config/cluster-manager.xml (original) +++ tomcat/trunk/webapps/docs/config/cluster-manager.xml Wed Oct 15 06:27:55 2014 @@ -241,6 +241,6 @@ /p /attribute /attributes -/section +/section /body /document - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Tomcat8 coercing behavior
Hi,
When binding a JSF input text to a String property of a JSF ManagedBean, I
want that an empty value is mapped to null and not (empty string).
So, on tomcat7 (7.0.56) with JSF(2.2) I can get this to work nicely by
controlling the coercing behavior with the JVM property
org.apache.el.parser.COERCE_TO_ZERO icw JSF
javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL as context
param.
When javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to
true, JSF will set the local component value for the input component as null
when the input if left empty.
Next, when the value is actually set by tomcat's EL parser, it will NOT try
to coerce the value when org.apache.el.parser.COERCE_TO_ZERO is set to
false.
This can be seen in org.apache.el.parser.AstValue#216:
if (COERCE_TO_ZERO == true
|| !isAssignable(value, targetClass)) {
resolver.setValue(ctx, t.base, t.property,
ELSupport.coerceToType(value, targetClass));
} else {
resolver.setValue(ctx, t.base, t.property, value);
}
So, in this case I get 'null' instead of = OK
However, if I now try this on tomcat8 (8.0.14), this no longer works.
org.apache.el.parser.AstValue#200 now does this:
resolver.setValue(ctx, t.base, t.property,
ELSupport.coerceToType(value, targetClass));
So ELSupport is ALWAYS executed, it will ignore the first 2 IF statements
(as my target type is String):
public static final Object coerceToType(final Object obj,
final Class? type) throws ELException {
if (type == null || Object.class.equals(type) ||
(obj != null type.isAssignableFrom(obj.getClass( {
return obj;
}
if (!COERCE_TO_ZERO) {
if (obj == null !type.isPrimitive()
!String.class.isAssignableFrom(type)) {
return null;
}
}
if (String.class.equals(type)) {
return coerceToString(obj);
}
And this will eventually call coerceToString, which will always return
if the value was null :
public static final String coerceToString(final Object obj) {
if (obj == null) {
return ;
So, from tomcat8 I always get instead of the desired null.
I know this is related to the specification (this goes as far back as
tomcat6) but now I'm getting really confused here as this worked on 6 and 7
but no longer on 8
Is this a bug or am I missing something here?
Thanks,
Koen.
Re: Tomcat8 coercing behavior
Hi,
2014-10-15 11:38 GMT+03:00 Koen Serneels k...@error.be:
Hi,
When binding a JSF input text to a String property of a JSF ManagedBean, I
want that an empty value is mapped to null and not (empty string).
So, on tomcat7 (7.0.56) with JSF(2.2) I can get this to work nicely by
controlling the coercing behavior with the JVM property
org.apache.el.parser.COERCE_TO_ZERO icw JSF
javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL as context
param.
When javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to
true, JSF will set the local component value for the input component as
null
when the input if left empty.
Next, when the value is actually set by tomcat's EL parser, it will NOT
try
to coerce the value when org.apache.el.parser.COERCE_TO_ZERO is set to
false.
This can be seen in org.apache.el.parser.AstValue#216:
if (COERCE_TO_ZERO == true
|| !isAssignable(value, targetClass)) {
resolver.setValue(ctx, t.base, t.property,
ELSupport.coerceToType(value, targetClass));
} else {
resolver.setValue(ctx, t.base, t.property, value);
}
So, in this case I get 'null' instead of = OK
However, if I now try this on tomcat8 (8.0.14), this no longer works.
org.apache.el.parser.AstValue#200 now does this:
resolver.setValue(ctx, t.base, t.property,
ELSupport.coerceToType(value, targetClass));
So ELSupport is ALWAYS executed, it will ignore the first 2 IF statements
(as my target type is String):
public static final Object coerceToType(final Object obj,
final Class? type) throws ELException {
if (type == null || Object.class.equals(type) ||
(obj != null type.isAssignableFrom(obj.getClass( {
return obj;
}
if (!COERCE_TO_ZERO) {
if (obj == null !type.isPrimitive()
!String.class.isAssignableFrom(type)) {
return null;
}
}
if (String.class.equals(type)) {
return coerceToString(obj);
}
And this will eventually call coerceToString, which will always return
if the value was null :
public static final String coerceToString(final Object obj) {
if (obj == null) {
return ;
So, from tomcat8 I always get instead of the desired null.
This is incompatible change in EL 3.0.
Check EL 3.0 Spec 1.23.1 and 1.23.2 the Rule for null String is to coerce
to .
and
A.4 Incompatibilities between EL 3.0 and EL 2.2
Regards
Violeta
I know this is related to the specification (this goes as far back as
tomcat6) but now I'm getting really confused here as this worked on 6 and
7
but no longer on 8
Is this a bug or am I missing something here?
Thanks,
Koen.
[Bug 57095] New: WebSocket memory usage
https://issues.apache.org/bugzilla/show_bug.cgi?id=57095 Bug ID: 57095 Summary: WebSocket memory usage Product: Tomcat 8 Version: 8.0.14 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: WebSocket Assignee: dev@tomcat.apache.org Reporter: veliscu.cri...@gmail.com By creating 100k connections with single text message exchanging between server and clients it takes over 6GB of memory. On other server it takes a half memory (around 3 GB). What are the parameters/buffers to address in order to avoid this issue? Thanks, Cristian -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Tomcat8 coercing behavior
Hi,
Thanks for point this out.
So, maybe my next question is more of a JSF question, but I'll give a shot.
Why does the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL even
exist then?
It will always be overruled by the EL parser when actually setting the value,
at least as of EL3
In other words is there any way to revert to the old behavior using tomcat8 icw
JSF?
-Original Message-
From: Violeta Georgieva [mailto:miles...@gmail.com]
Sent: woensdag 15 oktober 2014 10:57
To: Tomcat Developers List
Subject: Re: Tomcat8 coercing behavior
Hi,
2014-10-15 11:38 GMT+03:00 Koen Serneels k...@error.be:
Hi,
When binding a JSF input text to a String property of a JSF
ManagedBean, I want that an empty value is mapped to null and not (empty
string).
So, on tomcat7 (7.0.56) with JSF(2.2) I can get this to work nicely by
controlling the coercing behavior with the JVM property
org.apache.el.parser.COERCE_TO_ZERO icw JSF
javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL as context
param.
When javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is
set to true, JSF will set the local component value for the input
component as
null
when the input if left empty.
Next, when the value is actually set by tomcat's EL parser, it will
NOT
try
to coerce the value when org.apache.el.parser.COERCE_TO_ZERO is set to
false.
This can be seen in org.apache.el.parser.AstValue#216:
if (COERCE_TO_ZERO == true
|| !isAssignable(value, targetClass)) {
resolver.setValue(ctx, t.base, t.property,
ELSupport.coerceToType(value, targetClass));
} else {
resolver.setValue(ctx, t.base, t.property, value);
}
So, in this case I get 'null' instead of = OK
However, if I now try this on tomcat8 (8.0.14), this no longer works.
org.apache.el.parser.AstValue#200 now does this:
resolver.setValue(ctx, t.base, t.property,
ELSupport.coerceToType(value, targetClass));
So ELSupport is ALWAYS executed, it will ignore the first 2 IF
statements (as my target type is String):
public static final Object coerceToType(final Object obj,
final Class? type) throws ELException {
if (type == null || Object.class.equals(type) ||
(obj != null
type.isAssignableFrom(obj.getClass( {
return obj;
}
if (!COERCE_TO_ZERO) {
if (obj == null !type.isPrimitive()
!String.class.isAssignableFrom(type)) {
return null;
}
}
if (String.class.equals(type)) {
return coerceToString(obj);
}
And this will eventually call coerceToString, which will always
return
if the value was null :
public static final String coerceToString(final Object obj) {
if (obj == null) {
return ;
So, from tomcat8 I always get instead of the desired null.
This is incompatible change in EL 3.0.
Check EL 3.0 Spec 1.23.1 and 1.23.2 the Rule for null String is to coerce to .
and
A.4 Incompatibilities between EL 3.0 and EL 2.2
Regards
Violeta
I know this is related to the specification (this goes as far back as
tomcat6) but now I'm getting really confused here as this worked on 6
and
7
but no longer on 8
Is this a bug or am I missing something here?
Thanks,
Koen.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57095] WebSocket memory usage
https://issues.apache.org/bugzilla/show_bug.cgi?id=57095 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Mark Thomas ma...@apache.org --- Bugzilla is not a support forum. Please direct your question to the Tomcat users' mailing list. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot failure in ASF Buildbot on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/549 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1631950 Blamelist: markt BUILD FAILED: failed compile_1 sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1631987 - in /tomcat/trunk/java/javax: el/BeanNameResolver.java websocket/RemoteEndpoint.java
Author: markt
Date: Wed Oct 15 10:13:11 2014
New Revision: 1631987
URL: http://svn.apache.org/r1631987
Log:
Java 8 isn't complaining about these but Eclipse is so fix them as well
Modified:
tomcat/trunk/java/javax/el/BeanNameResolver.java
tomcat/trunk/java/javax/websocket/RemoteEndpoint.java
Modified: tomcat/trunk/java/javax/el/BeanNameResolver.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/el/BeanNameResolver.java?rev=1631987r1=1631986r2=1631987view=diff
==
--- tomcat/trunk/java/javax/el/BeanNameResolver.java (original)
+++ tomcat/trunk/java/javax/el/BeanNameResolver.java Wed Oct 15 10:13:11 2014
@@ -54,10 +54,12 @@ public abstract class BeanNameResolver {
* is created with the given value.
*
* @param beanName The name of the bean to be set/create
- * @param valueThe value of the bean to set/create
+ * @param valueThe value of the bean to set/create]
+ *
+ * @throws PropertyNotWritableException if the bean is read only
*/
public void setBeanValue(String beanName, Object value)
-throws PropertyNotWritableException{
+throws PropertyNotWritableException {
throw new PropertyNotWritableException();
}
Modified: tomcat/trunk/java/javax/websocket/RemoteEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/websocket/RemoteEndpoint.java?rev=1631987r1=1631986r2=1631987view=diff
==
--- tomcat/trunk/java/javax/websocket/RemoteEndpoint.java (original)
+++ tomcat/trunk/java/javax/websocket/RemoteEndpoint.java Wed Oct 15 10:13:11
2014
@@ -173,6 +173,8 @@ public interface RemoteEndpoint {
* @param applicationData The payload for the ping message
*
* @throws IOException If an I/O error occurs while sending the ping
+ * @throws IllegalArgumentException if the applicationData is too large for
+ * a control message (max 125 bytes)
*/
void sendPing(ByteBuffer applicationData)
throws IOException, IllegalArgumentException;
@@ -185,6 +187,8 @@ public interface RemoteEndpoint {
* @param applicationData The payload for the pong message
*
* @throws IOException If an I/O error occurs while sending the pong
+ * @throws IllegalArgumentException if the applicationData is too large for
+ * a control message (max 125 bytes)
*/
void sendPong(ByteBuffer applicationData)
throws IOException, IllegalArgumentException;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1631992 - in /tomcat/trunk: BUILDING.txt RELEASE-NOTES build.xml webapps/docs/changelog.xml webapps/docs/class-loader-howto.xml webapps/docs/index.xml webapps/docs/project.xml
Author: kkolinko
Date: Wed Oct 15 11:25:40 2014
New Revision: 1631992
URL: http://svn.apache.org/r1631992
Log:
Correct version of Java WebSocket mentioned in documentation
Followup to r1631839
Modified:
tomcat/trunk/BUILDING.txt
tomcat/trunk/RELEASE-NOTES
tomcat/trunk/build.xml
tomcat/trunk/webapps/docs/changelog.xml
tomcat/trunk/webapps/docs/class-loader-howto.xml
tomcat/trunk/webapps/docs/index.xml
tomcat/trunk/webapps/docs/project.xml
Modified: tomcat/trunk/BUILDING.txt
URL:
http://svn.apache.org/viewvc/tomcat/trunk/BUILDING.txt?rev=1631992r1=1631991r2=1631992view=diff
==
--- tomcat/trunk/BUILDING.txt (original)
+++ tomcat/trunk/BUILDING.txt Wed Oct 15 11:25:40 2014
@@ -20,7 +20,7 @@
This subproject contains the source code for Tomcat @VERSION_MAJOR_MINOR@, a
container that
-implements the Servlet 3.1, JSP 2.3, EL 3.0 and WebSocket 1.0 specifications
+implements the Servlet 3.1, JSP 2.3, EL 3.0 and WebSocket 1.1 specifications
from the Java Community Process http://www.jcp.org/.
Note: If you just need to run Apache Tomcat, it is not necessary to build
Modified: tomcat/trunk/RELEASE-NOTES
URL:
http://svn.apache.org/viewvc/tomcat/trunk/RELEASE-NOTES?rev=1631992r1=1631991r2=1631992view=diff
==
--- tomcat/trunk/RELEASE-NOTES (original)
+++ tomcat/trunk/RELEASE-NOTES Wed Oct 15 11:25:40 2014
@@ -85,8 +85,8 @@ for use by web applications (by placing
* tomcat-jni.jar (Interface to the native component of the APR/native
connector)
* tomcat-spdy.jar (SPDY implementation)
* tomcat-util.jar (Various utilities)
-* tomcat-websocket.jar (WebSocket 1.0 implementation)
-* websocket-api.jar (WebSocket 1.0 API)
+* tomcat-websocket.jar (WebSocket 1.1 implementation)
+* websocket-api.jar (WebSocket 1.1 API)
You can make additional APIs available to all of your web applications by
putting unpacked classes into a classes directory (not created by default),
Modified: tomcat/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=1631992r1=1631991r2=1631992view=diff
==
--- tomcat/trunk/build.xml (original)
+++ tomcat/trunk/build.xml Wed Oct 15 11:25:40 2014
@@ -720,13 +720,13 @@
filesId=files.el-api
manifest=${tomcat.manifests}/el-api.jar.manifest /
-!-- WebSocket 1.0 API JAR File --
+!-- WebSocket 1.1 API JAR File --
jarIt jarfile=${websocket-api.jar}
filesDir=${tomcat.classes}
filesId=files.websocket-api
manifest=${tomcat.manifests}/websocket-api.jar.manifest /
-!-- WebSocket 1.0 implementation JAR File --
+!-- WebSocket 1.1 implementation JAR File --
jarIt jarfile=${tomcat-websocket.jar}
filesDir=${tomcat.classes}
filesId=files.tomcat-websocket
@@ -1918,9 +1918,9 @@ Apache Tomcat ${version} native binaries
sourcepath=${tomcat.dist}/src/java
destdir=${tomcat.dist}/webapps/docs/websocketapi
version=true
- windowtitle=WebSocket 1.0 API Documentation - Apache Tomcat ${version}
- doctitle=WebSocket 1.0 API - Apache Tomcat ${version}
- header=lt;bgt;WebSocket 1.0 - Apache Tomcat ${version}lt;/bgt;
+ windowtitle=WebSocket 1.1 API Documentation - Apache Tomcat ${version}
+ doctitle=WebSocket 1.1 API - Apache Tomcat ${version}
+ header=lt;bgt;WebSocket 1.1 - Apache Tomcat ${version}lt;/bgt;
bottom=Copyright amp;#169; 2000-${year} Apache Software Foundation.
All Rights Reserved.
encoding=ISO-8859-1
additionalparam=-breakiterator
@@ -2590,13 +2590,13 @@ Apache Tomcat ${version} native binaries
filesId=files.el-api
manifest=${tomcat.manifests}/el-api.jar.manifest /
-!-- WebSocket 1.0 API JAR File --
+!-- WebSocket 1.1 API JAR File --
jarIt jarfile=${websocket-api-src.jar}
filesDir=java
filesId=files.websocket-api
manifest=${tomcat.manifests}/websocket-api.jar.manifest /
-!-- WebSocket 1.0 implementation JAR File --
+!-- WebSocket 1.1 implementation JAR File --
jarIt jarfile=${tomcat-websocket-src.jar}
filesDir=java
filesId=files.tomcat-websocket /
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1631992r1=1631991r2=1631992view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Wed Oct 15 11:25:40 2014
@@ -198,7 +198,11 @@
codelt;Enginegt;/code's codejvmRoute/code or in a system
property. (schultz)
/fix
- /changelog
+ fix
+Correct version of Java WebSocket mentioned in documentation
+
svn commit: r1631993 - /tomcat/trunk/java/javax/el/BeanNameResolver.java
Author: kkolinko
Date: Wed Oct 15 11:27:34 2014
New Revision: 1631993
URL: http://svn.apache.org/r1631993
Log:
Correct a typo (followup to r1631987)
Modified:
tomcat/trunk/java/javax/el/BeanNameResolver.java
Modified: tomcat/trunk/java/javax/el/BeanNameResolver.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/el/BeanNameResolver.java?rev=1631993r1=1631992r2=1631993view=diff
==
--- tomcat/trunk/java/javax/el/BeanNameResolver.java (original)
+++ tomcat/trunk/java/javax/el/BeanNameResolver.java Wed Oct 15 11:27:34 2014
@@ -54,7 +54,7 @@ public abstract class BeanNameResolver {
* is created with the given value.
*
* @param beanName The name of the bean to be set/create
- * @param valueThe value of the bean to set/create]
+ * @param valueThe value of the bean to set/create
*
* @throws PropertyNotWritableException if the bean is read only
*/
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57097] New: Add name attribute to standard connectors
https://issues.apache.org/bugzilla/show_bug.cgi?id=57097 Bug ID: 57097 Summary: Add name attribute to standard connectors Product: Tomcat 8 Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P2 Component: Connectors Assignee: dev@tomcat.apache.org Reporter: jens.borgl...@gmail.com I would like a name attribute (or similar) added to the standard connectors. This name should preferably be part of the JMX ObjectName for the connector MBeans, or at least be retrievable from the MBeans. Justification: I'm working on an application which bundles Tomcat and makes use of several connectors (typically binding to different network interfaces). In my application I need to determine which port is set for which connector. I can easily list the connector MBeans and retrieve the information from those but I have no way of telling which connector is which. The connectors may use the same protocol (it depends on the customer if they want to use HTTP or HTTPS) and I have no control over their ports (they're set by the customers installing the application). A simple name attribute that is reachable from JMX would solve my problem. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55988] Add parameter useCipherSuitesOrder to JSSE (BIO and NIO) connectors [PATCH]
https://issues.apache.org/bugzilla/show_bug.cgi?id=55988 Jens Borgland jens.borgl...@gmail.com changed: What|Removed |Added CC||jens.borgl...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57097] Add name attribute to standard connectors
https://issues.apache.org/bugzilla/show_bug.cgi?id=57097 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Mark Thomas ma...@apache.org --- Connectors are uniquely identified by the combination of address and port. This information is already included in the JMX name. An additional name property would be redundant. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57091] Websockets cannot be used in Windows applet plugin environments based on Oracle Java7
https://issues.apache.org/bugzilla/show_bug.cgi?id=57091 --- Comment #3 from Mark Thomas ma...@apache.org --- A test case would be helpful, thank you. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57097] Add name attribute to standard connectors
https://issues.apache.org/bugzilla/show_bug.cgi?id=57097 --- Comment #2 from Jens Borgland jens.borgl...@gmail.com --- Well, yes that uniquely identifies the connector but since both those attributes may be set at will by the administrator when deploying the application they cannot be used to identify which connector is which (for my purposes) - I have no way of knowing which address or port that is supposed to be the backend or frontend. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57098] New: Weird Reponse for a HTTP request on HTTPS(SSL) port
https://issues.apache.org/bugzilla/show_bug.cgi?id=57098 Bug ID: 57098 Summary: Weird Reponse for a HTTP request on HTTPS(SSL) port Product: Tomcat 7 Version: 7.0.55 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Connectors Assignee: dev@tomcat.apache.org Reporter: beigel.ste...@gmail.com Hi I'am using tomcat 7.0.55 with this configuration: Debian 7.x Java 1.7.0_67-b01 I'am getting some wierd reaktion whenever I do a simple HTTP request on the SSL port. Other webserver sending a 400 Bad Request response. With Chrome webbrowser a File is being downloaded. At the moment iam not sure if this is a real bug. Chrome 37.0.2062.124 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1632012 - /tomcat/trunk/java/org/apache/catalina/authenticator/AuthenticatorBase.java
Author: markt
Date: Wed Oct 15 13:20:02 2014
New Revision: 1632012
URL: http://svn.apache.org/r1632012
Log:
Simplify code
Modified:
tomcat/trunk/java/org/apache/catalina/authenticator/AuthenticatorBase.java
Modified:
tomcat/trunk/java/org/apache/catalina/authenticator/AuthenticatorBase.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/authenticator/AuthenticatorBase.java?rev=1632012r1=1632011r2=1632012view=diff
==
--- tomcat/trunk/java/org/apache/catalina/authenticator/AuthenticatorBase.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/authenticator/AuthenticatorBase.java
Wed Oct 15 13:20:02 2014
@@ -446,12 +446,12 @@ public abstract class AuthenticatorBase
// where the login form (and therefore the j_security_check URI
// to which it submits) might be outside the secured area
String contextPath = this.context.getPath();
-String requestURI = request.getDecodedRequestURI();
-if (requestURI.startsWith(contextPath)
-requestURI.endsWith(Constants.FORM_ACTION)) {
+String decodedRequestURI = request.getDecodedRequestURI();
+if (decodedRequestURI.startsWith(contextPath)
+decodedRequestURI.endsWith(Constants.FORM_ACTION)) {
if (!authenticate(request, response)) {
if (log.isDebugEnabled()) {
-log.debug( Failed authenticate() test ?? + requestURI );
+log.debug( Failed authenticate() test ?? +
decodedRequestURI );
}
return;
}
@@ -467,23 +467,18 @@ public abstract class AuthenticatorBase
if (session != null) {
SavedRequest savedRequest =
(SavedRequest)
session.getNote(Constants.FORM_REQUEST_NOTE);
-if (savedRequest != null) {
-String decodedRequestURI = request.getDecodedRequestURI();
-if (decodedRequestURI != null
-decodedRequestURI.equals(
-savedRequest.getDecodedRequestURI())) {
-if (!authenticate(request, response)) {
-if (log.isDebugEnabled()) {
-log.debug( Failed authenticate() test);
-}
-/*
- * ASSERT: Authenticator already set the appropriate
- * HTTP status code, so we do not have to do anything
- * special
- */
-return;
-}
+if (savedRequest != null
+
decodedRequestURI.equals(savedRequest.getDecodedRequestURI())
+!authenticate(request, response)) {
+if (log.isDebugEnabled()) {
+log.debug( Failed authenticate() test);
}
+/*
+ * ASSERT: Authenticator already set the appropriate
+ * HTTP status code, so we do not have to do anything
+ * special
+ */
+return;
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57098] Weird Reponse for a HTTP request on HTTPS(SSL) port
https://issues.apache.org/bugzilla/show_bug.cgi?id=57098 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Mark Thomas ma...@apache.org --- Bugzilla is not a support forum. Please use the Apache Tomcat users' mailing list. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1632022 - in /tomcat/trunk/test/org/apache/tomcat/util/http: TestMimeHeaders.java TestMimeHeadersIntegration.java
Author: markt
Date: Wed Oct 15 13:40:12 2014
New Revision: 1632022
URL: http://svn.apache.org/r1632022
Log:
Rename since I need to create some unit tests that don't use Tomcat embedded
Added:
tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeadersIntegration.java
- copied, changed from r1631986,
tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeaders.java
Removed:
tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeaders.java
Copied:
tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeadersIntegration.java
(from r1631986,
tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeaders.java)
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeadersIntegration.java?p2=tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeadersIntegration.javap1=tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeaders.javar1=1631986r2=1632022rev=1632022view=diff
==
--- tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeaders.java
(original)
+++
tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeadersIntegration.java
Wed Oct 15 13:40:12 2014
@@ -39,7 +39,7 @@ import org.apache.catalina.startup.Tomca
import org.apache.catalina.startup.TomcatBaseTest;
import org.apache.catalina.valves.TesterAccessLogValve;
-public class TestMimeHeaders extends TomcatBaseTest {
+public class TestMimeHeadersIntegration extends TomcatBaseTest {
private HeaderCountLogValve alv;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1632027 - /tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeaders.java
Author: markt
Date: Wed Oct 15 13:47:07 2014
New Revision: 1632027
URL: http://svn.apache.org/r1632027
Log:
Add a unit test for the case insensitivity of header names
Added:
tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeaders.java (with
props)
Added: tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeaders.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeaders.java?rev=1632027view=auto
==
--- tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeaders.java (added)
+++ tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeaders.java Wed Oct
15 13:47:07 2014
@@ -0,0 +1,64 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.tomcat.util.http;
+
+import org.junit.Assert;
+import org.junit.Test;
+
+public class TestMimeHeaders {
+
+public static final String HEADER_NAME_LC_STRING = test;
+public static final String HEADER_NAME_UC_STRING = TEST;
+public static final String HEADER_NAME_MIXED_STRING = tEsT;
+
+@Test
+public void testSetValueStringIgnoresCase01() {
+MimeHeaders mh = new MimeHeaders();
+
+mh.setValue(HEADER_NAME_LC_STRING).setString(HEADER_NAME_LC_STRING);
+mh.setValue(HEADER_NAME_UC_STRING).setString(HEADER_NAME_UC_STRING);
+
+Assert.assertEquals(HEADER_NAME_UC_STRING,
mh.getValue(HEADER_NAME_UC_STRING).toString());
+Assert.assertEquals(HEADER_NAME_UC_STRING,
mh.getValue(HEADER_NAME_LC_STRING).toString());
+Assert.assertEquals(HEADER_NAME_UC_STRING,
mh.getValue(HEADER_NAME_MIXED_STRING).toString());
+}
+
+@Test
+public void testSetValueStringIgnoresCase02() {
+MimeHeaders mh = new MimeHeaders();
+
+mh.setValue(HEADER_NAME_UC_STRING).setString(HEADER_NAME_UC_STRING);
+mh.setValue(HEADER_NAME_LC_STRING).setString(HEADER_NAME_LC_STRING);
+
+Assert.assertEquals(HEADER_NAME_LC_STRING,
mh.getValue(HEADER_NAME_LC_STRING).toString());
+Assert.assertEquals(HEADER_NAME_LC_STRING,
mh.getValue(HEADER_NAME_UC_STRING).toString());
+Assert.assertEquals(HEADER_NAME_LC_STRING,
mh.getValue(HEADER_NAME_MIXED_STRING).toString());
+}
+
+@Test
+public void testSetValueStringIgnoresCase03() {
+MimeHeaders mh = new MimeHeaders();
+
+mh.setValue(HEADER_NAME_UC_STRING).setString(HEADER_NAME_UC_STRING);
+
mh.setValue(HEADER_NAME_MIXED_STRING).setString(HEADER_NAME_MIXED_STRING);
+
+Assert.assertEquals(HEADER_NAME_MIXED_STRING,
mh.getValue(HEADER_NAME_LC_STRING).toString());
+Assert.assertEquals(HEADER_NAME_MIXED_STRING,
mh.getValue(HEADER_NAME_UC_STRING).toString());
+Assert.assertEquals(HEADER_NAME_MIXED_STRING,
mh.getValue(HEADER_NAME_MIXED_STRING).toString());
+}
+
+}
Propchange: tomcat/trunk/test/org/apache/tomcat/util/http/TestMimeHeaders.java
--
svn:eol-style = native
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Weird Reponse for a HTTP request on HTTPS(SSL) port
Hi I'am using tomcat 7.0.55 with this configuration: Debian 7.x Java 1.7.0_67-b01 I'am getting some wierd reaction whenever I do a simple HTTP request on the SSL port. Other webserver (nginx) sending a 400 Bad Request response. With Chrome webbrowser a File is being downloaded. At the moment iam not sure if this is a real bug. Chrome 37.0.2062.124 Yours sincerely Stefan
Re: Weird Reponse for a HTTP request on HTTPS(SSL) port
On 15/10/2014 15:12, Stefan Beigel wrote: Hi I'am using tomcat 7.0.55 with this configuration: Debian 7.x Java 1.7.0_67-b01 I'am getting some wierd reaction whenever I do a simple HTTP request on the SSL port. Other webserver (nginx) sending a 400 Bad Request response. With Chrome webbrowser a File is being downloaded. At the moment iam not sure if this is a real bug. Chrome 37.0.2062.124 This belongs on the *users* mailing list. Mark Yours sincerely Stefan - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56397] Establish parallel Maven-based build process
https://issues.apache.org/bugzilla/show_bug.cgi?id=56397 --- Comment #38 from Pierre Viret pierre.vi...@gmail.com --- Something went wrong with the patch: I had renamed the dir: apache-tomcat/src/main/resoucres/ To : apache-tomcat/src/main/resources but maybe the svn mv was not contained in the patch?? Can you please try to svn mv the dir directly? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1632105 - in /tomcat/sandbox/trunk-maven-layout/apache-tomcat/src/main: resoucres/ resources/
Author: markt Date: Wed Oct 15 16:04:19 2014 New Revision: 1632105 URL: http://svn.apache.org/r1632105 Log: Rename missed in previously applied patch Added: tomcat/sandbox/trunk-maven-layout/apache-tomcat/src/main/resources/ - copied from r1631843, tomcat/sandbox/trunk-maven-layout/apache-tomcat/src/main/resoucres/ Removed: tomcat/sandbox/trunk-maven-layout/apache-tomcat/src/main/resoucres/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56397] Establish parallel Maven-based build process
https://issues.apache.org/bugzilla/show_bug.cgi?id=56397 --- Comment #39 from Mark Thomas ma...@apache.org --- That fixed it. It looks like (from a quick glance at the stack traces) the problem is that the mbean-descriptor.xml files are not being included in the JARs. They need to appear in the same package as they do in the source tree. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57099] New: loose parsing of import attribute in page directive screws up SMAP output
https://issues.apache.org/bugzilla/show_bug.cgi?id=57099 Bug ID: 57099 Summary: loose parsing of import attribute in page directive screws up SMAP output Product: Tomcat 7 Version: 7.0.39 Hardware: PC OS: Mac OS X 10.1 Status: NEW Severity: normal Priority: P2 Component: Jasper Assignee: dev@tomcat.apache.org Reporter: dgar...@veracode.com Came across some customer code that had the following in their jsp files: %@ page session=false buffer=8kb import=java.io.*; import java.util.*; import java.text.*; import java.util.Date.*; import java.text.DecimalFormat; import com.xyz.debug.Debug; import com.xyz.failure.*; import com.xyz.messaging.*; import com.xyz.utils.*; import com.xyz.xml_messaging.*; import com.xyz.environment.*; import generated.screening_engine.*; import generated.xml_utils.*; contentType=text/html % Even though the JSP spec says that the import statement should be The value is as in an import declaration in the Java programming language, a (comma separated) list of either a fully qualified Java programming language type name denoting that type, or of a package name followed by the .* string, denoting all the public types declared in that package. this is parsed/compiled by the JSP parser. these folks seem to have stumbled on to a, well, different way of specifying a list of imports. Since the JSP parser only sees a single import and believes it has merely written a single import line, the SMAP numbering ends up being off by, in this case, 12, causing all sorts of fun down the line when trying to map back to original jsp code by way of the SMAP file. In short, it appears that one could, in an import statement, append a semicolon and then put whatever java code they want, and it would go in and get compiled in as long as there weren't any commas in it. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57099] loose parsing of import attribute in page directive screws up SMAP output
https://issues.apache.org/bugzilla/show_bug.cgi?id=57099 Daniel Garcia dgar...@veracode.com changed: What|Removed |Added CC||dgar...@veracode.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56397] Establish parallel Maven-based build process
https://issues.apache.org/bugzilla/show_bug.cgi?id=56397 Pierre Viret pierre.vi...@gmail.com changed: What|Removed |Added Attachment #32108|0 |1 is obsolete|| --- Comment #40 from Pierre Viret pierre.vi...@gmail.com --- Created attachment 32113 -- https://issues.apache.org/bugzilla/attachment.cgi?id=32113action=edit patch for tomcat-maven-layout created with svn diff -x -u Thanks for your hint, you were right: this patch fixes this, the non-java files from the src dir are now added as resources. I had to add dummy files for logs temp dirs to get created (seems assembly won't create empty dirs). Now the server can be started successfully! The default web applications still do not work (some problem with the JSP), I will have to analyse this. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53952] Add support for TLS 1.1 and 1.2
https://issues.apache.org/bugzilla/show_bug.cgi?id=53952 Mark Woon markw...@gmail.com changed: What|Removed |Added CC||markw...@gmail.com --- Comment #30 from Mark Woon markw...@gmail.com --- Another day, another SSL vulnerability. Any chance this will go through any time soon? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56844] Update to OpenSSL 1.0.1j
https://issues.apache.org/bugzilla/show_bug.cgi?id=56844 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Summary|Update to OpenSSL 1.0.1i|Update to OpenSSL 1.0.1j OS||All --- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com --- OpenSSL 1.0.1j was released on 15-Oct-2014. Security advisory: http://www.openssl.org/news/secadv_20141015.txt -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
