[Bug 63287] Inconsistent log level practices in Catalina component

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63287

--- Comment #2 from AnhT  ---
Thank you very much Mark for your feedback and insightful suggestion that have
helped to refine my work.

-- 
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] branch 8.5.x updated: Fix regression for PKCS#8 private keys with OpenSSL

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 8245479  Fix regression for PKCS#8 private keys with OpenSSL
8245479 is described below

commit 8245479675d068753232acdc9ef456e43fed8e8e
Author: Mark Thomas 
AuthorDate: Thu Mar 28 23:15:02 2019 +

Fix regression for PKCS#8 private keys with OpenSSL
---
 java/org/apache/tomcat/util/net/openssl/OpenSSLUtil.java | 5 -
 webapps/docs/changelog.xml   | 5 +
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/tomcat/util/net/openssl/OpenSSLUtil.java 
b/java/org/apache/tomcat/util/net/openssl/OpenSSLUtil.java
index 6878deb..74e115f 100644
--- a/java/org/apache/tomcat/util/net/openssl/OpenSSLUtil.java
+++ b/java/org/apache/tomcat/util/net/openssl/OpenSSLUtil.java
@@ -16,6 +16,7 @@
  */
 package org.apache.tomcat.util.net.openssl;
 
+import java.io.IOException;
 import java.security.KeyStoreException;
 import java.util.List;
 import java.util.Set;
@@ -102,7 +103,9 @@ public class OpenSSLUtil extends SSLUtilBase {
 public KeyManager[] getKeyManagers() throws Exception {
 try {
 return super.getKeyManagers();
-} catch (KeyStoreException e) {
+} catch (KeyStoreException | IOException e) {
+// Depending on what is presented, JSSE may throw either of the
+// above exceptions if it doesn't understand the provided file.
 if (certificate.getCertificateFile() != null) {
 if (log.isDebugEnabled()) {
 log.info(sm.getString("openssl.nonJsseCertficate",
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index b482e9c..63a752b 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -98,6 +98,11 @@
 a protocol was not negotiated, Tomcat failed to fallback to HTTP/1.1 
and
 instead dropped the connection. (markt)
   
+  
+Correct a regression in the TLS connector refactoring in Tomcat 9.0.17
+that prevented the use of PKCS#8 private keys with OpenSSL based
+connectors. (markt)
+  
 
   
   


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch master updated: Fix regression for PKCS#8 private keys with OpenSSL

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 294d13b  Fix regression for PKCS#8 private keys with OpenSSL
294d13b is described below

commit 294d13b16f244a54df018dffb9fb47231dcbd26b
Author: Mark Thomas 
AuthorDate: Thu Mar 28 23:15:02 2019 +

Fix regression for PKCS#8 private keys with OpenSSL
---
 java/org/apache/tomcat/util/net/openssl/OpenSSLUtil.java | 5 -
 webapps/docs/changelog.xml   | 5 +
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/tomcat/util/net/openssl/OpenSSLUtil.java 
b/java/org/apache/tomcat/util/net/openssl/OpenSSLUtil.java
index 6878deb..74e115f 100644
--- a/java/org/apache/tomcat/util/net/openssl/OpenSSLUtil.java
+++ b/java/org/apache/tomcat/util/net/openssl/OpenSSLUtil.java
@@ -16,6 +16,7 @@
  */
 package org.apache.tomcat.util.net.openssl;
 
+import java.io.IOException;
 import java.security.KeyStoreException;
 import java.util.List;
 import java.util.Set;
@@ -102,7 +103,9 @@ public class OpenSSLUtil extends SSLUtilBase {
 public KeyManager[] getKeyManagers() throws Exception {
 try {
 return super.getKeyManagers();
-} catch (KeyStoreException e) {
+} catch (KeyStoreException | IOException e) {
+// Depending on what is presented, JSSE may throw either of the
+// above exceptions if it doesn't understand the provided file.
 if (certificate.getCertificateFile() != null) {
 if (log.isDebugEnabled()) {
 log.info(sm.getString("openssl.nonJsseCertficate",
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index fcd55ed..67ae696 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -113,6 +113,11 @@
 a protocol was not negotiated, Tomcat failed to fallback to HTTP/1.1 
and
 instead dropped the connection. (markt)
   
+  
+Correct a regression in the TLS connector refactoring in Tomcat 9.0.17
+that prevented the use of PKCS#8 private keys with OpenSSL based
+connectors. (markt)
+  
 
   
   


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 63287] Inconsistent log level practices in Catalina component

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63287

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Mark Thomas  ---
Thanks for the report.

Reviewing the individual reports I think there is a little to much focus on
similarity of code and not enough focus on similarity of function. To put it
another way, an invalid charset may be a minor issue when provided as part of a
user request but a significant issue if a security realm is configured to
digest passwords using an invalid encoding.

For report 1, a better comparison would be how the MemoryUserDatabase handles a
missing/invalid tomcat-users.xml file. Also, there are other error conditions
earlier in JAASMemoryLoginModule that should be treated in a consistent manner.

For report 2, an argument could be made that AccessLogValve should use WARN but
it isn't a very strong argument. For Response, an invalid encoding may not be
an error so WARN seems right. I think there is a case for making
MessageDigestCredentialHandler and Connector ERROR.

For report 3, I agree they should be the same buy I'd switch to WARN since
cluster nodes going down isn't unexpected.

Fixed in master for 9.0.18 onwards.

-- 
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] branch master updated (8cbe4ba -> 819fceb)

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


from 8cbe4ba  Remove apparent Registry code duplication
 new 8f6dd89  Log level consistency
 new f702768  Better log levels
 new 2e24a34  Log ping failures consistently at WARN
 new 819fceb  Update changelog

The 20686 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 java/org/apache/catalina/connector/Connector.java   | 2 +-
 java/org/apache/catalina/realm/JAASMemoryLoginModule.java   | 6 +++---
 java/org/apache/catalina/realm/MessageDigestCredentialHandler.java  | 2 +-
 .../apache/catalina/tribes/membership/StaticMembershipProvider.java | 2 +-
 webapps/docs/changelog.xml  | 4 
 5 files changed, 10 insertions(+), 6 deletions(-)


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Becoming graalvm friendly?

[Romain Manni-Bucau]

You can make it supporting JUL switching the log manager to a simpler
version, AFAIK this is what quarkus does using jboss logging log manager,
guess it shouldn't be that complicated to switch to a lighter version of
JUL one without reload capabilities - still thinking out loud.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 28 mars 2019 à 16:19, Rémy Maucherat  a écrit :

> On Thu, Mar 28, 2019 at 3:43 PM Romain Manni-Bucau 
> wrote:
>
> > In my case - I tried on meecrowave - i just switched using Log SPI the
> impl
> > to something else - custom log4j2 IIRC - and it passed that state until
> it
> > fails on JMX. Then i @Subtitute some code in the Registry and base
> classes
> > but it is literally "monkey patching" Tomcat which is something I really
> > disliked - versus adding a module using a SPI which deactivates some
> > potential code path.
> >
> > My goal is to avoid to fork most of the stack as quarkus did and ensure
> > built-in tomcat can be compiled natively. Using more SPI can be a good
> > option probably and even open more doors to integrators which is never
> bad
> > IMHO.
> >
>
> Well, support for java.util.logging shouldn't be optional (this isn't even
> documented, while JMX is at least documented as not supported). I don't
> think Tomcat support is ever going to happen unless Graal capabilities
> manages to improve, if at all possible, right now it's simply too alien.
>
> Rémy
>

[Bug 63299] Exception occurs while starting deployed war on windows only

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63299

Coty Sutherland  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #1 from Coty Sutherland  ---
Bugzilla is not a support forum. Please use the users mailing list. Thanks!

-- 
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 63299] New: Exception occurs while starting deployed war on windows only

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63299

Bug ID: 63299
   Summary: Exception occurs while starting deployed war on
windows only
   Product: Tomcat 9
   Version: 9.0.x
  Hardware: PC
OS: Mac OS X 10.1
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: kolesl...@yandex.ru
  Target Milestone: -

Exception occurs while starting deployed war on windows os only, for unix os
war starts successfully.

war: https://drive.google.com/file/d/1sRafj4QDwUtx2Gjug15BwjzJOi9MqIGk/view
exc: Caused by: java.lang.IllegalArgumentException: The archive
[jar:file:/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%209.0/webapps/annotation-spring-1.12.15.war!/]
is malformed and will be ignored: an entry contains an illegal path
[com/aspose/email/aux.class] which was not expanded to [\.\aux] since that is
outside of the defined docBase [C:\Program Files\Apache Software
Foundation\Tomcat 9.0\webapps\annotation-spring-1.12.15]
at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:142)

It seems like there is something wrong with implementation FileSystem for
Windows OS in java.

Please, provide any information how to fix 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

Re: Becoming graalvm friendly?

[Rémy Maucherat]

On Thu, Mar 28, 2019 at 3:43 PM Romain Manni-Bucau 
wrote:

> In my case - I tried on meecrowave - i just switched using Log SPI the impl
> to something else - custom log4j2 IIRC - and it passed that state until it
> fails on JMX. Then i @Subtitute some code in the Registry and base classes
> but it is literally "monkey patching" Tomcat which is something I really
> disliked - versus adding a module using a SPI which deactivates some
> potential code path.
>
> My goal is to avoid to fork most of the stack as quarkus did and ensure
> built-in tomcat can be compiled natively. Using more SPI can be a good
> option probably and even open more doors to integrators which is never bad
> IMHO.
>

Well, support for java.util.logging shouldn't be optional (this isn't even
documented, while JMX is at least documented as not supported). I don't
think Tomcat support is ever going to happen unless Graal capabilities
manages to improve, if at all possible, right now it's simply too alien.

Rémy

Re: Becoming graalvm friendly?

[Romain Manni-Bucau]

In my case - I tried on meecrowave - i just switched using Log SPI the impl
to something else - custom log4j2 IIRC - and it passed that state until it
fails on JMX. Then i @Subtitute some code in the Registry and base classes
but it is literally "monkey patching" Tomcat which is something I really
disliked - versus adding a module using a SPI which deactivates some
potential code path.

My goal is to avoid to fork most of the stack as quarkus did and ensure
built-in tomcat can be compiled natively. Using more SPI can be a good
option probably and even open more doors to integrators which is never bad
IMHO.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 28 mars 2019 à 15:38, Rémy Maucherat  a écrit :

> On Wed, Mar 20, 2019 at 4:45 PM Romain Manni-Bucau 
> wrote:
>
> > Most of the time monitoring is done through a custom exporter in practise
> > based on other impl - sigar, library integration like
> > hibernate/eclipselinks ones, metrics, microprofile etc... -  and JMX is
> not
> > then used - not judging it is good, bad, lack of knowledge or not, just
> > saying what i see.
> > Now I'm happy if JMX is made graal compatible. From what I saw, mainly
> the
> > MBeanServer and Notifier (through the hierarchy it goes until that point
> in
> > the JVM in standard mbeans) are blocking the compilation. I'm pretty sure
> > these parts of Tomcat can be extracted in a particular class and then
> > substrated which would make it graal compatible probably.
> >
>
> Ok, so I had a (quick) look, and this doesn't seem to be something that is
> adapted to Tomcat at this time.
>
> Steps:
> - I built the embedded packaging here
> https://github.com/apache/tomcat/tree/master/res/tomcat-maven
> - It produces a standalone jar in target/tomcat-maven-1.0.jar
> - Une the graal tool $GRAALVM/bin/native-image -jar
> target/tomcat-maven-1.0.jar
>
> Produces:
> Error: No instances are allowed in the image heap for a class that is
> initialized or reinitialized at image runtime:
> java.util.logging.SimpleFormatter
> Detailed message:
> Error: No instances are allowed in the image heap for a class that is
> initialized or reinitialized at image runtime:
> java.util.logging.SimpleFormatter
> Trace: object java.util.logging.ConsoleHandler
> object java.lang.Object[]
> object java.util.concurrent.CopyOnWriteArrayList
> object java.util.logging.LogManager$RootLogger
> object java.util.logging.Logger
> object org.apache.juli.logging.DirectJDKLog
> method
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState,
> Object, boolean)
> Call path from entry point to
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState,
> Object, boolean):
> at
>
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:390)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:193)
> at org.apache.catalina.startup.Tomcat.start(Tomcat.java:455)
> at org.apache.catalina.startup.Tomcat.main(Tomcat.java:1444)
> at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:152)
> at
>
> com.oracle.svm.core.code.IsolateEnterStub.JavaMainWrapper_run_5087f5482cc9a6abc971913ece43acb471d2631b(generated:0)
>
> If you want to work on this, you can (git makes it easy) but it looks a bit
> daunting at this point (java.util.logging is not supported either ? this is
> not documented at
> https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md ).
>
> Rémy
>

Re: Becoming graalvm friendly?

[Rémy Maucherat]

On Wed, Mar 20, 2019 at 4:45 PM Romain Manni-Bucau 
wrote:

> Most of the time monitoring is done through a custom exporter in practise
> based on other impl - sigar, library integration like
> hibernate/eclipselinks ones, metrics, microprofile etc... -  and JMX is not
> then used - not judging it is good, bad, lack of knowledge or not, just
> saying what i see.
> Now I'm happy if JMX is made graal compatible. From what I saw, mainly the
> MBeanServer and Notifier (through the hierarchy it goes until that point in
> the JVM in standard mbeans) are blocking the compilation. I'm pretty sure
> these parts of Tomcat can be extracted in a particular class and then
> substrated which would make it graal compatible probably.
>

Ok, so I had a (quick) look, and this doesn't seem to be something that is
adapted to Tomcat at this time.

Steps:
- I built the embedded packaging here
https://github.com/apache/tomcat/tree/master/res/tomcat-maven
- It produces a standalone jar in target/tomcat-maven-1.0.jar
- Une the graal tool $GRAALVM/bin/native-image -jar
target/tomcat-maven-1.0.jar

Produces:
Error: No instances are allowed in the image heap for a class that is
initialized or reinitialized at image runtime:
java.util.logging.SimpleFormatter
Detailed message:
Error: No instances are allowed in the image heap for a class that is
initialized or reinitialized at image runtime:
java.util.logging.SimpleFormatter
Trace: object java.util.logging.ConsoleHandler
object java.lang.Object[]
object java.util.concurrent.CopyOnWriteArrayList
object java.util.logging.LogManager$RootLogger
object java.util.logging.Logger
object org.apache.juli.logging.DirectJDKLog
method
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState,
Object, boolean)
Call path from entry point to
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState,
Object, boolean):
at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:390)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:193)
at org.apache.catalina.startup.Tomcat.start(Tomcat.java:455)
at org.apache.catalina.startup.Tomcat.main(Tomcat.java:1444)
at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:152)
at
com.oracle.svm.core.code.IsolateEnterStub.JavaMainWrapper_run_5087f5482cc9a6abc971913ece43acb471d2631b(generated:0)

If you want to work on this, you can (git makes it easy) but it looks a bit
daunting at this point (java.util.logging is not supported either ? this is
not documented at
https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md ).

Rémy

[tomcat] branch master updated: Remove apparent Registry code duplication

[remm]

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 8cbe4ba  Remove apparent Registry code duplication
8cbe4ba is described below

commit 8cbe4ba594dc41615faafb216fcb4ff3e0d8fafc
Author: remm 
AuthorDate: Thu Mar 28 15:31:09 2019 +0100

Remove apparent Registry code duplication

mserver field seems useless overall, so deprecate it. Use the resgistry
register/unregister rather than duplicated code.
---
 java/org/apache/catalina/core/StandardServer.java  | 12 ---
 .../apache/catalina/util/LifecycleMBeanBase.java   | 40 +++---
 .../apache/catalina/util/LocalStrings.properties   |  2 --
 3 files changed, 12 insertions(+), 42 deletions(-)

diff --git a/java/org/apache/catalina/core/StandardServer.java 
b/java/org/apache/catalina/core/StandardServer.java
index 5c38e19..2bf87a1 100644
--- a/java/org/apache/catalina/core/StandardServer.java
+++ b/java/org/apache/catalina/core/StandardServer.java
@@ -38,6 +38,7 @@ import java.util.concurrent.TimeUnit;
 
 import javax.management.InstanceNotFoundException;
 import javax.management.MBeanException;
+import javax.management.MBeanServer;
 import javax.management.ObjectName;
 
 import org.apache.catalina.Context;
@@ -56,6 +57,7 @@ import org.apache.juli.logging.Log;
 import org.apache.juli.logging.LogFactory;
 import org.apache.tomcat.util.ExceptionUtils;
 import org.apache.tomcat.util.buf.StringCache;
+import org.apache.tomcat.util.modeler.Registry;
 import org.apache.tomcat.util.res.StringManager;
 import org.apache.tomcat.util.threads.TaskThreadFactory;
 
@@ -849,8 +851,9 @@ public final class StandardServer extends 
LifecycleMBeanBase implements Server {
 try {
 // Note: Hard-coded domain used since this object is per Server/JVM
 ObjectName sname = new ObjectName("Catalina:type=StoreConfig");
-if (mserver.isRegistered(sname)) {
-mserver.invoke(sname, "storeConfig", null, null);
+MBeanServer server = Registry.getRegistry(null, 
null).getMBeanServer();
+if (server.isRegistered(sname)) {
+server.invoke(sname, "storeConfig", null, null);
 } else {
 
log.error(sm.getString("standardServer.storeConfig.notAvailable", sname));
 }
@@ -878,8 +881,9 @@ public final class StandardServer extends 
LifecycleMBeanBase implements Server {
 try {
 // Note: Hard-coded domain used since this object is per Server/JVM
 ObjectName sname = new ObjectName("Catalina:type=StoreConfig");
-if (mserver.isRegistered(sname)) {
-mserver.invoke(sname, "store",
+MBeanServer server = Registry.getRegistry(null, 
null).getMBeanServer();
+if (server.isRegistered(sname)) {
+server.invoke(sname, "store",
 new Object[] {context},
 new String [] { "java.lang.String"});
 } else {
diff --git a/java/org/apache/catalina/util/LifecycleMBeanBase.java 
b/java/org/apache/catalina/util/LifecycleMBeanBase.java
index def6453..90fc2c8 100644
--- a/java/org/apache/catalina/util/LifecycleMBeanBase.java
+++ b/java/org/apache/catalina/util/LifecycleMBeanBase.java
@@ -17,8 +17,6 @@
 
 package org.apache.catalina.util;
 
-import javax.management.InstanceNotFoundException;
-import javax.management.MBeanRegistrationException;
 import javax.management.MBeanServer;
 import javax.management.MalformedObjectNameException;
 import javax.management.ObjectName;
@@ -43,6 +41,7 @@ public abstract class LifecycleMBeanBase extends LifecycleBase
 /* Cache components of the MBean registration. */
 private String domain = null;
 private ObjectName oname = null;
+@Deprecated
 protected MBeanServer mserver = null;
 
 /**
@@ -52,7 +51,6 @@ public abstract class LifecycleMBeanBase extends LifecycleBase
  */
 @Override
 protected void initInternal() throws LifecycleException {
-
 // If oname is not null then registration has already happened via
 // preRegister().
 if (oname == null) {
@@ -157,8 +155,7 @@ public abstract class LifecycleMBeanBase extends 
LifecycleBase
 
 try {
 on = new ObjectName(name.toString());
-
-Registry.getRegistry(null, null).registerComponent(obj, on, null);
+Registry.getRegistry(null, 
null).registerComponent(name.toString(), on, null);
 } catch (MalformedObjectNameException e) {
 log.warn(sm.getString("lifecycleMBeanBase.registerFail", obj, 
name),
 e);
@@ -187,17 +184,7 @@ public abstract class LifecycleMBeanBase extends 
LifecycleBase
 StringBuilder name = new StringBuilder(getDomain());
 name.append(':');
 name.append(objectNameKeyProperti

[tomcat] branch 8.5.x updated: WS

[remm]

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/8.5.x by this push:
 new b9b5f23  WS
b9b5f23 is described below

commit b9b5f236cac2fa24b9f3ad0a4cc8ba42f3bce8e2
Author: remm 
AuthorDate: Thu Mar 28 09:33:02 2019 +0100

WS
---
 java/org/apache/tomcat/util/net/Nio2Endpoint.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/java/org/apache/tomcat/util/net/Nio2Endpoint.java 
b/java/org/apache/tomcat/util/net/Nio2Endpoint.java
index 0432198..ca94fe0 100644
--- a/java/org/apache/tomcat/util/net/Nio2Endpoint.java
+++ b/java/org/apache/tomcat/util/net/Nio2Endpoint.java
@@ -737,7 +737,7 @@ public class Nio2Endpoint extends 
AbstractJsseEndpoint {
 writeInterest = true;
 return false;
 }
-// If the buffer is empty, it is possible to write to it 
+// If the buffer is empty, it is possible to write to it
 if (socketBufferHandler.isWriteBufferEmpty() && 
nonBlockingWriteBuffer.isEmpty()) {
 writePending.release();
 return true;


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GUMP@vmgump-vm3]: Project tomcat-tc8.5.x-validate (in module tomcat-8.5.x) failed

[Bill Barker]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project tomcat-tc8.5.x-validate has an issue affecting its community 
integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-tc8.5.x-validate :  Tomcat 8.x, a web server implementing the Java 
Servlet 3.1,
...


Full details are available at:
http://vmgump-vm3.apache.org/tomcat-8.5.x/tomcat-tc8.5.x-validate/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on checkstyle exists, no need to add for property 
checkstyle.jar.
 -INFO- Failed with reason build failed



The following work was performed:
http://vmgump-vm3.apache.org/tomcat-8.5.x/tomcat-tc8.5.x-validate/gump_work/build_tomcat-8.5.x_tomcat-tc8.5.x-validate.html
Work Name: build_tomcat-8.5.x_tomcat-tc8.5.x-validate (Type: Build)
Work ended in a state of : Failed
Elapsed: 22 secs
Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only -Dsun.zip.disableMemoryMapping=true 
org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Dbase.path=/srv/gump/public/workspace/tomcat-8.5.x/tomcat-build-libs 
-Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-8.19-SNAPSHOT.jar
 -Dexecute.validate=true validate 
[Working Directory: /srv/gump/public/workspace/tomcat-8.5.x]
CLASSPATH: 
/usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-8.19-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/commons-beanutils/dist/commons-beanutils-20190328.jar:/srv/gump/packages/commons-collections3/commons-collections-3.2.1.jar:/srv/gump/public/workspace/commons-cli/target/commons-cli-1.5-SNAPSHOT.jar:/srv/gump/public/workspace/commons-lang-trunk/target/commons-lang3-3.9-SNAPSHOT.jar:/srv/gump/pu
 
blic/workspace/apache-commons/logging/target/commons-logging-20190328.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20190328.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-HEAD-jre-SNAPSHOT.jar
-
Buildfile: /srv/gump/public/workspace/tomcat-8.5.x/build.xml

build-prepare:
   [delete] Deleting directory 
/srv/gump/public/workspace/tomcat-8.5.x/output/build/temp
[mkdir] Created dir: 
/srv/gump/public/workspace/tomcat-8.5.x/output/build/temp

compile-prepare:

download-validate:

testexist:
 [echo] Testing  for 
/srv/gump/public/workspace/checkstyle/target/checkstyle-8.19-SNAPSHOT.jar

setproxy:

downloadfile:

validate:
[mkdir] Created dir: 
/srv/gump/public/workspace/tomcat-8.5.x/output/res/checkstyle
[checkstyle] Running Checkstyle 8.19-SNAPSHOT on 3243 files
[checkstyle] [ERROR] 
/srv/gump/public/workspace/tomcat-8.5.x/java/org/apache/tomcat/util/net/Nio2Endpoint.java:740:
 Line matches the illegal pattern '\s+$'. [RegexpSingleline]

BUILD FAILED
/srv/gump/public/workspace/tomcat-8.5.x/build.xml:558: Got 1 errors and 0 
warnings.

Total time: 22 seconds
-

To subscribe to this information via syndicated feeds:
- RSS: http://vmgump-vm3.apache.org/tomcat-8.5.x/tomcat-tc8.5.x-validate/rss.xml
- Atom: 
http://vmgump-vm3.apache.org/tomcat-8.5.x/tomcat-tc8.5.x-validate/atom.xml

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 20190328060006, vmgump-vm3.apache.org:vmgump:20190328060006
Gump E-mail Identifier (unique within run) #2.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump-vm3]

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org