[Bug 64621] HTTP/2 Tomcat Server responds with RST_STREAM (REFUSED_STREAM) continuously in one of the TCP connection.

[bugzilla]

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

--- Comment #6 from Raghavendran V  ---
Thanks Mark, for the update. Will try to reproduce in our local setup and will
get back to you with more clarity. As this occurs randomly, we are yet to
narrow down to the "reproduction steps". So, will get back to you ASAP. 

Thanks again for the swift responses.

-- 
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] liudongmiao commented on a change in pull request #30: Tc9.x Initial suport for Tomact9

[GitBox]

liudongmiao commented on a change in pull request #30:
URL: https://github.com/apache/tomcat-maven-plugin/pull/30#discussion_r459798227



##
File path: 
tomcat9-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat9/run/RunMojo.java
##
@@ -479,18 +480,23 @@ private WebResource urlToWebResource( URL url, String 
path )
 jarFile = new JarFile( filePath );
 
 JarEntry jarEntry = jarFile.getJarEntry( 
StringUtils.removeStart( path, "/" ) );
-
+/*
 return new JarResource( this, //
 getPath(), //
 filePath, //
 
url.getPath().substring( 0, idx ), //
 jarEntry, //
 "", //
 null );
+*/
+
+JarResourceSet jr = new 
JarResourceSet(context.getResources(), getPath(), filePath, getPath());

Review comment:
   Sorry for outdated.
   
   Yes, for the code, it's changed from `getPath()` to `"/"` in commit 
7f26908685ee565c1a501ec7b03763905adf1b1b.
   And the internal path is always `"/"` now.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[tomcat] branch master updated: Allow detection of Graal via reflection or system property

[fhanik]

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

fhanik 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 b1820ad  Allow detection of Graal via reflection or system property
b1820ad is described below

commit b1820ad16b41671c265c7194deb0d723d9c34ac9
Author: Filip Hanik 
AuthorDate: Thu Jul 23 15:41:16 2020 -0700

Allow detection of Graal via reflection or system property
---
 java/org/apache/jasper/runtime/JspRuntimeLibrary.java | 2 +-
 java/org/apache/naming/NamingContext.java | 2 +-
 java/org/apache/tomcat/util/compat/GraalCompat.java   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java 
b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
index cfb6e75..73b149f 100644
--- a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
+++ b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
@@ -69,7 +69,7 @@ public class JspRuntimeLibrary {
 } catch (ReflectiveOperationException | IllegalArgumentException e) {
 // Should never happen
 }
-GRAAL = result;
+GRAAL = result || 
System.getProperty("org.graalvm.nativeimage.imagecode") != null;
 }
 
 /**
diff --git a/java/org/apache/naming/NamingContext.java 
b/java/org/apache/naming/NamingContext.java
index 0471279..a064421 100644
--- a/java/org/apache/naming/NamingContext.java
+++ b/java/org/apache/naming/NamingContext.java
@@ -804,7 +804,7 @@ public class NamingContext implements Context {
 } catch (ReflectiveOperationException | IllegalArgumentException e) {
 // Should never happen
 }
-GRAAL = result;
+GRAAL = result || 
System.getProperty("org.graalvm.nativeimage.imagecode") != null;
 }
 
 /**
diff --git a/java/org/apache/tomcat/util/compat/GraalCompat.java 
b/java/org/apache/tomcat/util/compat/GraalCompat.java
index 9fb835a..6187eb6 100644
--- a/java/org/apache/tomcat/util/compat/GraalCompat.java
+++ b/java/org/apache/tomcat/util/compat/GraalCompat.java
@@ -32,7 +32,7 @@ class GraalCompat extends Jre9Compat {
 } catch (ReflectiveOperationException | IllegalArgumentException e) {
 // Should never happen
 }
-GRAAL = result;
+GRAAL = result || 
System.getProperty("org.graalvm.nativeimage.imagecode") != null;
 }
 
 static boolean isSupported() {


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

[tomcat] branch 9.0.x updated: Allow detection of Graal via reflection or system property

[fhanik]

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

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


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 73288c6  Allow detection of Graal via reflection or system property
73288c6 is described below

commit 73288c6b3c979777054e4fc5baf0163c84bb2ac9
Author: Filip Hanik 
AuthorDate: Thu Jul 23 15:41:16 2020 -0700

Allow detection of Graal via reflection or system property
---
 java/org/apache/jasper/runtime/JspRuntimeLibrary.java | 2 +-
 java/org/apache/naming/NamingContext.java | 2 +-
 java/org/apache/tomcat/util/compat/GraalCompat.java   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java 
b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
index c0a7a63..3a0cc1b 100644
--- a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
+++ b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
@@ -69,7 +69,7 @@ public class JspRuntimeLibrary {
 } catch (ReflectiveOperationException | IllegalArgumentException e) {
 // Should never happen
 }
-GRAAL = result;
+GRAAL = result || 
System.getProperty("org.graalvm.nativeimage.imagecode") != null;
 }
 
 /**
diff --git a/java/org/apache/naming/NamingContext.java 
b/java/org/apache/naming/NamingContext.java
index 0471279..a064421 100644
--- a/java/org/apache/naming/NamingContext.java
+++ b/java/org/apache/naming/NamingContext.java
@@ -804,7 +804,7 @@ public class NamingContext implements Context {
 } catch (ReflectiveOperationException | IllegalArgumentException e) {
 // Should never happen
 }
-GRAAL = result;
+GRAAL = result || 
System.getProperty("org.graalvm.nativeimage.imagecode") != null;
 }
 
 /**
diff --git a/java/org/apache/tomcat/util/compat/GraalCompat.java 
b/java/org/apache/tomcat/util/compat/GraalCompat.java
index 9fb835a..6187eb6 100644
--- a/java/org/apache/tomcat/util/compat/GraalCompat.java
+++ b/java/org/apache/tomcat/util/compat/GraalCompat.java
@@ -32,7 +32,7 @@ class GraalCompat extends Jre9Compat {
 } catch (ReflectiveOperationException | IllegalArgumentException e) {
 // Should never happen
 }
-GRAAL = result;
+GRAAL = result || 
System.getProperty("org.graalvm.nativeimage.imagecode") != null;
 }
 
 static boolean isSupported() {


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

[tomcat] branch master updated: Minor EL bugs when running under Graal/SubstrateVM

[fhanik]

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

fhanik 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 f03f60e  Minor EL bugs when running under Graal/SubstrateVM
f03f60e is described below

commit f03f60e04a97f283825da9000a913107922d24fb
Author: Filip Hanik 
AuthorDate: Thu Jul 23 12:17:33 2020 -0700

Minor EL bugs when running under Graal/SubstrateVM
---
 java/org/apache/jasper/el/JasperELResolver.java | 4 
 test/org/apache/jasper/el/TestJasperELResolver.java | 8 +---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/java/org/apache/jasper/el/JasperELResolver.java 
b/java/org/apache/jasper/el/JasperELResolver.java
index d28c61c..71ed2ff 100644
--- a/java/org/apache/jasper/el/JasperELResolver.java
+++ b/java/org/apache/jasper/el/JasperELResolver.java
@@ -199,6 +199,7 @@ public class JasperELResolver extends CompositeELResolver {
 if (method != null) {
 context.setPropertyResolved(base, property);
 try {
+method.setAccessible(true);
 value = method.invoke(base, (Object[]) null);
 } catch (Exception ex) {
 Throwable thr = 
ExceptionUtils.unwrapInvocationTargetException(ex);
@@ -211,6 +212,9 @@ public class JasperELResolver extends CompositeELResolver {
 @Override
 public void setValue(ELContext context, Object base, Object property,
 Object value) {
+if (base == null) {
+return;
+}
 Method method = getWriteMethod(base.getClass(), 
property.toString());
 if (method != null) {
 context.setPropertyResolved(base, property);
diff --git a/test/org/apache/jasper/el/TestJasperELResolver.java 
b/test/org/apache/jasper/el/TestJasperELResolver.java
index 59c31d6..d58391e 100644
--- a/test/org/apache/jasper/el/TestJasperELResolver.java
+++ b/test/org/apache/jasper/el/TestJasperELResolver.java
@@ -28,6 +28,7 @@ import org.junit.Assert;
 import org.junit.Test;
 
 import org.apache.el.stream.StreamELResolverImpl;
+import org.apache.jasper.runtime.JspRuntimeLibrary;
 
 public class TestJasperELResolver {
 
@@ -53,15 +54,16 @@ public class TestJasperELResolver {
 list.add(new ImplicitObjectELResolver());
 }
 
+int adjustedForGraalCount = JspRuntimeLibrary.GRAAL ? count + 1 : 
count;
+
 JasperELResolver resolver =
 new JasperELResolver(list, new StreamELResolverImpl());
 
-
 Assert.assertEquals(Integer.valueOf(count),
 getField("appResolversSize", resolver));
-Assert.assertEquals(9 + count,
+Assert.assertEquals(9 + adjustedForGraalCount,
 ((ELResolver[])getField("resolvers", resolver)).length);
-Assert.assertEquals(Integer.valueOf(9 + count),
+Assert.assertEquals(Integer.valueOf(9 + adjustedForGraalCount),
 Integer.valueOf(((AtomicInteger) getField("resolversSize", 
resolver)).get()));
 }
 


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

[tomcat] branch 9.0.x updated: Minor EL bugs when running under Graal/SubstrateVM

[fhanik]

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

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


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 814f52b  Minor EL bugs when running under Graal/SubstrateVM
814f52b is described below

commit 814f52b4e36b54bec957ccd12354b8b70bc28e69
Author: Filip Hanik 
AuthorDate: Thu Jul 23 12:17:33 2020 -0700

Minor EL bugs when running under Graal/SubstrateVM
---
 java/org/apache/jasper/el/JasperELResolver.java | 4 
 test/org/apache/jasper/el/TestJasperELResolver.java | 8 +---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/java/org/apache/jasper/el/JasperELResolver.java 
b/java/org/apache/jasper/el/JasperELResolver.java
index 99189807..1d72630 100644
--- a/java/org/apache/jasper/el/JasperELResolver.java
+++ b/java/org/apache/jasper/el/JasperELResolver.java
@@ -199,6 +199,7 @@ public class JasperELResolver extends CompositeELResolver {
 if (method != null) {
 context.setPropertyResolved(base, property);
 try {
+method.setAccessible(true);
 value = method.invoke(base, (Object[]) null);
 } catch (Exception ex) {
 Throwable thr = 
ExceptionUtils.unwrapInvocationTargetException(ex);
@@ -211,6 +212,9 @@ public class JasperELResolver extends CompositeELResolver {
 @Override
 public void setValue(ELContext context, Object base, Object property,
 Object value) {
+if (base == null) {
+return;
+}
 Method method = getWriteMethod(base.getClass(), 
property.toString());
 if (method != null) {
 context.setPropertyResolved(base, property);
diff --git a/test/org/apache/jasper/el/TestJasperELResolver.java 
b/test/org/apache/jasper/el/TestJasperELResolver.java
index 948465c..f2eef62 100644
--- a/test/org/apache/jasper/el/TestJasperELResolver.java
+++ b/test/org/apache/jasper/el/TestJasperELResolver.java
@@ -28,6 +28,7 @@ import org.junit.Assert;
 import org.junit.Test;
 
 import org.apache.el.stream.StreamELResolverImpl;
+import org.apache.jasper.runtime.JspRuntimeLibrary;
 
 public class TestJasperELResolver {
 
@@ -53,15 +54,16 @@ public class TestJasperELResolver {
 list.add(new ImplicitObjectELResolver());
 }
 
+int adjustedForGraalCount = JspRuntimeLibrary.GRAAL ? count + 1 : 
count;
+
 JasperELResolver resolver =
 new JasperELResolver(list, new StreamELResolverImpl());
 
-
 Assert.assertEquals(Integer.valueOf(count),
 getField("appResolversSize", resolver));
-Assert.assertEquals(9 + count,
+Assert.assertEquals(9 + adjustedForGraalCount,
 ((ELResolver[])getField("resolvers", resolver)).length);
-Assert.assertEquals(Integer.valueOf(9 + count),
+Assert.assertEquals(Integer.valueOf(9 + adjustedForGraalCount),
 Integer.valueOf(((AtomicInteger) getField("resolversSize", 
resolver)).get()));
 }
 


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

Re: [tomcat] branch master updated: Avoid reflection for default instantiation

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Filip,

On 7/22/20 12:41, Filip Hanik wrote:
> Hi Christopher,
>>> environments. -Class clazz =
>>> Class.forName(className); -return
>>> (AuthConfigFactory) clazz.getConstructor().newInstance(); + if
>>> (className.equals("org.apache.catalina.authenticator.jaspic.AuthConf
ig
>>
>>>
FactoryImpl"))
>>> {
>>
>> Why not use AuthConfigFactoryImpl.class.getName()? It may help in
>> the future with refactoring.
>
> [Filip Hanik] Trying to avoid a circular dependency. You see the
> javax/jakarta package should not import org.apache.catalina code. I
> should be able to execute the AuthConfigFactory code without
> needing to load
> org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl
> class. The JVM is smart enough that if the execution doesn't enter
> the if statement block, it won't attempt the classloading of the
> AuthConfigFactoryImpl class. However, if the AuthConfigFactoryImpl
> Class itself is part of the evaluation statement, it will be
> loaded.
>
> The previous implementation also had it as a string, instead of
> AuthConfigFactoryImpl.class.getName() for the same reason.
> https://github.com/apache/tomcat/blob/35dc7b9288aad4a7d70750c157543d4f
f1593c98/java/jakarta/security/auth/message/config/AuthConfigFactory.jav
a#L48-L49
>
>  This way, I can build a jakarta.security.auth.message library,
> that can be used without the org.apache.catalina library.

That's a very good reason. Thanks for explaining.

> I need to change my commit to use the constant, instead of the
> duplicated string in the IF statement.
>
> if (className.equals(DEFAULT_JASPI_AUTHCONFIGFACTORYIMPL)) { return
> new
> org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl(); }
> else { Class clazz = Class.forName(className); return
> (AuthConfigFactory) clazz.getConstructor().newInstance(); }

:)

- -chris

-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8ZyrUACgkQHPApP6U8
pFghOg//UxcPA7Xm+SKXtyCWEIcabjFkbdHv9o8kOHTiWVSUOrhXLBvTznDKYmYk
+5zFjxsFbBjj1amQnGER/3zJSSJmvdcEUohpHpYHUHFGLh59YyXTVb0ou8PSiX+B
iFEZCqKrkylZPCn21tPXN4wgmnvQxcD9S3++vZBWyCCiQw/BoUYwYGLtg9/sgCjj
eqk2r/yqGRlVtHsMEu04wMadcqpum6f14LO1b8J1C5jP0N9fwiGTEsD4HXskcUfQ
PeDjHtG6tJPXwfYjwRjzZolQIFmQwJ1B6WLufsyw0ZrUVBUENkU4xQwBy3pcVewn
0xc9+vgg+VSXblrDMnoswUBf2hLmfmpw49evcjeKSY7q0G0Fdoe1lUmt+OM74ppK
EZ6qmvCphWtXakyCU5uXx82nQMsNXdwmgLG3Dni4ya79dVoGvn8j3Guh/7g45Jet
0bc7x7KsouqJIbqQAPqdt8E2xKRARsdUE4BH9S0ENkvTqnhhbCWmlxJk3CiPpwoy
3zD5xt9CoXuKX/CjK92hP+nw4b1j+Mdhmwj4whM4FbcvLC6Rq8JXt0obysArweT8
FbfZD45OsWqbgVrVpwcCt19z25+6Ar02DvUz0CkI1sbxzS+hd1yhp2BRbiqTd6HY
EkUodl2R7H95ZmIRZ0QhcnEyq5tPJUcspXLvmzQ5Li25oJEWLrc=
=XYLJ
-END PGP SIGNATURE-

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

[Bug 64621] HTTP/2 Tomcat Server responds with RST_STREAM (REFUSED_STREAM) continuously in one of the TCP connection.

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #5 from Mark Thomas  ---
You have misunderstood the nature of the FIXME. There is no "sync issue" here
that results in streams not being closed.

We have a test case that tests the REFUSED_STREAM state and extending that test
demonstrates that new streams may be sent once the concurrency level falls
below the limit.

For us to investigate further you will need to provide the *minimal* steps to
reproduce this error (with code, scripts etc as required) on a clean install of
the latest Tomcat 9.0.x release.

-- 
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 64621] HTTP/2 Tomcat Server responds with RST_STREAM (REFUSED_STREAM) continuously in one of the TCP connection.

[bugzilla]

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

Raghavendran V  changed:

   What|Removed |Added

 Status|NEEDINFO|NEW

--- Comment #4 from Raghavendran V  ---
It is h2c we are using. 

Also, as this is a pre-production/production, upgrading to the latest version
requires solid evidence to push to the higher version :(. 

Is it possible to check on the corresponding modules on whether this issue is
resolved in 9.0.37? Can you please help on this?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 64621] HTTP/2 Tomcat Server responds with RST_STREAM (REFUSED_STREAM) continuously in one of the TCP connection.

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #3 from Mark Thomas  ---
Please re-test with 9.0.37. There have been many fixes since 9.0.22

Are you using h2 or h2c?

-- 
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 64621] HTTP/2 Tomcat Server responds with RST_STREAM (REFUSED_STREAM) continuously in one of the TCP connection.

[bugzilla]

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

Raghavendran V  changed:

   What|Removed |Added

 Status|NEEDINFO|NEW

--- Comment #2 from Raghavendran V  ---
The current Tomcat version used is 9.0.22, in which we are seeing this issue. I
have also checked the pasted code snippets up-to the latest 9.0.37 version. It
is the same till 9.0.37.

-- 
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 64621] HTTP/2 Tomcat Server responds with RST_STREAM (REFUSED_STREAM) continuously in one of the TCP connection.

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Mark Thomas  ---
Exact Tomcat version being used?

-- 
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: Jakarta EE - JASPIC TCK (nightly)

[Mark Thomas]

Comments in line.

On 22/07/2020 10:19, Jean-Louis MONTEIRO wrote:
> Hi,
> 
> Small update on the progress.
> Passed: 52 and Failed: 9
> 
> I had a lot of random passed/failed for quite a while and finally found
> the reason yesterday.

I took a look at running these myself for Tomcat. There is a lot of
fiddly setup required. I may come back to this but for now I have other
priorities.

> I'd be interested in having some thoughts
> 
> AuthenticatorBase uses by default CallbackHandlerImpl
> 
> The CallbackHandlerImpl will create the GenericPrincipal for the subject
> based on the supported callbacks (CallerPrincipalCallback
> and GroupPrincipalCallback).
> 
> The AuthenticatorBase will pull the GenericPrincipal from the subject
> and do the register.
> 
> Long story short, the TCK calls the CallbackHandlerImpl twice with the
> CallerCallback and another time with CallerCallback + GroupCallback. We
> end up having 2 GenericPrincipal in the subject, one with the name only
> and another one with the name and roles.
> 
> JASPIC
> TCK 
> https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/jaspic/tssv/module/servlet/TSServerAuthModule.java#L371
> 
> See 
> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/authenticator/jaspic/CallbackHandlerImpl.java#L96
> 
> Issue is that AuthenticatorBase pulls the first one available.
> See 
> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/authenticator/AuthenticatorBase.java#L956
> 
> It will randomly pull the GenericPrincipal with the name only or the
> GenericPrincipal with the name and the roles.

Nice find. That must have been a real pain to track down.

I've been reading through the Jakarta Authentication specification (it
should be essentially identical to the previous JASPIC spec).

>From 3.8.3.1

... handle a CallerPrincipalCallback using the clientSubject as argument
to the callback. If more than one module of a context uses the
CallbackHandler to handle this callback, the context is responsible for
coordinating the calls such that the appropriate caller principal value
is established.


context here is referring to ServerAuthContext.

I think, in this case, the ServerAuthContext is being provided by the
TCK so my first impression is that this is a TCK bug.

I think this is worth raising on the Jakarta Authentication mailing lists.

> I did a fork in TomEE of the CallbackHandlerImpl to merge the
> GenericPrincipal in the name is the same and switched the
> CallbackHandlerImpl class in the BasicAuthenticator valve.

Yes, that is the same solution I thought of. Rather than add the newly
created GenericPrincipal to the Subject's private credentials, see if
the new GenericPrincipal has the same name as an existing
GenericPrincipal and if it does merge them.

I'm not sure that would be safe to do in the general case though.

Mark


> 
> Hope it's more or less clear ;-)
> Some thoughts would be very helpfup
> 
> 
> Le ven. 17 juil. 2020 à 18:21, Mark Thomas  > a écrit :
> 
> On 17/07/2020 16:56, Jean-Louis MONTEIRO wrote:
> > Hi,
> >
> > Following up on this thread.
> > Pretty old I know. Haven't seen more recent topics on JASPIC and
> Jakarta
> > EE TCK.
> >
> > I tried to invest some time in TomEE to run the JASPIC TCK which is
> > fully relying on Tomcat.
> > I have counted 68 tests under the package com.sun.ts.tests.jaspic
> >
> > The wiki says 100+ so dunno where I'm missing some.
> >
> > Long story short, after some time configuring the thing, I've got 
> >
> > Passed: 38
> > Failed: 30
> >
> > Anyone looked at it already since Feb 2019?
> 
> I'm probably the most likely candidate and I haven't looked at it.
> 
> Mark
> 
> 
> >
> >
> > Le lun. 11 févr. 2019 à 21:34, Mark Thomas  
> > >> a écrit :
> >
> >     All,
> >
> >     I've started to look at the Jakarta EE JASPIC TCK.
> >
> >     Again a nightly build so usual caveats apply.
> >
> >     Progress is being tracked here:
> >     https://cwiki.apache.org/confluence/display/TOMCAT/JASPIC+TCK
> >
> >     Hmm.
> >
> >     This TCK seems very different to the standalone TCKs for the
> other specs
> >     we implement.
> >     - Deployment is significantly more complex. Rather than just
> WARs there
> >       are some JARS that need to be extracted and rename from EARs.
> >     - It seems to need the RI up and running for the tests.
> >
> >
> >     I'm giving up on this for now. I may come back to it at some
> point but I
> >     think it is more likely that I won't.
> >
> >     Mark
> >
> >   
>  -
> >     To unsubscribe, e-mail: 

[Bug 64621] HTTP/2 Tomcat Server responds with RST_STREAM (REFUSED_STREAM) continuously in one of the TCP connection.

[bugzilla]

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

Raghavendran V  changed:

   What|Removed |Added

 CC||raghavendra...@ericsson.com

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 64621] New: HTTP/2 Tomcat Server responds with RST_STREAM (REFUSED_STREAM) continuously in one of the TCP connection.

[bugzilla]

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

Bug ID: 64621
   Summary: HTTP/2 Tomcat Server responds with RST_STREAM
(REFUSED_STREAM) continuously in one of the TCP
connection.
   Product: Tomcat 9
   Version: 9.0.x
  Hardware: HP
OS: Linux
Status: NEW
  Severity: critical
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: raghavendra...@ericsson.com
  Target Milestone: -

*Sub-Component - Coyote*

*OS : Redhat Linux*

*Description:*

*Setup:*

We have an implementation with Tomcat to transport http/2 packets between 2
systems. 

*Issue reproduction:*

During a load test (with some 1000 requests per second) in the pre-production
systems, we identified some scenarios where our Tomcat server is continuously
replying with a RST_STREAM, with REFUSED_STREAM as the reason, in a single TCP
Connection. 

Even though it is understood that exceeding the number of streams per
connection rejects the new streams with RST_STREAM (REFUSED_STREAM) error as
per Section 5.1.2 and SECTION 8.1.4 of RFC7540. We are not seeing any other
responses sent by the server after sometime. It was only RST_STREAM
(REFUSED_STREAM) errors. For the whole test run period (around 30 minutes), it
was only RST_STREAM in that particular TCP connection.

If the RST_STREAM is sent for exceeded stream count, should it have not
recovered after sometime? 


*Additional Information:*

Also, by looking into the tomcat code base, it was understood that the
RST_STREAM (REFUSED_STREAM) response from tomcat is only possible during an
exceeded stream count and in no other situation (reference given below).

if (localSettings.getMaxConcurrentStreams() <
activeRemoteStreamCount.incrementAndGet()) {
activeRemoteStreamCount.decrementAndGet();
throw new
StreamException(sm.getString("upgradeHandler.tooManyRemoteStreams",
   
Long.toString(localSettings.getMaxConcurrentStreams())),
Http2Error.REFUSED_STREAM, streamId);
}

In addition to this, in the Stream processor code, we noticed a ‘FIXME:’
comment to fix the syncs (reference given below).

final void process(SocketEvent event) {
try {
// FIXME: the regular processor syncs on socketWrapper, but here
this deadlocks
synchronized (this) {
// HTTP/2 equivalent of AbstractConnectionHandler#process()
without the
// socket <-> processor mapping
ContainerThreadMarker.set();
SocketState state = SocketState.CLOSED;
try {
state = process(socketWrapper, event);

if (state == SocketState.CLOSED) {
if (!getErrorState().isConnectionIoAllowed()) {
ConnectionException ce = new
ConnectionException(sm.getString(
"streamProcessor.error.connection",
stream.getConnectionId(),
stream.getIdentifier()),
Http2Error.INTERNAL_ERROR);
stream.close(ce);
} else if (!getErrorState().isIoAllowed()) {
StreamException se = stream.getResetException();
if (se == null) {
se = new StreamException(sm.getString(
"streamProcessor.error.stream",
stream.getConnectionId(),
stream.getIdentifier()),
Http2Error.INTERNAL_ERROR,
stream.getIdAsInt());
}
stream.close(se);
}
}
} catch (Exception e) {
String msg =
sm.getString("streamProcessor.error.connection",
stream.getConnectionId(), stream.getIdentifier());
if (log.isDebugEnabled()) {
log.debug(msg, e);
}
ConnectionException ce = new ConnectionException(msg,
Http2Error.INTERNAL_ERROR);
ce.initCause(e);
stream.close(ce);
} finally {
ContainerThreadMarker.clear();
}
}
} finally {
handler.executeQueuedStream();
}
}

Correlating these two items, if the streams are not closed due to this sync
issue, the activeRemoteStreamCount will be in an increasing trend (as I am
seeing the stream closure only here), Which will result in the REFUSED_STREAM
errors. 

Can you confirm this issue and suggest on whether a fix is available in any of
your working streams? As the system is already in production, it is susceptible
to the issue in 

Re: [tomcat] branch master updated: Simpler way to determine Graal runtime

[Romain Manni-Bucau]

Hmm, for me you have 3 modes:

1. Plain vm -> we dont care
2. Native image generator (
https://github.com/oracle/graal/blob/901ad5cf25d145909d1eca36cbb86765697dcc0b/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/NativeImageGenerator.java#L506
so it is set)
3. Native run -> substitution works

Optional case 4 is the javaagent but this one is not needed normally for
tomcat or is a dev thing so does not need to be implicit (we can set the
property if still used but i suspect once a first flavor is generated it is
no more used and just integrated in tomcat then updated manually).

Do I miss something?

Le jeu. 23 juil. 2020 à 03:02, Filip Hanik  a écrit :

> Hi Romain,
>
> > -Original Message-
> > From: Romain Manni-Bucau 
> > Sent: Wednesday, July 22, 2020 12:48 PM
> > To: Tomcat Developers List 
> > Subject: Re: [tomcat] branch master updated: Simpler way to determine
> Graal
> > runtime
> >
> > Thinking out loud: cant you substitute it to be hardcoded to true in
> native
> > mode? This way you get the best of both.
>
> This works for when you compile it to native code. Remy was talking about
> when running under the Substrate VM as a Java application. That's when I
> experience test failures and prompted me to look into a change.
> If I understand it correctly, the substrate VM doesn't pick up those
> substitutions when running in Java mode.
>
> Filip
>
> >
> > Le mer. 22 juil. 2020 à 20:17, Filip Hanik  >  > a écrit :
> >
> >
> >   Thanks Remy,
> >
> >
> >
> >   I ran into some failures when running the test suite using the
> substrate
> > VM, but it makes more sense to adjust those tests.
> >
> >   I’ll revert these today
> >
> >
> >
> >   Filip
> >
> >
> >
> >   From: Rémy Maucherat  >  >
> > Sent: Wednesday, July 22, 2020 12:10 AM
> >   To: Tomcat Developers List  >  >
> >   Subject: Re: [tomcat] branch master updated: Simpler way to
> > determine Graal runtime
> >
> >
> >
> >   On Tue, Jul 21, 2020 at 11:16 PM  >  > wrote:
> >
> >   This is an automated email from the ASF dual-hosted git
> > repository.
> >
> >   fhanik pushed a commit to branch master
> >   in repository
> > https://gitbox.apache.org/repos/asf/tomcat.git
> >  > o
> > x.apache.org%2Frepos%2Fasf%2Ftomcat.git=02%7C01%7Cfhanik%40v
> > mware.c
> > om%7C5bb8217a67084dc6f0e308d82e791421%7Cb39138ca3cee4b4aa4d6c
> > d83d9dd62f0
> > %7C0%7C0%7C637310444856257107=T20lk9hPTLaJGtrD5ZLD3OVzkC
> > amedtpcKo2
> > V4MwXtg%3D=0>
> >
> >
> >   The following commit(s) were added to refs/heads/master by
> > this push:
> >new 098c4c8  Simpler way to determine Graal runtime
> >   098c4c8 is described below
> >
> >   commit 098c4c81602ba1e8d5f33b0795d7caf55f70d573
> >   Author: Filip Hanik  >  >
> >   AuthorDate: Tue Jul 21 14:04:57 2020 -0700
> >
> >   Simpler way to determine Graal runtime
> >
> >   Also, allows to mock the behavior
> >
> > https://www.graalvm.org/sdk/javadoc/org/graalvm/nativeimage/ImageInfo.h
> > t
> > ml#PROPERTY_IMAGE_CODE_KEY
> >  > w.g
> > raalvm.org%2Fsdk%2Fjavadoc%2Forg%2Fgraalvm%2Fnativeimage%2FImageI
> > nfo.htm
> > l%23PROPERTY_IMAGE_CODE_KEY=02%7C01%7Cfhanik%40vmware.co
> > m%7C5bb8217
> > a67084dc6f0e308d82e791421%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7
> > C0%7C0%7C6
> > 37310444856267104=vHbmuRW5YP1%2B2a6romOsuaxaUHqMqF9G4
> > ob7aXlSYbY%3D
> > =0>
> >   ---
> >java/org/apache/jasper/runtime/JspRuntimeLibrary.java |
> > 16 +---
> >java/org/apache/naming/NamingContext.java |
> > 15 +--
> >java/org/apache/tomcat/util/compat/GraalCompat.java   |
> > 15 +--
> >3 files changed, 3 insertions(+), 43 deletions(-)
> >
> >   diff --git
> > a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> > b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> >   index cfb6e75..f27ce3b 100644
> >   ---
> > a/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> >   +++
> > b/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
> >   @@ -56,21 +56,7 @@ import
> > org.apache.tomcat.InstanceManager;
> > */
> >public class JspRuntimeLibrary {
> >
> >   -public static final boolean GRAAL;
> >   -
> >   -static {
> >   -boolean result = false;
> >   -try {
> >   -Class nativeImageClazz =
> > Class.forName("org.graalvm.nativeimage.ImageInfo");
> > 

[Bug 64614] tomcat doesn't work with JSSE FIPS-compliant with NSS

[bugzilla]

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

--- Comment #13 from jfclere  ---
Something like no alias no wrapping and alias and FIPS warning and no wrapping?

-- 
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