[Bug 57129] New: Regression. Load WEB-INF/lib jarfiles in alphabetical order
https://issues.apache.org/bugzilla/show_bug.cgi?id=57129
Bug ID: 57129
Summary: Regression. Load WEB-INF/lib jarfiles in alphabetical
order
Product: Tomcat 8
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: j...@jorgenpersson.se
When the classpath are created for the webapp classloader, the ordering of the
jar files are not the same in Tomcat7 vs Tomcat8.
This is due to that in Tomcat7, the FileDirContext.list(File) method sorts the
jar files in the WEB-ING/lib folder alpabetically:
...
Arrays.sort(names); // Sort alphabetically
NamingEntry entry = null;
for (int i = 0; i names.length; i++) {
...
The new design in Tomcat8 does not do this. I've identified two places where
WEB-INF/lib is read:
StandardRoot.list(String, boolean)
and
DirResourceSet.listWebAppPaths(String)
Even though it is not a requirement that the entries are ordered
alphabetically, it would be nice if they were. And there is no harm in doing it
for web applications that does not depend on classpath ordering.
I've attached a patch file, tomcat8.patch, based on tomcat8 trunk (@ rev.
1633538).
--
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 57129] Regression. Load WEB-INF/lib jarfiles in alphabetical order
https://issues.apache.org/bugzilla/show_bug.cgi?id=57129 --- Comment #1 from Jörgen Persson j...@jorgenpersson.se --- Created attachment 32134 -- https://issues.apache.org/bugzilla/attachment.cgi?id=32134action=edit Adds Arrays.sort(...) in the two identified methods -- 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 57129] Regression. Load WEB-INF/lib jarfiles in alphabetical order
https://issues.apache.org/bugzilla/show_bug.cgi?id=57129 --- Comment #2 from Jörgen Persson j...@jorgenpersson.se --- I found the problem running Linux Mint 17. On Windows 7 64 bit, the files seems to be ordered alphabetically. -- 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 57129] Regression. Load WEB-INF/lib jarfiles in alphabetical order
https://issues.apache.org/bugzilla/show_bug.cgi?id=57129
Mark Thomas ma...@apache.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Mark Thomas ma...@apache.org ---
Applications that depend on JARs being searched for classes in a particular
order are broken and should be fixed.
I am -1 on adding this unncessary bloat to the new resources implementation in
Tomcat 8.
Broken web applications that need a JAR to be searched for classes before all
other JARs can force this via configuration in the context.xml file. Something
along the lines of the following should work:
Resources
!-- Trick to force this JAR to be searched for classes before all others
to work around a Jira bug --
PreResources className=org.apache.catalina.webresources.FileResourceSet
base=${catalina.base}/webapps/jira/WEB-INF/lib/jira-api-6.2.jar
webAppMount=/WEB-INF/lib/jira-api-6.2.jar /
/Resources
--
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
[GUMP@vmgump]: Project tomcat-trunk-validate (in module tomcat-trunk) 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 gene...@gump.apache.org. Project tomcat-trunk-validate has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-validate : Tomcat 8.x, a web server implementing the Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on checkstyle exists, no need to add for property checkstyle.jar. -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/gump_work/build_tomcat-trunk_tomcat-trunk-validate.html Work Name: build_tomcat-trunk_tomcat-trunk-validate (Type: Build) Work ended in a state of : Failed Elapsed: 24 secs Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-6.0-SNAPSHOT.jar -Dexecute.validate=true validate [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-6.0-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-20141022.jar:/srv/gump/public/workspace/apache-commons/cli/target/commons-cli-1.3-SNAPSHOT.jar:/srv/gump/public/workspace/commons-collections-3.x/target/commons-collections-3.3-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/exec/target/comm ons-exec-1.3-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-20141022.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20141022.jar:/srv/gump/public/workspace/apache-commons/validator/dist/commons-validator-20141022.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-19.0-SNAPSHOT.jar - Buildfile: /srv/gump/public/workspace/tomcat-trunk/build.xml build-prepare: [delete] Deleting directory /srv/gump/public/workspace/tomcat-trunk/output/build/temp [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/temp compile-prepare: download-validate: testexist: [echo] Testing for /srv/gump/public/workspace/checkstyle/target/checkstyle-6.0-SNAPSHOT.jar setproxy: downloadzip: validate: [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/res/checkstyle [checkstyle] Running Checkstyle 6.0-SNAPSHOT on 2915 files [checkstyle] /srv/gump/public/workspace/tomcat-trunk/webapps/docs/changelog.xml:161: Line matches the illegal pattern '\s+$'. BUILD FAILED /srv/gump/public/workspace/tomcat-trunk/build.xml:542: Got 1 errors and 0 warnings. Total time: 24 seconds - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/rss.xml - Atom: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 20141022060038, vmgump.apache.org:vmgump:20141022060038 Gump E-mail Identifier (unique within run) #1. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1633551 - /tomcat/trunk/webapps/docs/changelog.xml
Author: markt Date: Wed Oct 22 07:57:34 2014 New Revision: 1633551 URL: http://svn.apache.org/r1633551 Log: Whitespace Modified: tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1633551r1=1633550r2=1633551view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Wed Oct 22 07:57:34 2014 @@ -158,7 +158,7 @@ /fix fix bug57105/bug: When parsing web.xml do not limit the buffer element -of the jsp-property-group element to integer values as the allowed +of the jsp-property-group element to integer values as the allowed values are codelt;numbergt;kb/code or codenone/code. (markt) /fix /changelog - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56780] IBM Java: server.startup gives error java.lang.IllegalArgumentException: Only TLS1.2 protocol can be enabl ed in SP800_131 strict mode
https://issues.apache.org/bugzilla/show_bug.cgi?id=56780 Hariharan, R cloakcaval...@gmail.com changed: What|Removed |Added CC||cloakcaval...@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
svn commit: r1633584 - in /tomcat/trunk: java/org/apache/catalina/realm/RealmBase.java webapps/docs/realm-howto.xml
Author: markt
Date: Wed Oct 22 09:54:39 2014
New Revision: 1633584
URL: http://svn.apache.org/r1633584
Log:
Switch the default character set for command line digesting of passwords from
UTF-8 to the system encoding as per kkolinko's review comment.
Modified:
tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java
tomcat/trunk/webapps/docs/realm-howto.xml
Modified: tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java?rev=1633584r1=1633583r2=1633584view=diff
==
--- tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java (original)
+++ tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java Wed Oct 22
09:54:39 2014
@@ -1387,16 +1387,17 @@ public abstract class RealmBase extends
// - Static Methods
-
/**
- * Digest password using the algorithm specified and
- * convert the result to a corresponding hex string.
- * If exception, the plain credentials string is returned
+ * Digest password using the algorithm specified and convert the result to
a
+ * corresponding hex string.
+ *
+ * @param credentials Password or other credentials to use in
authenticating
+ *this username
+ * @param algorithm Algorithm used to do the digest
+ * @param encodingCharacter encoding of the string to digest
*
- * @param credentials Password or other credentials to use in
- * authenticating this username
- * @param algorithm Algorithm used to do the digest
- * @param encoding Character encoding of the string to digest
+ * @return The digested credentials as a hex string or the original plain
+ * text credentials if an error occurs.
*/
public static final String Digest(String credentials, String algorithm,
String encoding) {
@@ -1433,8 +1434,9 @@ public abstract class RealmBase extends
* credential. If not specified a default of SHA-512 will
be
* used./li
* lib-e/b - The encoding to use for any byte to/from character
- * conversion that may be necessary. If not specified, a
- * default of UTF-8 will be used./li
+ * conversion that may be necessary. If not specified, the
+ * system encoding ({@link Charset#defaultCharset()}) will
+ * be used./li
* lib-i/b - The number of iterations to use when generating the
* stored credential. If not specified, the default for the
* CredentialHandler will be used./li
@@ -1456,11 +1458,12 @@ public abstract class RealmBase extends
* li{@link MessageDigestCredentialHandler}/li
* li{@link SecretKeyCredentialHandler}/li
* /ul
+ * @param args The parameters passed on the command line
*/
public static void main(String args[]) {
String algorithm = SHA-512;
-String encoding = UTF-8;
+String encoding = Charset.defaultCharset().name();
int saltLength = -1;
int iterations = -1;
int keyLength = -1;
Modified: tomcat/trunk/webapps/docs/realm-howto.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/realm-howto.xml?rev=1633584r1=1633583r2=1633584view=diff
==
--- tomcat/trunk/webapps/docs/realm-howto.xml (original)
+++ tomcat/trunk/webapps/docs/realm-howto.xml Wed Oct 22 09:54:39 2014
@@ -189,8 +189,8 @@ techniques are supported:/p
liIf you are writing an application that needs to calculate digested
passwords dynamically, call the static codeDigest()/code method of the
codeorg.apache.catalina.realm.RealmBase/code class, passing the
-cleartext password and the digest algorithm name as arguments. This
-method will return the digested password./li
+cleartext password, the digest algorithm name and the encoding as
arguments.
+This method will return the digested password./li
liIf you want to execute a command line utility to calculate the digested
password, simply execute
sourceCATALINA_HOME/bin/digest.[bat|sh] -a {algorithm}
{cleartext-password}/source
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1633589 - in /tomcat/trunk: java/org/apache/catalina/realm/RealmBase.java webapps/docs/realm-howto.xml
Author: markt
Date: Wed Oct 22 10:22:16 2014
New Revision: 1633589
URL: http://svn.apache.org/r1633589
Log:
Modify the handling of defaults for -a and -h as per kkolinko's review.
Modified:
tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java
tomcat/trunk/webapps/docs/realm-howto.xml
Modified: tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java?rev=1633589r1=1633588r2=1633589view=diff
==
--- tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java (original)
+++ tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java Wed Oct 22
10:22:16 2014
@@ -80,6 +80,9 @@ public abstract class RealmBase extends
new ArrayList();
static {
+// Order is important since it determines the search order for a
+// matching handler if only an algorithm is specified when calling
+// main()
credentialHandlerClasses.add(MessageDigestCredentialHandler.class);
credentialHandlerClasses.add(SecretKeyCredentialHandler.class);
}
@@ -1462,11 +1465,15 @@ public abstract class RealmBase extends
*/
public static void main(String args[]) {
-String algorithm = SHA-512;
-String encoding = Charset.defaultCharset().name();
+// Use negative values since null is not an option to indicate 'not
set'
int saltLength = -1;
int iterations = -1;
int keyLength = -1;
+// Default
+String encoding = Charset.defaultCharset().name();
+// Default values for these depend on whether either of them are set on
+// the command line
+String algorithm = null;
String handlerClassName = null;
if (args.length == 0) {
@@ -1511,6 +1518,19 @@ public abstract class RealmBase extends
argIndex += 2;
}
+// Determine defaults for -a and -h. The rules are more complex to
+// express than the implementation:
+// - if neither -a nor -h is set, use SHA-512 and
+// MessageDigestCredentialHandler
+// - if only -a is set the built-in handlers will be searched in order
+// (MessageDigestCredentialHandler, SecretKeyCredentialHandler) and
+// the first handler that supports the algorithm will be used
+// - if only -h is set no default will be used for -a. The handler may
+// or may nor support -a and may or may not supply a sensible default
+if (algorithm == null handlerClassName == null) {
+algorithm = SHA-512;
+}
+
CredentialHandler handler = null;
if (handlerClassName == null) {
Modified: tomcat/trunk/webapps/docs/realm-howto.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/realm-howto.xml?rev=1633589r1=1633588r2=1633589view=diff
==
--- tomcat/trunk/webapps/docs/realm-howto.xml (original)
+++ tomcat/trunk/webapps/docs/realm-howto.xml Wed Oct 22 10:22:16 2014
@@ -209,13 +209,42 @@ techniques are supported:/p
not specified in web.xml, the default value of codeAuthentication
required/code is used./p
-pNon-ASCII usernames and/or passwords are supported using/p
+pUsernames and/or passwords using encodings other than the platform default
+are supported using/p
sourceCATALINA_HOME/bin/digest.[bat|sh] -a {algorithm} -e {encoding}
{input}/source
-pbut care is required to ensure that the non-ASCII input is
-correctly passed to the digester.
-The digester returns code{input}:{digest}/code. If the input appears
-corrupted in the return, the digest will be invalid./p
-
+pbut care is required to ensure that the input is correctly passed to the
+digester. The digester returns code{input}:{digest}/code. If the input
+appears corrupted in the return, the digest will be invalid./p
+
+pThe full syntax of codeCATALINA_HOME/bin/digest.[bat|sh]/code is:/p
+sourceCATALINA_HOME/bin/digest.[bat|sh] [-a lt;algorithmgt;] [-e
lt;encodinggt;]
+[-i lt;iterationsgt;] [-s lt;salt-lengthgt;] [-k
lt;key-lengthgt;]
+[-h lt;handler-class-namegt;] lt;credentialsgt;
+/source
+ul
+lib-a/b - The algorithm to use to generate the stored
+credential. If not specified, the default for the handler will
+be used. If neither handler nor algorithm is specified then a
+default of codeSHA-512/code will be used/li
+lib-e/b - The encoding to use for any byte to/from character
+conversion that may be necessary. If not specified, the
+system encoding (codeCharset#defaultCharset()/code) will
+be used./li
+lib-i/b - The number of iterations to use when generating the
+stored credential. If not specified, the default for the
+CredentialHandler will be
Re: digest.bat (RealmBase.main()) is broken in current Tomcat 8 trunk. Tomcat 8.0.14 is OK.
On 17/10/2014 14:13, Konstantin Kolinko wrote: 2014-09-30 19:22 GMT+04:00 Konstantin Kolinko knst.koli...@gmail.com: 2014-09-29 14:43 GMT+04:00 Mark Thomas ma...@apache.org: On 27/09/2014 15:52, Konstantin Kolinko wrote: () 4) The current javadoc for RealmBase.main() says that algorithm (-a) is not required and If not specified a default of SHA-512 will be used. I wonder whether that is justified. That is what is currently implemented. Happy to discuss changes but SHA-512 doesn't seem unreasonable to me. I think there is a contradiction between -a algorithm and -h credential handler implementation class keys: 1) If -h is used I think it shall default to whatever default algorithm the credential handler implements. 2) Custom credential handler implementations may lack setAlgorithm() method. I think that one of (-a, -h) is required, with no default for either. The old code had no default for algorithm. I agree with the two issues above but I have a different solution. If neither -a or -h is specified, SHA-512 and MessageDigestCredentialHandler will be used. If only -a is specified, the built-in handlers will be searched in order (MessageDigestCredentialHandler, SecretKeyCredentialHandler) and the first handler that supports the algorithm will be used. If only -h is specified, no default will be used for -a. The handler may or may nor support -a and may or may not supply a sensible default. String encoding = UTF-8; I think it shall use system encoding, because the value is passed on the command line and is not read from file etc. Fixed. BTW, That chapter in realm-howto in Tomcat 8 needs an update for the new features of digest.sh / RealmBase.main(). Fixed. I think that this have to be fixed before tagging next Tomcat 8 release. I believe I have address all the outstanding concerns with these changes. Let me know if I have missed something. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1633595 - /tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java
Author: markt
Date: Wed Oct 22 11:04:31 2014
New Revision: 1633595
URL: http://svn.apache.org/r1633595
Log:
Java 9 Javadoc issues
Modified:
tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java
Modified: tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java?rev=1633595r1=1633594r2=1633595view=diff
==
--- tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java (original)
+++ tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java Wed Oct 22
11:04:31 2014
@@ -226,25 +226,27 @@ public abstract class RealmBase extends
/**
* Return the all roles mode.
+ * @return A string representation of the current all roles mode
*/
public String getAllRolesMode() {
-
return allRolesMode.toString();
-
}
/**
* Set the all roles mode.
+ * @param allRolesMode A string representation of the new all roles mode
*/
public void setAllRolesMode(String allRolesMode) {
-
this.allRolesMode = AllRolesMode.toMode(allRolesMode);
-
}
+
/**
- * Return the digest algorithm used for storing credentials.
+ * Return the digest algorithm used for storing credentials.
+ *
+ * @return The currently configured algorithm used to digest stored
+ * credentials
*
* @deprecated This will be removed in Tomcat 9.0.x as it has been
replaced
* by the CredentialHandler
@@ -346,11 +348,10 @@ public abstract class RealmBase extends
/**
* Return the validate certificate chains flag.
+ * @return The value of the validate certificate chains flag
*/
public boolean getValidate() {
-
-return (this.validate);
-
+return validate;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57130] New: Allow digest.sh to accept password from a file or from stdin
https://issues.apache.org/bugzilla/show_bug.cgi?id=57130 Bug ID: 57130 Summary: Allow digest.sh to accept password from a file or from stdin Product: Tomcat 8 Version: 8.0.14 Hardware: PC Status: NEW Severity: enhancement Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: knst.koli...@gmail.com This is inspired by discussions about adding --password-file option to subversion command line tool at dev at subversion.a.o mailing list. Links to threads: The --password and clumsy users issue [PATCH]: Add --password-file and --password-envvar http://subversion.markmail.org/thread/xdcfgujgqvgytx64 http://subversion.markmail.org/thread/jgbu75eiradryodf The digest.sh utility in Tomcat accepts passwords as arguments on the command line and prints hashed representation for them to System.out. Proposal is to 1) Provide an option to specify a file name to read passwords from 2) If file name is - then treat it as System.in 3) Add support for option -- to specify the end of list of options Notes: Implementation goes into RealmBase.java, documentation goes into realm-howto.xml. r1633589 can be used for a reference. -- 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: digest.bat (RealmBase.main()) is broken in current Tomcat 8 trunk. Tomcat 8.0.14 is OK.
2014-10-22 14:22 GMT+04:00 Mark Thomas ma...@apache.org: On 17/10/2014 14:13, Konstantin Kolinko wrote: 2014-09-30 19:22 GMT+04:00 Konstantin Kolinko knst.koli...@gmail.com: 2014-09-29 14:43 GMT+04:00 Mark Thomas ma...@apache.org: On 27/09/2014 15:52, Konstantin Kolinko wrote: () 4) The current javadoc for RealmBase.main() says that algorithm (-a) is not required and If not specified a default of SHA-512 will be used. I wonder whether that is justified. That is what is currently implemented. Happy to discuss changes but SHA-512 doesn't seem unreasonable to me. I think there is a contradiction between -a algorithm and -h credential handler implementation class keys: 1) If -h is used I think it shall default to whatever default algorithm the credential handler implements. 2) Custom credential handler implementations may lack setAlgorithm() method. I think that one of (-a, -h) is required, with no default for either. The old code had no default for algorithm. I agree with the two issues above but I have a different solution. If neither -a or -h is specified, SHA-512 and MessageDigestCredentialHandler will be used. If only -a is specified, the built-in handlers will be searched in order (MessageDigestCredentialHandler, SecretKeyCredentialHandler) and the first handler that supports the algorithm will be used. If only -h is specified, no default will be used for -a. The handler may or may nor support -a and may or may not supply a sensible default. OK for me, if you find SHA-512 default useful. It is just my personal preference to ask the caller to specify algorithm name explicitly. (The actual algorithm that a user needs depends upon how the realm is configured in server.xml/context.xml. I think that not much typing is saved by having a default here. I think that many tools such as openssl do not have default algorithm names in their command line. E.g. I do not see any default for genpkey command https://www.openssl.org/docs/apps/genpkey.html ) I filed an issue for further improvements, https://issues.apache.org/bugzilla/show_bug.cgi?id=57130 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56425] Unable to find unambiguous method in class String
https://issues.apache.org/bugzilla/show_bug.cgi?id=56425 --- Comment #5 from Violeta Georgieva violet...@apache.org --- Created attachment 32137 -- https://issues.apache.org/bugzilla/attachment.cgi?id=32137action=edit Test The following test reproduces the issue. -- 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 57129] Regression. Load WEB-INF/lib jarfiles in alphabetical order
https://issues.apache.org/bugzilla/show_bug.cgi?id=57129 --- Comment #4 from Christopher Schultz ch...@christopherschultz.net --- (In reply to Jörgen Persson from comment #2) I found the problem running Linux Mint 17. On Windows 7 64 bit, the files seems to be ordered alphabetically. This has to do with the order in which the directory entries are returned by the underlying file system. Neither NTFS nor extXfs, etc. guarantee in which order directory entries are returned from a readdir. What you are observing on Windows versus Linux is entirely coincidental. -- 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 57130] Allow digest.sh to accept password from a file or from stdin
https://issues.apache.org/bugzilla/show_bug.cgi?id=57130 Christopher Schultz ch...@christopherschultz.net changed: What|Removed |Added OS||All --- Comment #1 from Christopher Schultz ch...@christopherschultz.net --- This would be a good bug for someone who would like to get their name in the changelog. Any takers? (Is there an easy bug flag that we can set to make finding them easier in BZ?) -- 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: [VOTE] Release Apache Tomcat Native 1.1.32
Mark, On 21.10.2014 11:05, Mark Thomas wrote: Version 1.1.32 includes the following changes: - Add support for TLS v1.1 and TLS v1.2 - Windows binaries built with APR 1.5.1 and OpenSSL 1.0.1j The Apache Tomcat Native (--1.1.31--) 1.1.32 is [X] Stable, go ahead and release [ ] Broken because of ... (non-binding) Tested with Tomcat 8.0.14 and 8-trunk. 8.0.14 reports, as expected: An invalid value [TLSv1+TLSv1.1+TLSv1.2] was provided for the SSLProtocol attribute 8-trunk works fine. SSLLabs reports that the server is not vulnerable to POODLE. -Ognjen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53411] NullPointerException in org.apache.tomcat.util.buf.CharChunk
https://issues.apache.org/bugzilla/show_bug.cgi?id=53411 Hariharan, R cloakcaval...@gmail.com changed: What|Removed |Added CC||cloakcaval...@gmail.com --- Comment #7 from Hariharan, R cloakcaval...@gmail.com --- Created attachment 32138 -- https://issues.apache.org/bugzilla/attachment.cgi?id=32138action=edit Patch for the enhancements mentioned above I have incorporated the changes mentioned above, with this patch. P.S. This is my first patch submission. Let me know if I could do anything to help better. -- 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 #5 from Mark Thomas ma...@apache.org --- A note for folks trying to reproduce this, the Tomcat JARs need to be signed as well. -- 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: r1633688 - in /tomcat/trunk: java/org/apache/tomcat/websocket/AsyncChannelGroupUtil.java webapps/docs/changelog.xml
Author: markt
Date: Wed Oct 22 19:29:25 2014
New Revision: 1633688
URL: http://svn.apache.org/r1633688
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=57091
Work around the behaviour of the Oracle JRE when creating new threads in an
applet environment that breaks the WebSocket client implementation.
Patch provided by Niklas Hallqvist.
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/AsyncChannelGroupUtil.java
tomcat/trunk/webapps/docs/changelog.xml
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/AsyncChannelGroupUtil.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/AsyncChannelGroupUtil.java?rev=1633688r1=1633687r2=1633688view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/websocket/AsyncChannelGroupUtil.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/websocket/AsyncChannelGroupUtil.java
Wed Oct 22 19:29:25 2014
@@ -18,6 +18,8 @@ package org.apache.tomcat.websocket;
import java.io.IOException;
import java.nio.channels.AsynchronousChannelGroup;
+import java.security.AccessController;
+import java.security.PrivilegedAction;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.SynchronousQueue;
import java.util.concurrent.ThreadFactory;
@@ -106,12 +108,21 @@ public class AsyncChannelGroupUtil {
private AtomicInteger count = new AtomicInteger(0);
@Override
-public Thread newThread(Runnable r) {
-Thread t = new Thread(r);
-t.setName(WebSocketClient-AsyncIO- + count.incrementAndGet());
-t.setContextClassLoader(this.getClass().getClassLoader());
-t.setDaemon(true);
-return t;
+public Thread newThread(final Runnable r) {
+// Create the new Thread within a doPrivileged block to ensure that
+// the thread inherits the current ProtectionDomain which is
+// essential to be able to use this with a Java Applet. See
+// https://issues.apache.org/bugzilla/show_bug.cgi?id=57091
+return AccessController.doPrivileged(new
PrivilegedActionThread() {
+@Override
+public Thread run() {
+Thread t = new Thread(r);
+t.setName(WebSocketClient-AsyncIO- +
count.incrementAndGet());
+t.setContextClassLoader(this.getClass().getClassLoader());
+t.setDaemon(true);
+return t;
+}
+});
}
}
}
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1633688r1=1633687r2=1633688view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Wed Oct 22 19:29:25 2014
@@ -233,6 +233,11 @@
Add null checks for arguments in remote endpoint. (remm/kkolinko)
/fix
fix
+bug57091/bug: Work around the behaviour of the Oracle JRE when
+creating new threads in an applet environment that breaks the WebSocket
+client implementation. Patch provided by Niklas Hallqvist. (markt)
+ /fix
+ fix
bug57118/bug: Ensure that that an codeEncodeException/code is
thrown by codeRemoteEndpoint.Basic.sendObject(Object)/code rather
than an codeIOException/code when no suitable codeEncoder/code
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1633689 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/tomcat/websocket/AsyncChannelGroupUtil.java webapps/docs/changelog.xml
Author: markt
Date: Wed Oct 22 19:30:45 2014
New Revision: 1633689
URL: http://svn.apache.org/r1633689
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=57091
Work around the behaviour of the Oracle JRE when creating new threads in an
applet environment that breaks the WebSocket client implementation.
Patch provided by Niklas Hallqvist.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/websocket/AsyncChannelGroupUtil.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1633688
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/websocket/AsyncChannelGroupUtil.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/websocket/AsyncChannelGroupUtil.java?rev=1633689r1=1633688r2=1633689view=diff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/websocket/AsyncChannelGroupUtil.java
(original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/websocket/AsyncChannelGroupUtil.java
Wed Oct 22 19:30:45 2014
@@ -18,6 +18,8 @@ package org.apache.tomcat.websocket;
import java.io.IOException;
import java.nio.channels.AsynchronousChannelGroup;
+import java.security.AccessController;
+import java.security.PrivilegedAction;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.SynchronousQueue;
import java.util.concurrent.ThreadFactory;
@@ -106,12 +108,21 @@ public class AsyncChannelGroupUtil {
private AtomicInteger count = new AtomicInteger(0);
@Override
-public Thread newThread(Runnable r) {
-Thread t = new Thread(r);
-t.setName(WebSocketClient-AsyncIO- + count.incrementAndGet());
-t.setContextClassLoader(this.getClass().getClassLoader());
-t.setDaemon(true);
-return t;
+public Thread newThread(final Runnable r) {
+// Create the new Thread within a doPrivileged block to ensure that
+// the thread inherits the current ProtectionDomain which is
+// essential to be able to use this with a Java Applet. See
+// https://issues.apache.org/bugzilla/show_bug.cgi?id=57091
+return AccessController.doPrivileged(new
PrivilegedActionThread() {
+@Override
+public Thread run() {
+Thread t = new Thread(r);
+t.setName(WebSocketClient-AsyncIO- +
count.incrementAndGet());
+t.setContextClassLoader(this.getClass().getClassLoader());
+t.setDaemon(true);
+return t;
+}
+});
}
}
}
Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1633689r1=1633688r2=1633689view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Wed Oct 22 19:30:45 2014
@@ -146,6 +146,11 @@
Add null checks for arguments in remote endpoint. (remm/kkolinko)
/fix
fix
+bug57091/bug: Work around the behaviour of the Oracle JRE when
+creating new threads in an applet environment that breaks the WebSocket
+client implementation. Patch provided by Niklas Hallqvist. (markt)
+ /fix
+ fix
bug57118/bug: Ensure that that an codeEncodeException/code is
thrown by codeRemoteEndpoint.Basic.sendObject(Object)/code rather
than an codeIOException/code when no suitable codeEncoder/code
-
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 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Mark Thomas ma...@apache.org --- Thanks for the test case. Very helpful. I can repeat this issue with Java 8 and Java 7 and I have applied your suggested patch to 8.0.x for 8.0.15 onwards and 7.0.x for 7.0.57 onwards. On a related topic, would it be helpful at all if the Tomcat JARs were signed by the ASF (we recently started to use Symantec's code signing service). If this would be useful, please open a new enhancement request and we'll figure out how to fit JSAR signing into the build process. -- 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 53411] NullPointerException in org.apache.tomcat.util.buf.CharChunk
https://issues.apache.org/bugzilla/show_bug.cgi?id=53411 --- Comment #8 from Mark Thomas ma...@apache.org --- Thanks for the patch. Don't be concerned about how much of the patch I am suggesting you change (most of it). The first patch I proposed was torn apart beyond recognition before it got anywhere near the Tomcat code base. The view expressed by Kubak that Tomcat should not start if the default host is not valid is not the consensus opinion of the Tomcat developers. It is safe to assume that Konstatin's comments (as a committer) does represent the consensus opinion unless another committer comments otherwise (in which case expect a discussion on the dev list to reach a consensus). I suggest you go through Konstantin's comments in comment #5 one by one and address each of them in your patch. -- 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 56780] IBM Java: server.startup gives error java.lang.IllegalArgumentException: Only TLS1.2 protocol can be enabl ed in SP800_131 strict mode
https://issues.apache.org/bugzilla/show_bug.cgi?id=56780 --- Comment #7 from Mark Thomas ma...@apache.org --- Is there a way to get the sslProtocol attribute specified for the connector in the server.xml? That has the value that should be used to create the SSLContext. That is what is used. If you set sslProtocol=TLSv1.2 and sslEnabledProtocols=TLSv1.2 you should get past the exception you are currently seeing. I now see a problem with cipher suites in my test environment. I'm still looking at whether this is a configuration problem or a Tomcat bug. The jury is out at this point so I am leaving this issue open. -- 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 #7 from Niklas Hallqvist niklas+apa...@appli.se --- (In reply to Mark Thomas from comment #6) Thanks for the test case. Very helpful. I can repeat this issue with Java 8 and Java 7 and I have applied your suggested patch to 8.0.x for 8.0.15 onwards and 7.0.x for 7.0.57 onwards. On a related topic, would it be helpful at all if the Tomcat JARs were signed by the ASF (we recently started to use Symantec's code signing service). If this would be useful, please open a new enhancement request and we'll figure out how to fit JSAR signing into the build process. Sorry I forgot to tell the tomcat jars needed to be signed as well. I am not sure it will be helpful, maybe it will now, but at least at some point in time, mixed signers were not working too well in our applet setups, so we decided sign all jars ourselves, 3rd party or not, with our own certificate as a standard practice these days. Of course we would have the potential to verify the jars' origin if they were signed, but we would still overwrite the signature with our own before deployment. Thanks for including the fix, this way I don't need to have a customized tomcat version for our needs. -- 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 56780] IBM Java: server.startup gives error java.lang.IllegalArgumentException: Only TLS1.2 protocol can be enabl ed in SP800_131 strict mode
https://issues.apache.org/bugzilla/show_bug.cgi?id=56780 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Mark Thomas ma...@apache.org --- I have confirmed that this is a configuration issue. A side effect of configuring strict SP800-131a mode and how Tomcat determines the available ciphers is that the default set of configured ciphers ends up being null. The simplest workaround to get to a working system is to use ciphers=ALL. In strict SP800-131a mode that should be a safe option. If you want to further restrict the ciphers list you can configure an explicit list of ciphetrs. I am restoring this issue to FIXED since the additional issues raised since the original bug was fixed in 7.0.56 are configuration issues not coding bugs. -- 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 57132] New: ImportHandler.resolveClass() fails to report conflicting import when called repeatedly
https://issues.apache.org/bugzilla/show_bug.cgi?id=57132 Bug ID: 57132 Summary: ImportHandler.resolveClass() fails to report conflicting import when called repeatedly Product: Tomcat 8 Version: 8.0.14 Hardware: PC Status: NEW Severity: minor Priority: P2 Component: EL Assignee: dev@tomcat.apache.org Reporter: knst.koli...@gmail.com I noted this issue when reviewing ImportHandler code after r1633440. I have test case that demonstrates it, but I do not have a fix yet. javax.el.ImportHandler.resolveClass(String name) should throw an ELException if the same class can be ambiguously found in several packages. To do so, it relies on calling findClass(className, true) and on clazzes field that is a cache of classes keyed by their simple class names. A simple class name is the name without its package. If resolveClass(foo) finds class foo in several packages then the first call to findClass() updates the clazzes cache and the second call finds the duplicate when trying to update the cache with a different class. If resolveClass(foo) call is repeated, expected result is to report the error again. The actual result is that the first thing it does is to look into the cache. It finds the first class there and returns it without any errors. -- 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 57132] ImportHandler.resolveClass() fails to report conflicting import when called repeatedly
https://issues.apache.org/bugzilla/show_bug.cgi?id=57132 --- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com --- Created attachment 32139 -- https://issues.apache.org/bugzilla/attachment.cgi?id=32139action=edit 2014-10-22_tc8_57132_testcases.patch Updated testcases for TestImportHandler to test that duplicate calls still report an error. A comment in ImportHandler class shows my first idea on fixing this. If I remove first duplicate from the cache it fixes duplicate check in resolveClass() but breaks duplicate check in importClass(). I think that if I move duplicate removal from the cache into resolveClass() method itself, it will be fixed. But maybe there is a more clean solution. BTW, there is no control that the class name argument in resolveClass() is actually a simple name without a package. JavaEE javadoc says that it should be simple name, but there is no control of that fact. JavaEE does not say whether it is ELException or IAE to be thrown if such a check were added. I think it is an ELException. [1] [1] http://docs.oracle.com/javaee/7/api/javax/el/ImportHandler.html -- 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 56780] IBM Java: server.startup gives error java.lang.IllegalArgumentException: Only TLS1.2 protocol can be enabl ed in SP800_131 strict mode
https://issues.apache.org/bugzilla/show_bug.cgi?id=56780
--- Comment #9 from Konstantin Kolinko knst.koli...@gmail.com ---
1. If IllegalArgumentException is thrown from static{} block of a class, is it
fatal for the class or not?
If it were fatal, the static{} block should have try/catch for
IllegalArgumentException.
OK - JSSESocketFactory in Tomcat 7 has such catch, but Tomcat 6 does not have
it yet.
2. This affects RFC_5746_SUPPORTED flag as well, as it will not be initialized
and will remain in the state of false.
3. Is it possible to try several names in turn in
SSLContext.getInstance(TLS);
such as TLS, TLSv1.1 and TLSv1.2?
4. If this results in null value for DEFAULT_SERVER_PROTOCOLS then maybe
a) Report some error when DEFAULT_SERVER_PROTOCOLS is null?
From comment 5 we are lucky that passing the null to JRE API call results in an
IllegalArgumentException with some decent message. I feared that it would be a
NullPointerException.
b) Replace it with an empty String[] array. I think the message from JRE will
be more near to the actual 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
svn commit: r1633726 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko
Date: Wed Oct 22 22:57:19 2014
New Revision: 1633726
URL: http://svn.apache.org/r1633726
Log:
Update vote and comment
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1633726r1=1633725r2=1633726view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Oct 22 22:57:19 2014
@@ -60,17 +60,24 @@ PATCHES PROPOSED TO BACKPORT:
* Mitigate POODLE by disabling SSLv3 by default for JSSE
http://people.apache.org/~markt/patches/2014-10-21-poodle-tc6-v2.patch
+1: markt, schultz
+ +1: kkolinko (several comments below)
-1:
- -0: kkolinko: I think that JSSESocketFactory.getEnabledProtocols() shall
- not return DEFAULT_SERVER_PROTOCOLS list in case if there are no
- matches. This behaviour silently enables default list of protocols,
- instead of erroring out.
- This bug did exist before this patch, so I filed
-https://issues.apache.org/bugzilla/show_bug.cgi?id=57116
-
- I wish there were some debug logging to see what protocols are being
- filtered out by if (protocol.contains(SSL)).
- markt: Addressed in v2 patch
+ kkolinko:
+ Good.
+ I think this makes BZ 57116 fixed as well.
+ Several notes:
+ 1) From BZ 56780 the static{} block in JSSESocketFactory
+ needs try/catch(IllegalArgumentException),
+ like it is already done in Tomcat 7 in r1615951
+
+ 2) In getEnabledProtocols() the
+if (requestedProtocols == null) { return DEFAULT_SERVER_PROTOCOLS; }
+ block can be moved several lines earlier.
+
+ 3) From BZ 56780 the DEFAULT_SERVER_PROTOCOLS value might result as
+ null. I am afraid that passing that null to Java APIs will result in
+ some cryptic messages. This question may be addressed later via BZ 56780.
+https://issues.apache.org/bugzilla/show_bug.cgi?id=56780#c9
schultz: it's not clear from the code what will happen if
DEFAULT_SERVER_PROTOCOLS remains null. Would it be more clear
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-trunk-test-apr (in module tomcat-trunk) 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 gene...@gump.apache.org. Project tomcat-trunk-test-apr has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-test-apr : Tomcat 8.x, a web server implementing the Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-apr/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz. -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/logs-APR -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/test-tmp-APR/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-apr/gump_work/build_tomcat-trunk_tomcat-trunk-test-apr.html Work Name: build_tomcat-trunk_tomcat-trunk-test-apr (Type: Build) Work ended in a state of : Failed Elapsed: 25 mins 39 secs Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Djunit.jar=/srv/gump/public/workspace/junit/target/junit-4.12-SNAPSHOT.jar -Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-2.2-SNAPSHOT.jar -Dtest.reports=output/logs-APR -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20141023-native-src.tar.gz -Dexamples.sources.skip=true -Djdt.jar=/srv/gump/packages/eclipse/plugins/P20140317-1600/ecj-P20140317-1600.jar -Dtest.apr.loc=/srv/gump/public/workspace/tomcat-native/dest-20141023/lib -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-20141023.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20141023-native-src.tar.gz -Dtest.temp=output/test-tmp-APR -Dtest.accesslog=true -Dexecute.test.nio=false -Dtest.openssl.path=/srv/gump/public/workspace/openssl/dest-20141023/bin/openssl -Dexecute.test.apr=true -Dexecute.test.bio=false -Dexecute.test.nio2=false -Deasymock.jar=/srv/gump/public/workspace/easymock/easymock/target/easymock-3.3-SNAPSHOT.jar -Dhamcrest.jar=/srv/gump/public/workspace/hamcrest/build/hamcrest-all-20141023.jar -Dcglib.jar=/srv/gump/packages/cglib/cglib-nodep-2.2.jar test [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-trunk/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/servlet-api.ja
