[Bug 56397] Establish parallel Maven-based build process
https://issues.apache.org/bugzilla/show_bug.cgi?id=56397 --- Comment #20 from Pierre Viret --- Created attachment 32044 --> https://issues.apache.org/bugzilla/attachment.cgi?id=32044&action=edit patch to be applied in tomcat_maven_layout created with "svn diff" I have created the necessary source directories and updated the svn:externals to select only the source files needed by each component. I can build the master project successfully in NetBeans. Can you please check & commit the patch? The next step will be to create the structure & externals for the tests. I have met following issue: - tomcat-util / tomcat-util-scan: org.apache.tomcat.util.file is in both components as defined in the ant file patterns. As tomcat-util-scan depends on tomcat-util I propose to remove it from tomcat-util-scan. - tomcat-api / tomcat-dbcp: org/apache/tomcat/dbcp is in both components as defined in the ant file patterns. Is it necessary or should I remove it from tomcat-api? I was positively surprised with svn externals: it is possible to set the svn:externals property on a directory which I have simply added to svn, and then with svn update to populate it's content, even without having committed the directory. So I (unfortunately ;-) ) do not need to be able to commit to svn myself. -- 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
[GitHub] tomcat-maven-plugin pull request: Adds support for a custom war fi...
GitHub user alex3305 opened a pull request:
https://github.com/apache/tomcat-maven-plugin/pull/11
Adds support for a custom war file name
Currently the war name is always equals to
${project.build.directory}/${project.build.finalName}.war. This is overridable
through the pom file in a project, but sometimes this behaviour is undesirable.
That's whythis pull request adds support for a custom war name through the
command line.
This pull request is divided into two seperate commits, one for tomcat6 and
the other for tomcat7.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/alex3305/tomcat-maven-plugin trunk
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tomcat-maven-plugin/pull/11.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #11
commit 21b38b360540981609affa7fa796e94368bced0b
Author: Alex van den Hoogen
Date: 2014-09-23T09:34:34Z
[tomcat-6] Adds support for a custom war file name
Currently the war name is always equals to
${project.build.directory}/${project.build.finalName}.war. This is overridable
through the pom file in a project, but sometimes this behaviour is undesirable.
That's why this commit adds support for a custom war name through the command
line.
commit d251dbc5c342611dfb7303b603dd7da0735d69ba
Author: Alex van den Hoogen
Date: 2014-09-23T09:35:03Z
[tomcat-7] Adds support for a custom war file name
Currently the war name is always equals to
${project.build.directory}/${project.build.finalName}.war. This is overridable
through the pom file in a project, but sometimes this behaviour is undesirable.
That's why this commit adds support for a custom war name through the command
line.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Discussion of pluggable password-derivation in Realms [Bug 56403]
On 23/09/2014 00:56, "Gabriel E. Sánchez Martínez" wrote: > > On 09/17/2014 04:36 AM, Mark Thomas wrote: >> On 16/09/2014 22:14, Christopher Schultz wrote: >>> Mark, >>> >>> On 9/16/14 3:39 PM, Mark Thomas wrote: Updated patch: http://people.apache.org/~markt/patches/2014-09-16-bug56403-tc8-v2.patch > It's looking good! I have an updated version I need to upload that addresses the remaining issues. > This would be good. One could have an array of CredentialHandler to > check in order. Is the idea that a password stored in an old format > would be matched using the old CredentialHandler and (upon first match) > stored in the upgraded format (the first CredentialHandler)? I assume > the same idea goes for when the same CredentialHandler is used but the > number of iterations has changed. The Realm API has no mechanism up writing to storage. That doesn't stop a custom realm doing this but it isn't (currently) part of Tomcat's API. > I saw that String.equals(String s) is being used. I'm not familiar with > the implementation but I imagine that if the string lengths differ or if > the first characters don't match, for example, the method returns false > without checking the rest of the characters. Perhaps that could lead to > a small vulnerability in which through many attempts and timing an an > attacker can infer whether the password length, etc. is right. I've > seen some implementations use a SecureEquals that tries to take > approximately the same time by comparing all characters of the strings > even if the lengths or first characters don't match. Is this a real > concern, or only theory? It is a real concern in that such an attack is possible. However the number of requests necessary for such an attack to be successful are far higher than the limits imposed by the LockOutRealm so Tomcat should be protected against this attack. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 51181] Add support for Web Sockets
https://issues.apache.org/bugzilla/show_bug.cgi?id=51181 --- Comment #65 from Konstantin Kolinko --- (In reply to Mark Thomas from comment #64) > The plan is: > 1. Add the JSR 356 implementation to Tomcat 7 > 2. Deprecate Tomcat's proprietary API in Tomcat 7 (it will still be > supported for Tomcat 7) > 3. Remove Tomcat's proprietary API in Tomcat 8 onwards. > > 3 has already been done. 1 & 2 will follow once Tomcat 8's JSR356 > implementation has stabilised. For a historical record, backport of JSR 356 implementation to Tomcat 7 and deprecation of Tomcat's proprietary API was done in Tomcat 7.0.43, released in 7.0.47. (Versions 7.0.43-.46 did not pass release vote). To make use of JSR 356 in Tomcat 7, one has to run it with Java 7 or later. -- 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
[Tomcat Wiki] Update of "Specifications" by KonstantinKolinko
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "Specifications" page has been changed by KonstantinKolinko: https://wiki.apache.org/tomcat/Specifications?action=diff&rev1=33&rev2=34 Comment: Add links to WebSocket 1.1, add Tomcat versions to the table Java API for !WebSocket is JSR 356. An implementation is to be included in Tomcat 8. See also [[https://issues.apache.org/bugzilla/show_bug.cgi?id=51181#c64|Bug 51181]]. - ||Spec versions: ||Java API for !WebSocket 1.0 || + ||Spec versions: ||Java API for !WebSocket 1.0 ||Java API for !WebSocket 1.1 || - ||Main page: || [[http://www.jcp.org/en/jsr/summary?id=356|JSR356]] || + ||Main page: ||[[http://www.jcp.org/en/jsr/summary?id=356|JSR356]] ||[[http://www.jcp.org/en/jsr/summary?id=356|JSR356]] || - ||Java.net project: || [[http://java.net/projects/websocket-spec/|websocket-spec ]]|| + ||Java.net project: ||<-2> [[http://java.net/projects/websocket-spec/|websocket-spec ]]|| - ||Stable: || Final Release || - ||Date: || 22 May, 2013 || - ||Download Page: || [[http://jcp.org/aboutJava/communityprocess/final/jsr356/index.html|Overview]]<>[[http://download.oracle.com/otndocs/jcp/websocket-1_0-fr-eval-spec/index.html|Direct Download]] || + ||Stable: || Final Release || Maintenance Release || + ||Date: || 22 May, 2013 || 5 August, 2014 || + ||Download Page: || [[http://jcp.org/aboutJava/communityprocess/final/jsr356/index.html|Overview]]<>[[http://download.oracle.com/otndocs/jcp/websocket-1_0-fr-eval-spec/index.html|Direct Download]] || [[https://jcp.org/aboutJava/communityprocess/mrel/jsr356/index.html|Overview]]<>[[http://download.oracle.com/otndocs/jcp/websocket-1_1-mrel-eval-spec/index.html|Direct Download]] || - ||Online Javadoc: || [[http://docs.oracle.com/javaee/7/api/|Java EE 7]] || + ||Online Javadoc: || [[http://docs.oracle.com/javaee/7/api/|Java EE 7]] || || + ||Minimum Tomcat version: || 7.0.47, 8.0.0<>running with Java 7 or later|| 8.0.13 || == See Also == - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57005] New: maven build for jdbc-pool broken with Java 8 because of javadoc problems
https://issues.apache.org/bugzilla/show_bug.cgi?id=57005 Bug ID: 57005 Summary: maven build for jdbc-pool broken with Java 8 because of javadoc problems Product: Tomcat Modules Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: jdbc-pool Assignee: dev@tomcat.apache.org Reporter: pierre.vi...@gmail.com The maven build for jdbc-pool crashes while creating the javadoc with following error: /Users/viretp/Dev/apache/tomcat/sandbox/trunk-maven-layout/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/DataSource.java:66: error: self-closing element not allowed * Unregisters the underlying connection pool mbean. ^ The problem is, that java 8 has become more strict with javadoc and per default javadoc will exits with an error if the syntax is not absolutely http conformed. How to repeat: (be sure to have java 8 version active) cd modules/jdbc-pool mvm clean install -DskipTests There are at minimum 2 solutions for this: 1) fix the javadoc --> this is my preferred option because the quality of the documentation will be better. In some cases the syntax errors would avoid some informations to be properly displayed in the final javadoc. 2) setup the javadoc plugin in maven to use a special flag to disable the syntax verification. --> no need to update the sources but the real problems are not solved with this solution. More information for this problem can be found here: http://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html If nobody fixes this before and if I come to this I will fix the javadoc and upload the patch here. -- 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 57005] maven build for jdbc-pool broken with Java 8 because of javadoc problems
https://issues.apache.org/bugzilla/show_bug.cgi?id=57005 --- Comment #1 from Konstantin Kolinko --- See here on how to disable DocLint checks in maven builds: https://jdpgrailsdev.github.io/blog/2014/04/03/maven_java8_javadoc.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 57004] Get number of stuck threads from StuckThreadDetectionValve through jmx
https://issues.apache.org/bugzilla/show_bug.cgi?id=57004 --- Comment #1 from Jiří Pejchal --- Created attachment 32045 --> https://issues.apache.org/bugzilla/attachment.cgi?id=32045&action=edit Patch for getting stuckThreadCount through jmx This would be nice to have in tomcat7 too. -- 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: r1626989 - in /tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2: ./ cpdsadapter/ datasources/
Author: markt
Date: Tue Sep 23 12:51:46 2014
New Revision: 1626989
URL: http://svn.apache.org/r1626989
Log:
Update to latest DBCP 2 code (r1626987)
- Javadoc fixes
- Custom eviction policy fix
Modified:
tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/ (props changed)
tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/BasicDataSource.java
tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/DelegatingConnection.java
tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/DelegatingDatabaseMetaData.java
tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/DelegatingResultSet.java
tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/DelegatingStatement.java
tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/PoolableConnectionFactory.java
tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/PoolingConnection.java
tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/cpdsadapter/PooledConnectionImpl.java
tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/datasources/CPDSConnectionFactory.java
tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/datasources/KeyedCPDSConnectionFactory.java
tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/package-info.java
Propchange: tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/
--
Merged
/commons/proper/dbcp/trunk/src/main/java/org/apache/commons/dbcp2:r1609330-1626988
Modified: tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/BasicDataSource.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/BasicDataSource.java?rev=1626989&r1=1626988&r2=1626989&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/BasicDataSource.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/BasicDataSource.java Tue Sep
23 12:51:46 2014
@@ -1308,7 +1308,7 @@ public class BasicDataSource implements
* Returns the value of the flag that controls whether or not connections
* being returned to the pool will checked and configured with
* {@link Connection#setAutoCommit(boolean) Connection.setAutoCommit(true)}
- * if the auto commit setting is false when the connection
+ * if the auto commit setting is {@code false} when the connection
* is returned. It is true by default.
*/
public boolean getEnableAutoCommitOnReturn() {
@@ -1319,7 +1319,7 @@ public class BasicDataSource implements
* Sets the value of the flag that controls whether or not connections
* being returned to the pool will checked and configured with
* {@link Connection#setAutoCommit(boolean) Connection.setAutoCommit(true)}
- * if the auto commit setting is false when the connection
+ * if the auto commit setting is {@code false} when the connection
* is returned. It is true by default.
*/
public void setEnableAutoCommitOnReturn(boolean enableAutoCommitOnReturn) {
@@ -2078,6 +2078,7 @@ public class BasicDataSource implements
gop.setTestWhileIdle(testWhileIdle);
gop.setLifo(lifo);
gop.setSwallowedExceptionListener(new SwallowedExceptionLogger(log));
+gop.setEvictionPolicyClassName(evictionPolicyClassName);
factory.setPool(gop);
connectionPool = gop;
}
Modified:
tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/DelegatingConnection.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/DelegatingConnection.java?rev=1626989&r1=1626988&r2=1626989&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/DelegatingConnection.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/DelegatingConnection.java
Tue Sep 23 12:51:46 2014
@@ -162,17 +162,17 @@ public class DelegatingConnectionDelegatingConnection, returns it,
+ * {@code DelegatingConnection}, returns it,
* otherwise recursively invokes this method on
* my delegate.
*
* Hence this method will return the first
- * delegate that is not a DelegatingConnection,
- * or null when no non-DelegatingConnection
+ * delegate that is not a {@code DelegatingConnection},
+ * or {@code null} when no non-{@code DelegatingConnection}
* delegate can be found by traversing this chain.
*
* This method is useful when you may have nested
- * DelegatingConnections, and you want to make
+ * {@code DelegatingConnection}s, and you want to make
* sure to obtain a "genuine" {@link Connection}.
*/
public Connection getInnermostDelegate() {
Modified:
tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/DelegatingDatabaseMetaData.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/DelegatingDatabaseMetaData.java?rev=1626989&r1=1626988&r2=1626989&view=diff
svn commit: r1626991 - in /tomcat/trunk: java/org/apache/catalina/valves/StuckThreadDetectionValve.java java/org/apache/catalina/valves/mbeans-descriptors.xml webapps/docs/changelog.xml
Author: schultz
Date: Tue Sep 23 12:52:08 2014
New Revision: 1626991
URL: http://svn.apache.org/r1626991
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=57004
Add stuckThreadCount property to StuckThreadDetectionValve.
Modified:
tomcat/trunk/java/org/apache/catalina/valves/StuckThreadDetectionValve.java
tomcat/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml
tomcat/trunk/webapps/docs/changelog.xml
Modified:
tomcat/trunk/java/org/apache/catalina/valves/StuckThreadDetectionValve.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/valves/StuckThreadDetectionValve.java?rev=1626991&r1=1626990&r2=1626991&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/valves/StuckThreadDetectionValve.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/valves/StuckThreadDetectionValve.java
Tue Sep 23 12:52:08 2014
@@ -247,6 +247,10 @@ public class StuckThreadDetectionValve e
}
}
+public int getStuckThreadCount() {
+return stuckCount.get();
+}
+
public long[] getStuckThreadIds() {
List idList = new ArrayList<>();
for (MonitoredThread monitoredThread : activeThreads.values()) {
Modified: tomcat/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml?rev=1626991&r1=1626990&r2=1626991&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml
(original)
+++ tomcat/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml Tue Sep
23 12:52:08 2014
@@ -517,6 +517,11 @@
type="java.lang.String"
writeable="false"/>
+
+
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1626991&r1=1626990&r2=1626991&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Tue Sep 23 12:52:08 2014
@@ -148,6 +148,11 @@
paths and are deployed as directories are correctly removed on undeploy
when running on a case sensitive file system. (markt)
+
+ 57004: Add stuckThreadCount property to
+ StuckThreadDetectionValve's JMX bean. Patch provided by
+ Jiří Pejchal. (schultz)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1626994 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/valves/StuckThreadDetectionValve.java java/org/apache/catalina/valves/mbeans-descriptors.xml webapps/docs/changelog.xml
Author: schultz
Date: Tue Sep 23 12:59:44 2014
New Revision: 1626994
URL: http://svn.apache.org/r1626994
Log:
Back-port r1626991 to fix
https://issues.apache.org/bugzilla/show_bug.cgi?id=57004
Add stuckThreadCount to StuckThreadDetectionValve's JMXBean.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/valves/StuckThreadDetectionValve.java
tomcat/tc7.0.x/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1626991
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/valves/StuckThreadDetectionValve.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/valves/StuckThreadDetectionValve.java?rev=1626994&r1=1626993&r2=1626994&view=diff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/catalina/valves/StuckThreadDetectionValve.java
(original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/catalina/valves/StuckThreadDetectionValve.java
Tue Sep 23 12:59:44 2014
@@ -260,6 +260,10 @@ public class StuckThreadDetectionValve e
}
}
+public int getStuckThreadCount() {
+return stuckCount.get();
+}
+
public long[] getStuckThreadIds() {
List idList = new ArrayList();
for (MonitoredThread monitoredThread : activeThreads.values()) {
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml?rev=1626994&r1=1626993&r2=1626994&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml
Tue Sep 23 12:59:44 2014
@@ -567,6 +567,11 @@
type="java.lang.String"
writeable="false"/>
+
+
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1626994&r1=1626993&r2=1626994&view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Tue Sep 23 12:59:44 2014
@@ -168,6 +168,11 @@
paths and are deployed as directories are correctly removed on undeploy
when running on a case sensitive file system. (markt)
+
+ 57004: Add stuckThreadCount property to
+ StuckThreadDetectionValve's JMX bean. Patch provided by
+ Jiří Pejchal. (schultz)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57004] Get number of stuck threads from StuckThreadDetectionValve through jmx
https://issues.apache.org/bugzilla/show_bug.cgi?id=57004 Christopher Schultz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Christopher Schultz --- Fixed in trunk in r1626991. Will be in Tomcat 8.0.13 and later. Fixed in Tomcat 7. Will be in Tomcat 7.0.56 and later. -- 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: r1627000 - /tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
Author: schultz
Date: Tue Sep 23 13:09:42 2014
New Revision: 1627000
URL: http://svn.apache.org/r1627000
Log:
Micro optimization.
Modified:
tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java?rev=1627000&r1=1626999&r2=1627000&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java Tue Sep 23
13:09:42 2014
@@ -75,10 +75,12 @@ public final class HexUtils {
if (null == bytes) {
return null;
}
+final char[] hex = HexUtils.hex;
+final int length = bytes.length;
-StringBuilder sb = new StringBuilder(bytes.length << 1);
+StringBuilder sb = new StringBuilder(length << 1);
-for(int i = 0; i < bytes.length; ++i) {
+for(int i = 0; i < length; ++i) {
sb.append(hex[(bytes[i] & 0xf0) >> 4])
.append(hex[(bytes[i] & 0x0f)])
;
@@ -94,8 +96,9 @@ public final class HexUtils {
}
char[] inputChars = input.toCharArray();
-byte[] result = new byte[input.length() >> 1];
-for (int i = 0; i < result.length; i++) {
+final int length = input.length() >> 1;
+byte[] result = new byte[length];
+for (int i = 0; i < length; i++) {
result[i] = (byte) ((getDec(inputChars[2*i]) << 4) +
getDec(inputChars[2*i + 1]));
}
return result;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1627000 - /tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
On 23/09/2014 14:09, schu...@apache.org wrote:
> Author: schultz
> Date: Tue Sep 23 13:09:42 2014
> New Revision: 1627000
>
> URL: http://svn.apache.org/r1627000
> Log:
> Micro optimization.
What is the performance benefit of this change?
Mark
>
> Modified:
> tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
>
> Modified: tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java?rev=1627000&r1=1626999&r2=1627000&view=diff
> ==
> --- tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java (original)
> +++ tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java Tue Sep 23
> 13:09:42 2014
> @@ -75,10 +75,12 @@ public final class HexUtils {
> if (null == bytes) {
> return null;
> }
> +final char[] hex = HexUtils.hex;
> +final int length = bytes.length;
>
> -StringBuilder sb = new StringBuilder(bytes.length << 1);
> +StringBuilder sb = new StringBuilder(length << 1);
>
> -for(int i = 0; i < bytes.length; ++i) {
> +for(int i = 0; i < length; ++i) {
> sb.append(hex[(bytes[i] & 0xf0) >> 4])
> .append(hex[(bytes[i] & 0x0f)])
> ;
> @@ -94,8 +96,9 @@ public final class HexUtils {
> }
>
> char[] inputChars = input.toCharArray();
> -byte[] result = new byte[input.length() >> 1];
> -for (int i = 0; i < result.length; i++) {
> +final int length = input.length() >> 1;
> +byte[] result = new byte[length];
> +for (int i = 0; i < length; i++) {
> result[i] = (byte) ((getDec(inputChars[2*i]) << 4) +
> getDec(inputChars[2*i + 1]));
> }
> return result;
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1627007 - in /tomcat/trunk/java/org/apache/tomcat/dbcp/pool2: BaseKeyedPooledObjectFactory.java impl/AbandonedConfig.java impl/LinkedBlockingDeque.java impl/SoftReferenceObjectPool.java
Author: markt
Date: Tue Sep 23 13:18:22 2014
New Revision: 1627007
URL: http://svn.apache.org/r1627007
Log:
Port some code clean-up from Pool2 trunk.
Modified:
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/BaseKeyedPooledObjectFactory.java
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/AbandonedConfig.java
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/LinkedBlockingDeque.java
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/SoftReferenceObjectPool.java
Modified:
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/BaseKeyedPooledObjectFactory.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/BaseKeyedPooledObjectFactory.java?rev=1627007&r1=1627006&r2=1627007&view=diff
==
---
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/BaseKeyedPooledObjectFactory.java
(original)
+++
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/BaseKeyedPooledObjectFactory.java
Tue Sep 23 13:18:22 2014
@@ -76,7 +76,7 @@ public abstract class BaseKeyedPooledObj
/**
* Ensures that the instance is safe to be returned by the pool.
*
- * The default implementation always returns true.
+ * The default implementation always returns {@code true}.
*
* @param key the key used when selecting the object
* @param p a {@code PooledObject} wrapping the the instance to be
validated
Modified:
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/AbandonedConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/AbandonedConfig.java?rev=1627007&r1=1627006&r2=1627007&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/AbandonedConfig.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/AbandonedConfig.java
Tue Sep 23 13:18:22 2014
@@ -44,7 +44,7 @@ public class AbandonedConfig {
* @return true if abandoned objects are to be removed by borrowObject
*/
public boolean getRemoveAbandonedOnBorrow() {
-return (this.removeAbandonedOnBorrow);
+return this.removeAbandonedOnBorrow;
}
/**
@@ -81,7 +81,7 @@ public class AbandonedConfig {
* @return true if abandoned objects are to be removed by the evictor
*/
public boolean getRemoveAbandonedOnMaintenance() {
-return (this.removeAbandonedOnMaintenance);
+return this.removeAbandonedOnMaintenance;
}
/**
@@ -114,7 +114,7 @@ public class AbandonedConfig {
* @return the abandoned object timeout in seconds
*/
public int getRemoveAbandonedTimeout() {
-return (this.removeAbandonedTimeout);
+return this.removeAbandonedTimeout;
}
/**
@@ -152,7 +152,7 @@ public class AbandonedConfig {
*
*/
public boolean getLogAbandoned() {
-return (this.logAbandoned);
+return this.logAbandoned;
}
/**
Modified:
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/LinkedBlockingDeque.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/LinkedBlockingDeque.java?rev=1627007&r1=1627006&r2=1627007&view=diff
==
---
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/LinkedBlockingDeque.java
(original)
+++
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/LinkedBlockingDeque.java
Tue Sep 23 13:18:22 2014
@@ -130,17 +130,17 @@ class LinkedBlockingDeque extends Abs
* Invariant: (first == null && last == null) ||
*(first.prev == null && first.item != null)
*/
-private transient Node first;
+private transient Node first; // @GuardedBy("lock")
/**
* Pointer to last node.
* Invariant: (first == null && last == null) ||
*(last.next == null && last.item != null)
*/
-private transient Node last;
+private transient Node last; // @GuardedBy("lock")
/** Number of items in the deque */
-private transient int count;
+private transient int count; // @GuardedBy("lock")
/** Maximum number of items in the deque */
private final int capacity;
@@ -192,7 +192,9 @@ class LinkedBlockingDeque extends Abs
* @throws IllegalArgumentException if {@code capacity} is less than 1
*/
public LinkedBlockingDeque(int capacity, boolean fairness) {
-if (capacity <= 0) throw new IllegalArgumentException();
+if (capacity <= 0) {
+throw new IllegalArgumentException();
+}
this.capacity = capacity;
lock = new InterruptibleReentrantLock(fairness);
notEmpty = lock.newCondition();
@@ -214,10 +216,12 @@ class LinkedBlockingDeque extends Abs
lock.lock(); // Never contended, but necessary for visibility
try {
for (E e : c) {
-
Re: svn commit: r1627000 - /tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
2014-09-23 15:15 GMT+02:00 Mark Thomas : > On 23/09/2014 14:09, schu...@apache.org wrote: > > Author: schultz > > Date: Tue Sep 23 13:09:42 2014 > > New Revision: 1627000 > > > > URL: http://svn.apache.org/r1627000 > > Log: > > Micro optimization. > > What is the performance benefit of this change? I don't see how there can be any measurable gain, so I agree this should be avoided if that's the case. More code for (na)no benefits is bad. Rémy
[Bug 57006] openssl s_client may connected with property allowUnsafeLegacyRenegotiation set false
https://issues.apache.org/bugzilla/show_bug.cgi?id=57006 --- Comment #2 from xinshouke <1599409...@qq.com> --- Created attachment 32047 --> https://issues.apache.org/bugzilla/attachment.cgi?id=32047&action=edit my server.xml config -- 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 57006] New: openssl s_client may connected with property allowUnsafeLegacyRenegotiation set false
https://issues.apache.org/bugzilla/show_bug.cgi?id=57006 Bug ID: 57006 Summary: openssl s_client may connected with property allowUnsafeLegacyRenegotiation set false Product: Tomcat 6 Version: 6.0.41 Hardware: Other OS: Linux Status: NEW Severity: critical Priority: P2 Component: Connectors Assignee: dev@tomcat.apache.org Reporter: 1599409...@qq.com I set as the below in server.xml,but tooling openssl s_client still may connected sucessfully. -- 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 56989] Classes being loaded from wrong web app.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56989 Mark Thomas changed: What|Removed |Added Severity|critical|normal --- Comment #5 from Mark Thomas --- It has been almost a week without any response to Konstantin's request for information so I am dropping the severity to normal since it clearly isn't that important to the OP or else they would have responded already. Like Konstantin, I suspect that additional copies of key classes are present elsewhere in the class loader hierarchy. Without the requested information, this issue is going to get closed as INVALID. -- 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 57006] openssl s_client may connected with property allowUnsafeLegacyRenegotiation set false
https://issues.apache.org/bugzilla/show_bug.cgi?id=57006 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Mark Thomas --- I don't see anything in this bug report (the little of it that there is) that describes a bug. I suggest you try the users list for further assistance. -- 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 57006] openssl s_client may connected with property allowUnsafeLegacyRenegotiation set false
https://issues.apache.org/bugzilla/show_bug.cgi?id=57006 --- Comment #4 from xinshouke <1599409...@qq.com> --- I re-describe my issue, pls check the below comments. (In reply to Mark Thomas from comment #1) > I don't see anything in this bug report (the little of it that there is) > that describes a bug. > > I suggest you try the users list for further assistance. -- 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: r1627033 - /tomcat/trunk/build.properties.default
Author: markt
Date: Tue Sep 23 14:17:55 2014
New Revision: 1627033
URL: http://svn.apache.org/r1627033
Log:
Partial fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=56079
(Still need to sign the Windows Installer)
Switch to the signed versions of the daemon binaries.
Modified:
tomcat/trunk/build.properties.default
Modified: tomcat/trunk/build.properties.default
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.properties.default?rev=1627033&r1=1627032&r2=1627033&view=diff
==
--- tomcat/trunk/build.properties.default (original)
+++ tomcat/trunk/build.properties.default Tue Sep 23 14:17:55 2014
@@ -175,13 +175,13 @@ commons-daemon.jar=${commons-daemon.home
commons-daemon.native.win.home=${commons-daemon.home}/windows
commons-daemon.native.win.mgr.exe=${commons-daemon.native.win.home}/prunmgr.exe
commons-daemon.native.src.tgz=${commons-daemon.home}/commons-daemon-${commons-daemon.version}-native-src.tar.gz
-commons-daemon.native.win.zip=${commons-daemon.home}/commons-daemon-${commons-daemon.version}-bin-windows.zip
+commons-daemon.native.win.zip=${commons-daemon.home}/commons-daemon-${commons-daemon.version}-bin-windows-signed.zip
commons-daemon.bin.loc.1=${base-commons.loc.1}/daemon/binaries/commons-daemon-${commons-daemon.version}-bin.tar.gz
commons-daemon.bin.loc.2=${base-commons.loc.2}/daemon/binaries/commons-daemon-${commons-daemon.version}-bin.tar.gz
commons-daemon.native.src.loc.1=${base-commons.loc.1}/daemon/source/commons-daemon-${commons-daemon.version}-native-src.tar.gz
commons-daemon.native.src.loc.2=${base-commons.loc.2}/daemon/source/commons-daemon-${commons-daemon.version}-native-src.tar.gz
-commons-daemon.native.win.loc.1=${base-commons.loc.1}/daemon/binaries/windows/commons-daemon-${commons-daemon.version}-bin-windows.zip
-commons-daemon.native.win.loc.2=${base-commons.loc.2}/daemon/binaries/windows/commons-daemon-${commons-daemon.version}-bin-windows.zip
+commons-daemon.native.win.loc.1=${base-commons.loc.1}/daemon/binaries/windows/commons-daemon-${commons-daemon.version}-bin-windows-signed.zip
+commons-daemon.native.win.loc.2=${base-commons.loc.2}/daemon/binaries/windows/commons-daemon-${commons-daemon.version}-bin-windows-signed.zip
# - JUnit Unit Test Suite, version 4.11 or later -
junit.version=4.11
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1627000 - /tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
2014-09-23 17:09 GMT+04:00 :
> Author: schultz
> Date: Tue Sep 23 13:09:42 2014
> New Revision: 1627000
>
> URL: http://svn.apache.org/r1627000
> Log:
> Micro optimization.
>
> Modified:
> tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
>
> Modified: tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java?rev=1627000&r1=1626999&r2=1627000&view=diff
> ==
> --- tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java (original)
> +++ tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java Tue Sep 23
> 13:09:42 2014
> @@ -75,10 +75,12 @@ public final class HexUtils {
> if (null == bytes) {
> return null;
> }
> +final char[] hex = HexUtils.hex;
> +final int length = bytes.length;
The above change does not make sense to me.
As HexUtils.hex and bytes.length are themselves final fields, it is up
to Java JVM to inline them. I see no need to define explicit local
fields for them.
> -StringBuilder sb = new StringBuilder(bytes.length << 1);
> +StringBuilder sb = new StringBuilder(length << 1);
>
> -for(int i = 0; i < bytes.length; ++i) {
> +for(int i = 0; i < length; ++i) {
> sb.append(hex[(bytes[i] & 0xf0) >> 4])
> .append(hex[(bytes[i] & 0x0f)])
> ;
> @@ -94,8 +96,9 @@ public final class HexUtils {
> }
>
> char[] inputChars = input.toCharArray();
> -byte[] result = new byte[input.length() >> 1];
> -for (int i = 0; i < result.length; i++) {
> +final int length = input.length() >> 1;
> +byte[] result = new byte[length];
> +for (int i = 0; i < length; i++) {
This fromHexString() method (where the above lines are) is used by
test code only.
The usefulness of this fromHexString() method is somewhat limited, as
it does not check correctness of its arguments. If input string has
even number of chars, the last char will be silently ignored. If some
characters are non-hex, it will silently produce bogus results.
> result[i] = (byte) ((getDec(inputChars[2*i]) << 4) +
> getDec(inputChars[2*i + 1]));
> }
> return result;
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57006] openssl s_client may connected with property allowUnsafeLegacyRenegotiation set false
https://issues.apache.org/bugzilla/show_bug.cgi?id=57006 xinshouke <1599409...@qq.com> changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #3 from xinshouke <1599409...@qq.com> --- Somebody checked my tomcat server, he reported a high sercurity risk with set SSLEnabled as true but no disabled renegotiations. It's a way to verify the issue thr command 'openssl s_client -connect ip:port'. So I set allowUnsafeLegacyRenegotiation="false" in the server.xml,the expected result that it get error after run the command 'openssl s_client -connect ip:port'. But, after executed the command,it still connected the SSL.sucessfully. -- 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: svn commit: r1627000 - /tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
Mark,
On 9/23/14 9:15 AM, Mark Thomas wrote:
> On 23/09/2014 14:09, schu...@apache.org wrote:
>> Author: schultz
>> Date: Tue Sep 23 13:09:42 2014
>> New Revision: 1627000
>>
>> URL: http://svn.apache.org/r1627000
>> Log:
>> Micro optimization.
>
> What is the performance benefit of this change?
See below.
>> Modified:
>> tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
>>
>> Modified: tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
>> URL:
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java?rev=1627000&r1=1626999&r2=1627000&view=diff
>> ==
>> --- tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java (original)
>> +++ tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java Tue Sep 23
>> 13:09:42 2014
>> @@ -75,10 +75,12 @@ public final class HexUtils {
>> if (null == bytes) {
>> return null;
>> }
>> +final char[] hex = HexUtils.hex;
>> +final int length = bytes.length;
>>
>> -StringBuilder sb = new StringBuilder(bytes.length << 1);
>> +StringBuilder sb = new StringBuilder(length << 1);
>>
>> -for(int i = 0; i < bytes.length; ++i) {
>> +for(int i = 0; i < length; ++i) {
bytes.length requires "aload" and "arraylength" opcodes while using a
local variable uses a single "aload" operation. Since I'm going to use
"length" instead of bytes.length, I may as well use it to construct the
StringBuilder object.
Compared to sb.append() this optimization is likely to be lost in the
noise, but it is still a slight improvement.
>> sb.append(hex[(bytes[i] & 0xf0) >> 4])
>> .append(hex[(bytes[i] & 0x0f)])
>> ;
>> @@ -94,8 +96,9 @@ public final class HexUtils {
>> }
>>
>> char[] inputChars = input.toCharArray();
>> -byte[] result = new byte[input.length() >> 1];
>> -for (int i = 0; i < result.length; i++) {
>> +final int length = input.length() >> 1;
>> +byte[] result = new byte[length];
>> +for (int i = 0; i < length; i++) {
Same here: fewer opcodes per loop.
>> result[i] = (byte) ((getDec(inputChars[2*i]) << 4) +
>> getDec(inputChars[2*i + 1]));
>> }
>> return result;
-chris
signature.asc
Description: OpenPGP digital signature
svn commit: r1627008 - /tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/EvictionTimer.java
Author: markt
Date: Tue Sep 23 13:21:10 2014
New Revision: 1627008
URL: http://svn.apache.org/r1627008
Log:
Port code clean up and a memory leak fix from Pool2 trunk
Modified:
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/EvictionTimer.java
Modified: tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/EvictionTimer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/EvictionTimer.java?rev=1627008&r1=1627007&r2=1627008&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/EvictionTimer.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/EvictionTimer.java Tue
Sep 23 13:21:10 2014
@@ -39,10 +39,10 @@ import java.util.TimerTask;
class EvictionTimer {
/** Timer instance */
-private static Timer _timer; //@GuardedBy("this")
+private static Timer _timer; //@GuardedBy("EvictionTimer.class")
/** Static usage count tracker */
-private static int _usageCount; //@GuardedBy("this")
+private static int _usageCount; //@GuardedBy("EvictionTimer.class")
/** Prevent instantiation */
private EvictionTimer() {
@@ -67,7 +67,7 @@ class EvictionTimer {
try {
AccessController.doPrivileged(new PrivilegedSetTccl(
EvictionTimer.class.getClassLoader()));
-_timer = new Timer("commons-pool-EvictionTimer", true);
+_timer = AccessController.doPrivileged(new
PrivilegedNewEvictionTimer());
} finally {
AccessController.doPrivileged(new PrivilegedSetTccl(ccl));
}
@@ -129,4 +129,22 @@ class EvictionTimer {
}
}
+/**
+ * {@link PrivilegedAction} used to create a new Timer. Creating the timer
+ * with a privileged action means the associated Thread does not inherit
the
+ * current access control context. In a container environment, inheriting
+ * the current access control context is likely to result in retaining a
+ * reference to the thread context class loader which would be a memory
+ * leak.
+ */
+private static class PrivilegedNewEvictionTimer implements
PrivilegedAction {
+
+/**
+ * {@inheritDoc}
+ */
+@Override
+public Timer run() {
+return new Timer("commons-pool-EvictionTimer", true);
+}
+}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1627030 - /tomcat/trunk/webapps/docs/changelog.xml
Author: markt Date: Tue Sep 23 13:48:01 2014 New Revision: 1627030 URL: http://svn.apache.org/r1627030 Log: Update changelog 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=1627030&r1=1627029&r2=1627030&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Tue Sep 23 13:48:01 2014 @@ -248,6 +248,17 @@ Ensure that the ide-eclipse build target downloads all the libraries required by the default Eclipse configuration files. + +Update the package renamed copy of Apache Commons DBCP 2 to revision +1626988 to pick up the fixes since the 2.0.1 release including support +for custom eviction policies. (markt) + + +Update the package renamed copy of Apache Commons Pool 2 to revision +1627022 to pick up the fixes since the 2.2 release including some memory +leak fixes and support for application provided eviction policies. +(markt) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1627027 - in /tomcat/trunk/java/org/apache/tomcat/dbcp/pool2: ./ impl/BaseGenericObjectPool.java impl/GenericKeyedObjectPool.java impl/GenericObjectPool.java
Author: markt
Date: Tue Sep 23 13:43:21 2014
New Revision: 1627027
URL: http://svn.apache.org/r1627027
Log:
Update Pool2 to latest trunk to pick up fixes/updates for:
- memory leak via the Evictor
- potential although unlikely threading issue
- application provided eviction policies
- POOL-270, POOL-276
Modified:
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/ (props changed)
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/BaseGenericObjectPool.java
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/GenericKeyedObjectPool.java
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/GenericObjectPool.java
Propchange: tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/
--
Merged
/commons/proper/pool/trunk/src/main/java/org/apache/commons/pool2:r1609324-1627022
Modified:
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/BaseGenericObjectPool.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/BaseGenericObjectPool.java?rev=1627027&r1=1627026&r2=1627027&view=diff
==
---
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/BaseGenericObjectPool.java
(original)
+++
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/BaseGenericObjectPool.java
Tue Sep 23 13:43:21 2014
@@ -20,6 +20,7 @@ import java.io.PrintWriter;
import java.io.StringWriter;
import java.io.Writer;
import java.lang.management.ManagementFactory;
+import java.lang.ref.WeakReference;
import java.util.Iterator;
import java.util.TimerTask;
import java.util.concurrent.atomic.AtomicLong;
@@ -92,9 +93,10 @@ public abstract class BaseGenericObjectP
/*
* Class loader for evictor thread to use since in a J2EE or similar
* environment the context class loader for the evictor thread may have
- * visibility of the correct factory. See POOL-161.
+ * visibility of the correct factory. See POOL-161. Uses a weak reference
to
+ * avoid potential memory leaks if the Pool is discarded rather than
closed.
*/
-private final ClassLoader factoryClassLoader;
+private final WeakReference factoryClassLoader;
// Monitoring (primarily JMX) attributes
@@ -111,7 +113,7 @@ public abstract class BaseGenericObjectP
private final StatsStore waitTimes = new
StatsStore(MEAN_TIMING_STATS_CACHE_SIZE);
private final Object maxBorrowWaitTimeMillisLock = new Object();
private volatile long maxBorrowWaitTimeMillis = 0; //
@GuardedBy("maxBorrowWaitTimeMillisLock")
-private SwallowedExceptionListener swallowedExceptionListener = null;
+private volatile SwallowedExceptionListener swallowedExceptionListener =
null;
/**
@@ -135,7 +137,8 @@ public abstract class BaseGenericObjectP
this.creationStackTrace = getStackTrace(new Exception());
// save the current CCL to be used later by the evictor Thread
-factoryClassLoader = Thread.currentThread().getContextClassLoader();
+factoryClassLoader =
+new
WeakReference<>(Thread.currentThread().getContextClassLoader());
fairness = config.getFairness();
}
@@ -586,7 +589,8 @@ public abstract class BaseGenericObjectP
public final void setEvictionPolicyClassName(
String evictionPolicyClassName) {
try {
-Class clazz = Class.forName(evictionPolicyClassName);
+Class clazz = Class.forName(evictionPolicyClassName, true,
+Thread.currentThread().getContextClassLoader());
Object policy = clazz.newInstance();
if (policy instanceof EvictionPolicy) {
@SuppressWarnings("unchecked") // safe, because we just
checked the class
@@ -995,8 +999,14 @@ public abstract class BaseGenericObjectP
Thread.currentThread().getContextClassLoader();
try {
// Set the class loader for the factory
-Thread.currentThread().setContextClassLoader(
-factoryClassLoader);
+ClassLoader cl = factoryClassLoader.get();
+if (cl == null) {
+// The pool has been dereferenced and the class loader
GC'd.
+// Cancel this timer so the pool can be GC'd as well.
+cancel();
+return;
+}
+Thread.currentThread().setContextClassLoader(cl);
// Evict from the pool
try {
Modified:
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/GenericKeyedObjectPool.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/GenericKeyedObjectPool.java?rev=1627027&r1=1627026&r2=1627027&view=diff
==
---
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/GenericKeyedO
Re: svn commit: r1627000 - /tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
On 23/09/2014 15:13, Christopher Schultz wrote:
> Mark,
>
> On 9/23/14 9:15 AM, Mark Thomas wrote:
>> On 23/09/2014 14:09, schu...@apache.org wrote:
>>> Author: schultz
>>> Date: Tue Sep 23 13:09:42 2014
>>> New Revision: 1627000
>>>
>>> URL: http://svn.apache.org/r1627000
>>> Log:
>>> Micro optimization.
>>
>> What is the performance benefit of this change?
>
> See below.
>
>>> Modified:
>>> tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
>>>
>>> Modified: tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
>>> URL:
>>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java?rev=1627000&r1=1626999&r2=1627000&view=diff
>>> ==
>>> --- tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java (original)
>>> +++ tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java Tue Sep 23
>>> 13:09:42 2014
>>> @@ -75,10 +75,12 @@ public final class HexUtils {
>>> if (null == bytes) {
>>> return null;
>>> }
>>> +final char[] hex = HexUtils.hex;
>>> +final int length = bytes.length;
>>>
>>> -StringBuilder sb = new StringBuilder(bytes.length << 1);
>>> +StringBuilder sb = new StringBuilder(length << 1);
>>>
>>> -for(int i = 0; i < bytes.length; ++i) {
>>> +for(int i = 0; i < length; ++i) {
>
> bytes.length requires "aload" and "arraylength" opcodes while using a
> local variable uses a single "aload" operation. Since I'm going to use
> "length" instead of bytes.length, I may as well use it to construct the
> StringBuilder object.
>
> Compared to sb.append() this optimization is likely to be lost in the
> noise, but it is still a slight improvement.
-1.
This changes makes the code harder to read and no evidence has been
presented that it will make any noticeable improvement. The chances are
that the compiler will in-line this any way.
Mark
>
>>> sb.append(hex[(bytes[i] & 0xf0) >> 4])
>>> .append(hex[(bytes[i] & 0x0f)])
>>> ;
>>> @@ -94,8 +96,9 @@ public final class HexUtils {
>>> }
>>>
>>> char[] inputChars = input.toCharArray();
>>> -byte[] result = new byte[input.length() >> 1];
>>> -for (int i = 0; i < result.length; i++) {
>>> +final int length = input.length() >> 1;
>>> +byte[] result = new byte[length];
>>> +for (int i = 0; i < length; i++) {
>
> Same here: fewer opcodes per loop.
>
>>> result[i] = (byte) ((getDec(inputChars[2*i]) << 4) +
>>> getDec(inputChars[2*i + 1]));
>>> }
>>> return result;
>
> -chris
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57006] openssl s_client may connected with property allowUnsafeLegacyRenegotiation set false
https://issues.apache.org/bugzilla/show_bug.cgi?id=57006 Mark Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #5 from Mark Thomas --- I still don't see anything in this report that describes unexpected, undesirable or insecure behavior. Again, please user the 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
Re: svn commit: r1627000 - /tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
Konstantin,
On 9/23/14 10:10 AM, Konstantin Kolinko wrote:
> 2014-09-23 17:09 GMT+04:00 :
>> Author: schultz
>> Date: Tue Sep 23 13:09:42 2014
>> New Revision: 1627000
>>
>> URL: http://svn.apache.org/r1627000
>> Log:
>> Micro optimization.
>>
>> Modified:
>> tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
>>
>> Modified: tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
>> URL:
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java?rev=1627000&r1=1626999&r2=1627000&view=diff
>> ==
>> --- tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java (original)
>> +++ tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java Tue Sep 23
>> 13:09:42 2014
>> @@ -75,10 +75,12 @@ public final class HexUtils {
>> if (null == bytes) {
>> return null;
>> }
>> +final char[] hex = HexUtils.hex;
>> +final int length = bytes.length;
>
> The above change does not make sense to me.
>
> As HexUtils.hex and bytes.length are themselves final fields, it is up
> to Java JVM to inline them. I see no need to define explicit local
> fields for them.
Seems there are major objections to small performance improvements. I'll
revert the change.
>> -StringBuilder sb = new StringBuilder(bytes.length << 1);
>> +StringBuilder sb = new StringBuilder(length << 1);
>>
>> -for(int i = 0; i < bytes.length; ++i) {
>> +for(int i = 0; i < length; ++i) {
>> sb.append(hex[(bytes[i] & 0xf0) >> 4])
>> .append(hex[(bytes[i] & 0x0f)])
>> ;
>> @@ -94,8 +96,9 @@ public final class HexUtils {
>> }
>>
>> char[] inputChars = input.toCharArray();
>> -byte[] result = new byte[input.length() >> 1];
>> -for (int i = 0; i < result.length; i++) {
>> +final int length = input.length() >> 1;
>> +byte[] result = new byte[length];
>> +for (int i = 0; i < length; i++) {
>
> This fromHexString() method (where the above lines are) is used by
> test code only.
>
> The usefulness of this fromHexString() method is somewhat limited, as
> it does not check correctness of its arguments. If input string has
> even number of chars, the last char will be silently ignored. If some
> characters are non-hex, it will silently produce bogus results.
This method will become more useful when bug
https://issues.apache.org/bugzilla/show_bug.cgi?id=56403 is implemented.
Thanks for the review of the code; we'll make appropriate modifications.
-chris
signature.asc
Description: OpenPGP digital signature
Re: Discussion of pluggable password-derivation in Realms [Bug 56403]
Gabriel,
On 9/22/14 7:56 PM, "Gabriel E. Sánchez Martínez" wrote:
>
> On 09/17/2014 04:36 AM, Mark Thomas wrote:
>> On 16/09/2014 22:14, Christopher Schultz wrote:
>>> Mark,
>>>
>>> On 9/16/14 3:39 PM, Mark Thomas wrote:
Updated patch:
http://people.apache.org/~markt/patches/2014-09-16-bug56403-tc8-v2.patch
> It's looking good!
>>> Looks good, but its missing a configuration for the digester to actually
>>> read the configuration and set-up the CredentialHandler objects at
>>> runtime. Existing MessageDigest-based configs will work, but explicit
>>> class references won't.
>> Ack. The docs need updating as well.
>>
>>> Speaking of which, I'd like to be able to nest CredentialHandler
>>> instances. The use case is when switching from one type of
>>> password-derivation method to another. We have done this at $work twice
>>> and being able to handle more than one kind of valid credential in the
>>> database is essential.
>> OK. That seems like a reasonable requirement.
>>
>>> Given that we are giving better options to users than standard
>>> single-pass MessageDigest password-mutators, we should help them
>>> migrate. The only way to do that would be something like
>>> CombinedCredentialHandler analogous to the CombinedRealm: you will
>>> accept either MessageDigestCredentiaHandler{SHA1} /or/, say, PBKDF,
>>> bcrypt, etc., by checking one CredentialHandler and then the second (or
>>> third?) if the first one fails.
>
> This would be good. One could have an array of CredentialHandler to
> check in order.
I think it makes sense to have a single CredentialHandler at the Realm
level. We can nest them if necessary.
> Is the idea that a password stored in an old format would be matched
> using the old CredentialHandler and (upon first match) stored in the
> upgraded format (the first CredentialHandler)? I assume the same idea
> goes for when the same CredentialHandler is used but the number of
> iterations has changed.
An old credential would always be matched by the old algorithm. No
auto-upgrade would occur or anything like that -- that's up to the
application to handle.
>>> Use of a CombinedCredentialHandler might result in a lot of spurious
>>> warnings in the log about invalid credentials. Maybe the
>>> CombinedCredentialHandler could tell the individual child
>>> CredentialHandlers that they should not log invalid credentials?
>> Yes, we'll need to make sure the logs don't fill up with false positives.
> +1
>>
>>> I'd like to get some other opinions on the public mutate() interface. I
>>> think we might not be able to convince each other ;)
>> You might be surprised. I was looking at using mutate() from match to
>> reduce code duplication but if you limit mutate() to just generating new
>> passwords then I agree there is no need for any other parameters. A
>> protected method used by both mutate() and match() should work. I'll
>> take another look.
>
> Without giving an opinion about what method should be called when, I
> agree that salt size and iteration count should be taken from the stored
> credential when matching. If the latest configuration asks for a
> different algorithm, salt size, or iteration count, then the supplied
> cleartext password should be re-hashed to the latest specs.
>
>> Regarding thread safety for the SecureRandom, we can do that now. It
>> doesn't cost us very much and it prevents it tripping us up in the
>> future.
>>
>> Mark
>>
>>
> I saw that String.equals(String s) is being used. I'm not familiar with
> the implementation but I imagine that if the string lengths differ or if
> the first characters don't match, for example, the method returns false
> without checking the rest of the characters. Perhaps that could lead to
> a small vulnerability in which through many attempts and timing an an
> attacker can infer whether the password length, etc. is right. I've
> seen some implementations use a SecureEquals that tries to take
> approximately the same time by comparing all characters of the strings
> even if the lengths or first characters don't match. Is this a real
> concern, or only theory?
While timing attacks are certainly possible, String.equals() is only
used at the very end of the operation and should be completely dominated
by the iterated hashing algorithm which happens regardless of the
correctness of the password.
What might contribute to a timing attack is avoiding the iterated
hashing operation under certain circumstances. For instance, in our own
implementation of DataSourceRealm, if the user does not exist, we waste
a bit of time hashing garbage and discard the result to avoid being able
to determine whether a user exists simply by attempting a login and
timing the response. We might want to have a "wasteTime" method added to
the CredentialHandler interface to allow the Realm to ask the CH to just
do a bunch of useless work to simulate a password match. Lazy
implementations could simply do nothing.
-chris
signature.asc
Description:
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/469 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1626905 Blamelist: kkolinko,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: r1627085 - /tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
Author: schultz
Date: Tue Sep 23 16:36:17 2014
New Revision: 1627085
URL: http://svn.apache.org/r1627085
Log:
Revert r1627000 after review.
Modified:
tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java?rev=1627085&r1=1627084&r2=1627085&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java Tue Sep 23
16:36:17 2014
@@ -75,12 +75,10 @@ public final class HexUtils {
if (null == bytes) {
return null;
}
-final char[] hex = HexUtils.hex;
-final int length = bytes.length;
-StringBuilder sb = new StringBuilder(length << 1);
+StringBuilder sb = new StringBuilder(bytes.length << 1);
-for(int i = 0; i < length; ++i) {
+for(int i = 0; i < bytes.length; ++i) {
sb.append(hex[(bytes[i] & 0xf0) >> 4])
.append(hex[(bytes[i] & 0x0f)])
;
@@ -96,9 +94,8 @@ public final class HexUtils {
}
char[] inputChars = input.toCharArray();
-final int length = input.length() >> 1;
-byte[] result = new byte[length];
-for (int i = 0; i < length; i++) {
+byte[] result = new byte[input.length() >> 1];
+for (int i = 0; i < result.length; i++) {
result[i] = (byte) ((getDec(inputChars[2*i]) << 4) +
getDec(inputChars[2*i + 1]));
}
return result;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1626893 - in /tomcat/trunk/webapps/docs: changelog.xml windows-auth-howto.xml
Hi Mark, one last nitpick. Am 22.09.2014 um 23:03 schrieb ma...@apache.org: Author: markt Date: Mon Sep 22 21:03:37 2014 New Revision: 1626893 URL: http://svn.apache.org/r1626893 Log: Update the Windows authentication documentation after some additional testing to answer the remaining questions. Modified: tomcat/trunk/webapps/docs/changelog.xml tomcat/trunk/webapps/docs/windows-auth-howto.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1626893&r1=1626892&r2=1626893&view=diff Modified: tomcat/trunk/webapps/docs/windows-auth-howto.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/windows-auth-howto.xml?rev=1626893&r1=1626892&r2=1626893&view=diff == --- tomcat/trunk/webapps/docs/windows-auth-howto.xml (original) +++ tomcat/trunk/webapps/docs/windows-auth-howto.xml Mon Sep 22 21:03:37 2014 @@ -53,27 +53,25 @@ sections. Kerberos (the basis for integrated Windows authentication) requires careful configuration. If the steps in this guide are followed exactly, then a working -configuration will result. There may be some flexibility in some of the steps -below but further testing is required to explore this. From the testing to date -it is known that: +configuration will result. It is important that the steps below are followed +exactly. There is very little scope for flexibility in the configuration. From +the testing to date it is known that: -The host name of the Tomcat server must match the host name in the SPN -exactly else authentication will fail. A checksum error may be reported in the -debug logs in this case. +The host name used to access the Tomcat server must match the host name in +the SPN exactly else authentication will fail. A checksum error may be reported +in the debug logs in this case. The client must be of the view that the server is part of the local trusted intranet. -The SPN does not have to start with HTTP but the SPN must be the same in all -the files it is used. +The SPN must be HTTP/and it must be exactly the same in all +the places it is used. +The port number must not be included in the SPN. Chrome has a flag, to disable the port stripping for non standard ports :) If a user has enabled that, the SPN has to match that setting, of course. But I think users with such a setup will probably know what they do and ignore that sentence. Regards Felix No more than one SPN may be mapped to a domain user. - -The areas where further testing is required include: - -Does the domain name have to be in upper case? -Can a port number be appended to the end of the host in the SPN? -Can the domain be left off the user in the ktpass command? -What are the limitations on the account that Tomcat can run as? SPN -associated account works, domain admin works, local admin doesn't -work +Tomcat must run as the domain account with which the SPN has been associated +or as domain admin. It is NOT recommended to run Tomcat under a +domain admin user. +The domain name (DEV.LOCAL) is not case sensitive when used in +the ktpass command, nor when used in jaas.conf +The domain must be specified when using the ktpass command There are four components to the configuration of the built-in Tomcat support for Windows authentication. The domain controller, the server hosting - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Discussion of pluggable password-derivation in Realms [Bug 56403]
Am 17.09.2014 um 10:36 schrieb Mark Thomas:
On 16/09/2014 22:14, Christopher Schultz wrote:
Mark,
On 9/16/14 3:39 PM, Mark Thomas wrote:
Updated patch:
http://people.apache.org/~markt/patches/2014-09-16-bug56403-tc8-v2.patch
Looks good, but its missing a configuration for the digester to actually
read the configuration and set-up the CredentialHandler objects at
runtime. Existing MessageDigest-based configs will work, but explicit
class references won't.
Ack. The docs need updating as well.
Speaking of which, I'd like to be able to nest CredentialHandler
instances. The use case is when switching from one type of
password-derivation method to another. We have done this at $work twice
and being able to handle more than one kind of valid credential in the
database is essential.
OK. That seems like a reasonable requirement.
If the mutate method was removed from CredentialHandler we could
implement a CombinedCredentialHandler, which holds a list of
CredentialHandlers. Those could be asked to handle the credentials in
order to support more than one derivation type.
The mutate method could be placed in an interface like
MutatingCredentialHandler which then could be used as the basis for the
abstract class CredentialHandlerBase.
I wonder if it would be a good idea to introduce a CredentialExtractor
interface, which would extract the salt, algorithm, iteration,
password-hash from a stored credential.
Given that we are giving better options to users than standard
single-pass MessageDigest password-mutators, we should help them
migrate. The only way to do that would be something like
CombinedCredentialHandler analogous to the CombinedRealm: you will
accept either MessageDigestCredentiaHandler{SHA1} /or/, say, PBKDF,
bcrypt, etc., by checking one CredentialHandler and then the second (or
third?) if the first one fails.
Use of a CombinedCredentialHandler might result in a lot of spurious
warnings in the log about invalid credentials. Maybe the
CombinedCredentialHandler could tell the individual child
CredentialHandlers that they should not log invalid credentials?
Yes, we'll need to make sure the logs don't fill up with false positives.
I'd like to get some other opinions on the public mutate() interface. I
think we might not be able to convince each other ;)
You might be surprised. I was looking at using mutate() from match to
reduce code duplication but if you limit mutate() to just generating new
passwords then I agree there is no need for any other parameters. A
protected method used by both mutate() and match() should work. I'll
take another look.
Regarding thread safety for the SecureRandom, we can do that now. It
doesn't cost us very much and it prevents it tripping us up in the future.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Discussion of pluggable password-derivation in Realms [Bug 56403]
Am 23.09.2014 um 01:56 schrieb "Gabriel E. Sánchez Martínez":
On 09/17/2014 04:36 AM, Mark Thomas wrote:
On 16/09/2014 22:14, Christopher Schultz wrote:
Mark,
On 9/16/14 3:39 PM, Mark Thomas wrote:
Updated patch:
http://people.apache.org/~markt/patches/2014-09-16-bug56403-tc8-v2.patch
It's looking good!
Looks good, but its missing a configuration for the digester to
actually
read the configuration and set-up the CredentialHandler objects at
runtime. Existing MessageDigest-based configs will work, but explicit
class references won't.
Ack. The docs need updating as well.
Speaking of which, I'd like to be able to nest CredentialHandler
instances. The use case is when switching from one type of
password-derivation method to another. We have done this at $work twice
and being able to handle more than one kind of valid credential in the
database is essential.
OK. That seems like a reasonable requirement.
Given that we are giving better options to users than standard
single-pass MessageDigest password-mutators, we should help them
migrate. The only way to do that would be something like
CombinedCredentialHandler analogous to the CombinedRealm: you will
accept either MessageDigestCredentiaHandler{SHA1} /or/, say, PBKDF,
bcrypt, etc., by checking one CredentialHandler and then the second (or
third?) if the first one fails.
This would be good. One could have an array of CredentialHandler to
check in order. Is the idea that a password stored in an old format
would be matched using the old CredentialHandler and (upon first
match) stored in the upgraded format (the first CredentialHandler)? I
assume the same idea goes for when the same CredentialHandler is used
but the number of iterations has changed.
Django is doing that. I think we could extend the CredentialHandler (or
a subclass) to take a CredentialUpdater which then could be fed with the
new stored credential. That way each Realm could implement its own
CredentialUpdater and set it on its main CredentialHandler.
Felix
Use of a CombinedCredentialHandler might result in a lot of spurious
warnings in the log about invalid credentials. Maybe the
CombinedCredentialHandler could tell the individual child
CredentialHandlers that they should not log invalid credentials?
Yes, we'll need to make sure the logs don't fill up with false
positives.
+1
I'd like to get some other opinions on the public mutate() interface. I
think we might not be able to convince each other ;)
You might be surprised. I was looking at using mutate() from match to
reduce code duplication but if you limit mutate() to just generating new
passwords then I agree there is no need for any other parameters. A
protected method used by both mutate() and match() should work. I'll
take another look.
Without giving an opinion about what method should be called when, I
agree that salt size and iteration count should be taken from the
stored credential when matching. If the latest configuration asks for
a different algorithm, salt size, or iteration count, then the
supplied cleartext password should be re-hashed to the latest specs.
Regarding thread safety for the SecureRandom, we can do that now. It
doesn't cost us very much and it prevents it tripping us up in the
future.
Mark
I saw that String.equals(String s) is being used. I'm not familiar
with the implementation but I imagine that if the string lengths
differ or if the first characters don't match, for example, the method
returns false without checking the rest of the characters. Perhaps
that could lead to a small vulnerability in which through many
attempts and timing an an attacker can infer whether the password
length, etc. is right. I've seen some implementations use a
SecureEquals that tries to take approximately the same time by
comparing all characters of the strings even if the lengths or first
characters don't match. Is this a real concern, or only theory?
Gabriel
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Discussion of pluggable password-derivation in Realms [Bug 56403]
Am 23.09.2014 um 19:35 schrieb Felix Schumacher:
Am 23.09.2014 um 01:56 schrieb "Gabriel E. Sánchez Martínez":
On 09/17/2014 04:36 AM, Mark Thomas wrote:
On 16/09/2014 22:14, Christopher Schultz wrote:
Mark,
On 9/16/14 3:39 PM, Mark Thomas wrote:
Updated patch:
http://people.apache.org/~markt/patches/2014-09-16-bug56403-tc8-v2.patch
It's looking good!
Looks good, but its missing a configuration for the digester to
actually
read the configuration and set-up the CredentialHandler objects at
runtime. Existing MessageDigest-based configs will work, but explicit
class references won't.
Ack. The docs need updating as well.
Speaking of which, I'd like to be able to nest CredentialHandler
instances. The use case is when switching from one type of
password-derivation method to another. We have done this at $work
twice
and being able to handle more than one kind of valid credential in the
database is essential.
OK. That seems like a reasonable requirement.
Given that we are giving better options to users than standard
single-pass MessageDigest password-mutators, we should help them
migrate. The only way to do that would be something like
CombinedCredentialHandler analogous to the CombinedRealm: you will
accept either MessageDigestCredentiaHandler{SHA1} /or/, say, PBKDF,
bcrypt, etc., by checking one CredentialHandler and then the second
(or
third?) if the first one fails.
This would be good. One could have an array of CredentialHandler to
check in order. Is the idea that a password stored in an old format
would be matched using the old CredentialHandler and (upon first
match) stored in the upgraded format (the first CredentialHandler)? I
assume the same idea goes for when the same CredentialHandler is used
but the number of iterations has changed.
Django is doing that. I think we could extend the CredentialHandler
(or a subclass) to take a CredentialUpdater which then could be fed
with the new stored credential. That way each Realm could implement
its own CredentialUpdater and set it on its main CredentialHandler.
I was just looking at implementing it and found, that CredentialHandler
is user agnostic, so putting the updater into CredentialHandler is not
working, as long as it doesn't know which user credentials it should update.
To get around that we could either give the user information to
CredentialHandler, or let CredentialHandler give back the best (newly
hashed) credentials, which could then be stored, if different to to the
old stored credentials.
Felix
Felix
Use of a CombinedCredentialHandler might result in a lot of spurious
warnings in the log about invalid credentials. Maybe the
CombinedCredentialHandler could tell the individual child
CredentialHandlers that they should not log invalid credentials?
Yes, we'll need to make sure the logs don't fill up with false
positives.
+1
I'd like to get some other opinions on the public mutate()
interface. I
think we might not be able to convince each other ;)
You might be surprised. I was looking at using mutate() from match to
reduce code duplication but if you limit mutate() to just generating
new
passwords then I agree there is no need for any other parameters. A
protected method used by both mutate() and match() should work. I'll
take another look.
Without giving an opinion about what method should be called when, I
agree that salt size and iteration count should be taken from the
stored credential when matching. If the latest configuration asks
for a different algorithm, salt size, or iteration count, then the
supplied cleartext password should be re-hashed to the latest specs.
Regarding thread safety for the SecureRandom, we can do that now. It
doesn't cost us very much and it prevents it tripping us up in the
future.
Mark
I saw that String.equals(String s) is being used. I'm not familiar
with the implementation but I imagine that if the string lengths
differ or if the first characters don't match, for example, the
method returns false without checking the rest of the characters.
Perhaps that could lead to a small vulnerability in which through
many attempts and timing an an attacker can infer whether the
password length, etc. is right. I've seen some implementations use a
SecureEquals that tries to take approximately the same time by
comparing all characters of the strings even if the lengths or first
characters don't match. Is this a real concern, or only theory?
Gabriel
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For
Re: svn commit: r1627000 - /tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
On 23/09/2014 17:16, Christopher Schultz wrote:
> Konstantin,
>
> On 9/23/14 10:10 AM, Konstantin Kolinko wrote:
>> 2014-09-23 17:09 GMT+04:00 :
>>> Author: schultz
>>> Date: Tue Sep 23 13:09:42 2014
>>> New Revision: 1627000
>>>
>>> URL: http://svn.apache.org/r1627000
>>> Log:
>>> Micro optimization.
>>>
>>> Modified:
>>> tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
>>>
>>> Modified: tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
>>> URL:
>>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java?rev=1627000&r1=1626999&r2=1627000&view=diff
>>> ==
>>> --- tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java (original)
>>> +++ tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java Tue Sep 23
>>> 13:09:42 2014
>>> @@ -75,10 +75,12 @@ public final class HexUtils {
>>> if (null == bytes) {
>>> return null;
>>> }
>>> +final char[] hex = HexUtils.hex;
>>> +final int length = bytes.length;
>>
>> The above change does not make sense to me.
>>
>> As HexUtils.hex and bytes.length are themselves final fields, it is up
>> to Java JVM to inline them. I see no need to define explicit local
>> fields for them.
>
> Seems there are major objections to small performance improvements. I'll
> revert the change.
I disagree with that characterisation. The objection was that it added
more code for no demonstrable gain. If a micro-benchmark can demonstrate
some quantifiable improvement I'd be happy to take another look.
>>> -StringBuilder sb = new StringBuilder(bytes.length << 1);
>>> +StringBuilder sb = new StringBuilder(length << 1);
>>>
>>> -for(int i = 0; i < bytes.length; ++i) {
>>> +for(int i = 0; i < length; ++i) {
>>> sb.append(hex[(bytes[i] & 0xf0) >> 4])
>>> .append(hex[(bytes[i] & 0x0f)])
>>> ;
>>> @@ -94,8 +96,9 @@ public final class HexUtils {
>>> }
>>>
>>> char[] inputChars = input.toCharArray();
>>> -byte[] result = new byte[input.length() >> 1];
>>> -for (int i = 0; i < result.length; i++) {
>>> +final int length = input.length() >> 1;
>>> +byte[] result = new byte[length];
>>> +for (int i = 0; i < length; i++) {
>>
>> This fromHexString() method (where the above lines are) is used by
>> test code only.
>>
>> The usefulness of this fromHexString() method is somewhat limited, as
>> it does not check correctness of its arguments. If input string has
>> even number of chars, the last char will be silently ignored. If some
>> characters are non-hex, it will silently produce bogus results.
>
> This method will become more useful when bug
> https://issues.apache.org/bugzilla/show_bug.cgi?id=56403 is implemented.
Agreed.
Mark
> Thanks for the review of the code; we'll make appropriate modifications.
>
> -chris
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56776] java.security.AccessControlException in ClassLoaderLogManager on ClassLoader.getParent() call
https://issues.apache.org/bugzilla/show_bug.cgi?id=56776 Mark Thomas changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Mark Thomas --- Given that two committers have tried to recreate this issue and failed, I am resolving this as WORKSFORME. If you can re-create this with a clean install of the latest Tomcat 7 release then please feel free to re-open this and add the steps to reproduce 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
Tomcat for 8.0.13
All, Now a signed Commons Daemon 1.0.15 release is available, I want to test the new code signing service with the Tomcat build. I plan to tag 8.0.13 in the next 12 to 24 hours. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1627118 - /tomcat/trunk/webapps/docs/changelog.xml
Author: markt Date: Tue Sep 23 19:07:40 2014 New Revision: 1627118 URL: http://svn.apache.org/r1627118 Log: Fix changelog 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=1627118&r1=1627117&r2=1627118&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Tue Sep 23 19:07:40 2014 @@ -245,8 +245,9 @@ setting when building Tomcat. (kkolinko) -Ensure that the ide-eclipse build target downloads all -the libraries required by the default Eclipse configuration files. +56990Ensure that the ide-eclipse build target +downloads all the libraries required by the default Eclipse +configuration files. Update the package renamed copy of Apache Commons DBCP 2 to revision - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat for 8.0.13
Mark, On 9/23/14 2:57 PM, Mark Thomas wrote: > Now a signed Commons Daemon 1.0.15 release is available, I want to test > the new code signing service with the Tomcat build. I plan to tag 8.0.13 > in the next 12 to 24 hours. Want to commit your patch for https://issues.apache.org/bugzilla/show_bug.cgi?id=56403 or will that not likely be ready on your 8.0.13 schedule? Thanks, -chris signature.asc Description: OpenPGP digital signature
[Bug 57011] New: Servlet 3 problem when writing HTTP response in the AsyncListener onTimeout method
https://issues.apache.org/bugzilla/show_bug.cgi?id=57011 Bug ID: 57011 Summary: Servlet 3 problem when writing HTTP response in the AsyncListener onTimeout method Product: Tomcat 8 Version: 8.0.12 Hardware: PC Status: NEW Severity: regression Priority: P2 Component: Connectors Assignee: dev@tomcat.apache.org Reporter: dario.frances...@consult.nordea.com Created attachment 32050 --> https://issues.apache.org/bugzilla/attachment.cgi?id=32050&action=edit Servlet Get the following exception every time the onTimeout method has been called INFO: Encountered a non-recycled request and recycled it forcedly. org.apache.catalina.connector.CoyoteAdapter$RecycleRequiredException at org.apache.catalina.connector.CoyoteAdapter.checkRecycled(CoyoteAdapter.java:717) at org.apache.coyote.http11.AbstractHttp11Processor.recycle(AbstractHttp11Processor.java:1791) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.release(Http11NioProtocol.java:239) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:733) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:724) -- 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 57011] Servlet 3 problem when writing HTTP response in the AsyncListener onTimeout method
https://issues.apache.org/bugzilla/show_bug.cgi?id=57011 --- Comment #1 from Dario Franceschi --- Created attachment 32051 --> https://issues.apache.org/bugzilla/attachment.cgi?id=32051&action=edit Context listener If you omit the close on the printwriter the socket will be RST before the data is transferred causing for instance wget to re-submit -- 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 57011] Servlet 3 problem when writing HTTP response in the AsyncListener onTimeout method
https://issues.apache.org/bugzilla/show_bug.cgi?id=57011 Dario Franceschi changed: What|Removed |Added OS||All --- Comment #2 from Dario Franceschi --- Seems I only get this on windows 7 (64) and tomcat 8 ( tried 8-11 & 8-12 ) on tomcat 7 I do not get this, I do not get this on tomcat 8 on (32 bit) linux either. Have also tried Java7 & Java8 but that does not seem to be related. -- 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 57011] Exception when writing HTTP response in the AsyncListener onTimeout method (servlet 3 HTTP-NIO)
https://issues.apache.org/bugzilla/show_bug.cgi?id=57011 Dario Franceschi changed: What|Removed |Added Summary|Servlet 3 problem when |Exception when writing HTTP |writing HTTP response in|response in the |the AsyncListener onTimeout |AsyncListener onTimeout |method |method (servlet 3 HTTP-NIO) -- 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 57011] Exception when writing HTTP response in the AsyncListener onTimeout method (servlet 3 HTTP-NIO)
https://issues.apache.org/bugzilla/show_bug.cgi?id=57011 Christopher Schultz changed: What|Removed |Added OS|All |Windows 7 -- 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 success in ASF Buildbot on tomcat-trunk
The Buildbot has detected a restored build on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/471 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1627118 Blamelist: markt,schultz Build succeeded! sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57006] openssl s_client may connected with property allowUnsafeLegacyRenegotiation set false
https://issues.apache.org/bugzilla/show_bug.cgi?id=57006 xinshouke <1599409...@qq.com> changed: What|Removed |Added Status|RESOLVED|REOPENED CC||1599409...@qq.com Resolution|INVALID |--- --- Comment #6 from xinshouke <1599409...@qq.com> --- According to the reading source code and doc in the Tomcat web site,I found the attribute 'allowUnsafeLegacyRenegotiation' with set false as default, I suspect when I needn't set anythings for the attribute in the tomcat server.xml to avoid The SSL Renegotation Attack thr SSL,should I? (In reply to Mark Thomas from comment #5) > I still don't see anything in this report that describes unexpected, > undesirable or insecure behavior. Again, please user the 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: r1627229 - /tomcat/trunk/webapps/docs/changelog.xml
Author: kkolinko Date: Wed Sep 24 06:14:55 2014 New Revision: 1627229 URL: http://svn.apache.org/r1627229 Log: Correct typo 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=1627229&r1=1627228&r2=1627229&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Wed Sep 24 06:14:55 2014 @@ -245,9 +245,9 @@ setting when building Tomcat. (kkolinko) -56990Ensure that the ide-eclipse build target +56990: Ensure that the ide-eclipse build target downloads all the libraries required by the default Eclipse -configuration files. +configuration files. (markt) Update the package renamed copy of Apache Commons DBCP 2 to revision - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1627231 - in /tomcat/tc7.0.x/trunk: ./ build.xml webapps/docs/changelog.xml
Author: kkolinko
Date: Wed Sep 24 06:42:02 2014
New Revision: 1627231
URL: http://svn.apache.org/r1627231
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56990
Ensure that the ide-eclipse build target downloads all the libraries required
by the default Eclipse configuration files.
It is port of r1626779.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/build.xml
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1626779
Modified: tomcat/tc7.0.x/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/build.xml?rev=1627231&r1=1627230&r2=1627231&view=diff
==
--- tomcat/tc7.0.x/trunk/build.xml (original)
+++ tomcat/tc7.0.x/trunk/build.xml Wed Sep 24 06:42:02 2014
@@ -2924,7 +2924,8 @@ Apache Tomcat ${version} native binaries
-
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=1627231&r1=1627230&r2=1627231&view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Wed Sep 24 06:42:02 2014
@@ -306,6 +306,11 @@
56988: Allow to use relative path in base.path
setting when building Tomcat. (kkolinko)
+
+56990: Ensure that the ide-eclipse build target
+downloads all the libraries required by the default Eclipse
+configuration files. (kkolinko)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56990] ant ide-eclipse target shall download easymock library
https://issues.apache.org/bugzilla/show_bug.cgi?id=56990 --- Comment #2 from Konstantin Kolinko --- Thank you. I ported the fix to Tomcat 7 in r1627231, it will be in 7.0.56. Tomcat 7 tests do not use easymock, but users say that they want to use the same version of junit and hamcrest libraries as used by Tomcat instead of ones provided by IDE, as the latter ones may be outdated. This change makes `ant ide-eclipse` target to download those libraries. -- 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
