[Bug 66680] [StandardSession] Misleading warning "Cannot serialize Principal object for session"
https://bz.apache.org/bugzilla/show_bug.cgi?id=66680 --- Comment #4 from Christopher Schultz --- I can do the changelog if you do the PR. -- 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 main updated: Simplify code for allocation of blank arrays
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new a903a28dd1 Simplify code for allocation of blank arrays
a903a28dd1 is described below
commit a903a28dd14055b6537a33904baef875b68678d8
Author: remm
AuthorDate: Thu Jul 20 16:07:36 2023 +0200
Simplify code for allocation of blank arrays
---
.../org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java | 8
.../org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
index c95ae98595..5030c04bb7 100644
---
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
+++
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
@@ -223,7 +223,7 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
long errCode = ERR_get_error();
if (errCode != 0) {
try (var localArena = Arena.ofConfined()) {
-var buf =
localArena.allocateFrom(ValueLayout.JAVA_BYTE, new byte[128]);
+var buf =
localArena.allocate(ValueLayout.JAVA_BYTE, 128);
ERR_error_string(errCode, buf);
log.error(sm.getString("openssl.errorLoadingCertificate", buf.getString(0)));
}
@@ -409,7 +409,7 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
rc = 1;
long errCode = ERR_get_error();
if (errCode != 0) {
-var buf =
localArena.allocateFrom(ValueLayout.JAVA_BYTE, new byte[128]);
+var buf = localArena.allocate(ValueLayout.JAVA_BYTE,
128);
ERR_error_string(errCode, buf);
log.error(sm.getString("opensslconf.checkFailed",
buf.getString(0)));
rc = 0;
@@ -485,7 +485,7 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
localArena.allocateFrom(value));
long errCode = ERR_get_error();
if (rc <= 0 || errCode != 0) {
-var buf =
localArena.allocateFrom(ValueLayout.JAVA_BYTE, new byte[128]);
+var buf = localArena.allocate(ValueLayout.JAVA_BYTE,
128);
ERR_error_string(errCode, buf);
log.error(sm.getString("opensslconf.commandError",
name, value, buf.getString(0)));
rc = 0;
@@ -1309,7 +1309,7 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
private static void logLastError(SegmentAllocator allocator, String
string) {
-var buf = allocator.allocateFrom(ValueLayout.JAVA_BYTE, new byte[128]);
+var buf = allocator.allocate(ValueLayout.JAVA_BYTE, 128);
ERR_error_string(ERR_get_error(), buf);
String err = buf.getString(0);
log.error(sm.getString(string, err));
diff --git
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
index a3b6ce301d..e64dee7409 100644
---
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
+++
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
@@ -1046,7 +1046,7 @@ public final class OpenSSLEngine extends SSLEngine
implements SSLUtil.ProtocolIn
try (var localArena = Arena.ofConfined()) {
do {
// Loop until getLastErrorNumber() returns SSL_ERROR_NONE
-var buf = localArena.allocateFrom(ValueLayout.JAVA_BYTE,
new byte[128]);
+var buf = localArena.allocate(ValueLayout.JAVA_BYTE, 128);
ERR_error_string(error, buf);
String err = buf.getString(0);
if (sslError == null) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: JNDIRealm not retrying connections on NamingException
On Thu, Jul 20, 2023 at 12:30 PM Felix Schumacher wrote: > > > Am 20.07.23 um 11:40 schrieb Rémy Maucherat: > > On Thu, Jul 20, 2023 at 11:11 AM Felix Schumacher > wrote: > > Hi all, > > at work, we have seen the following stacktrace without a retrying log message. > > javax.naming.NamingException: LDAP connection has been closed > at com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:133) > ~[?:1.8.0_342] > at com.sun.jndi.ldap.Connection.readReply(Connection.java:469) > ~[?:1.8.0_342] > at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:638) > ~[?:1.8.0_342] > at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:561) ~[?:1.8.0_342] > at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2013) ~[?:1.8.0_342] > at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1872) ~[?:1.8.0_342] > at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1797) ~[?:1.8.0_342] > at > com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392) > ~[?:1.8.0_342] > at > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) > ~[?:1.8.0_342] > at > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341) > ~[?:1.8.0_342] > at > javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267) > ~[?:1.8.0_342] > at > org.apache.catalina.realm.JNDIRealm.getUserBySearch(JNDIRealm.java:1610) > ~[catalina.jar:9.0.50.redhat-7] > at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1447) > ~[catalina.jar:9.0.50.redhat-7] > at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1376) > ~[catalina.jar:9.0.50.redhat-7] > at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2348) > ~[catalina.jar:9.0.50.redhat-7] > at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2288) > [catalina.jar:9.0.50.redhat-7] > at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2253) > [catalina.jar:9.0.50.redhat-7] > > That happens, because we are catching CommunicationException and > ServiceUnavailableException in getPrincipal instead of the more general > NamingException. > > We had a similar issue in Bug 61313. To fix that bug we changed the catch > clause from CommunicationException to NamingException. > > I think we should change the code in getPrincipal to catch the more general > exception, too. Does anyone know, why we catched those specialized > NamingExceptions instead of the general one? > > I think the rationale was very simple: IO errors are always > recoverable by closing and retrying the connection. Other errors are > "". Now reading your exception it is "NamingException: LDAP > connection has been closed", where it should have been > "CommunicationException: LDAP connection has been closed". This is > unfortunate. > Your proposed change would mean everything is assumed to be > recoverable which is not good, but unavoidable if everything is > reported as a NamingException. > > I read your answer as, "ok, not nice, but let's do it". Pretty much. > And thanks for the explanation. > > But to add to the fun, I looked at the source code of a current OpenJDK > (https://github.com/openjdk/jdk/blob/94eb44b192ba421692549a178c386ea34164ea50/src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java#L115C26-L115C26). > > It looks like we now can expect to even get an IOException in case the LDAP > connection has been closed. Ok, I read the code one level up in Connection.readReply, and the IOException in LdapRequest gets wrapped as a CommunicationException. So the workaround is not needed in Tomcat 11 (trunk) since it requires Java 21. However, Java 17 (and 11 obviously) don't have the fix, so the change is needed in 10.1 and 9.0. Rémy > > Regards > > Felix > > Rémy > > Regards > > Felix > > PS. I will do a PR, if we agree on changing the catch clause. > > PPS. The code to catch the exception is the same in current tomcat JNDIRealm > classes, even if the line numbers changed a bit. > > - > 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: JNDIRealm not retrying connections on NamingException
Am 20.07.23 um 11:40 schrieb Rémy Maucherat: On Thu, Jul 20, 2023 at 11:11 AM Felix Schumacher wrote: Hi all, at work, we have seen the following stacktrace without a retrying log message. javax.naming.NamingException: LDAP connection has been closed at com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:133) ~[?:1.8.0_342] at com.sun.jndi.ldap.Connection.readReply(Connection.java:469) ~[?:1.8.0_342] at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:638) ~[?:1.8.0_342] at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:561) ~[?:1.8.0_342] at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2013) ~[?:1.8.0_342] at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1872) ~[?:1.8.0_342] at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1797) ~[?:1.8.0_342] at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392) ~[?:1.8.0_342] at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) ~[?:1.8.0_342] at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341) ~[?:1.8.0_342] at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267) ~[?:1.8.0_342] at org.apache.catalina.realm.JNDIRealm.getUserBySearch(JNDIRealm.java:1610) ~[catalina.jar:9.0.50.redhat-7] at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1447) ~[catalina.jar:9.0.50.redhat-7] at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1376) ~[catalina.jar:9.0.50.redhat-7] at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2348) ~[catalina.jar:9.0.50.redhat-7] at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2288) [catalina.jar:9.0.50.redhat-7] at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2253) [catalina.jar:9.0.50.redhat-7] That happens, because we are catching CommunicationException and ServiceUnavailableException in getPrincipal instead of the more general NamingException. We had a similar issue in Bug 61313. To fix that bug we changed the catch clause from CommunicationException to NamingException. I think we should change the code in getPrincipal to catch the more general exception, too. Does anyone know, why we catched those specialized NamingExceptions instead of the general one? I think the rationale was very simple: IO errors are always recoverable by closing and retrying the connection. Other errors are "". Now reading your exception it is "NamingException: LDAP connection has been closed", where it should have been "CommunicationException: LDAP connection has been closed". This is unfortunate. Your proposed change would mean everything is assumed to be recoverable which is not good, but unavoidable if everything is reported as a NamingException. I read your answer as, "ok, not nice, but let's do it". And thanks for the explanation. But to add to the fun, I looked at the source code of a current OpenJDK (https://github.com/openjdk/jdk/blob/94eb44b192ba421692549a178c386ea34164ea50/src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java#L115C26-L115C26). It looks like we now can expect to even get an IOException in case the LDAP connection has been closed. Regards Felix Rémy Regards Felix PS. I will do a PR, if we agree on changing the catch clause. PPS. The code to catch the exception is the same in current tomcat JNDIRealm classes, even if the line numbers changed a bit. - To unsubscribe, e-mail:dev-unsubscr...@tomcat.apache.org For additional commands, e-mail:dev-h...@tomcat.apache.org OpenPGP_0xEA6C3728EA91C4AF.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[tomcat] branch main updated: Allocate API changes
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 5f2bf30d66 Allocate API changes
5f2bf30d66 is described below
commit 5f2bf30d66d041af1f149e16a14a88014cf629cb
Author: remm
AuthorDate: Thu Jul 20 12:07:38 2023 +0200
Allocate API changes
---
.../util/net/openssl/panama/OpenSSLContext.java| 56 +++---
.../util/net/openssl/panama/OpenSSLEngine.java | 18 +++
.../openssl/panama/OpenSSLLifecycleListener.java | 14 +++---
.../net/openssl/panama/OpenSSLSessionContext.java | 4 +-
.../apache/tomcat/util/openssl/constants$29.java | 2 +-
5 files changed, 47 insertions(+), 47 deletions(-)
diff --git
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
index 4419bbfe8f..c95ae98595 100644
---
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
+++
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
@@ -223,7 +223,7 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
long errCode = ERR_get_error();
if (errCode != 0) {
try (var localArena = Arena.ofConfined()) {
-var buf =
localArena.allocateArray(ValueLayout.JAVA_BYTE, new byte[128]);
+var buf =
localArena.allocateFrom(ValueLayout.JAVA_BYTE, new byte[128]);
ERR_error_string(errCode, buf);
log.error(sm.getString("openssl.errorLoadingCertificate", buf.getString(0)));
}
@@ -405,11 +405,11 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
if (name.equals("NO_OCSP_CHECK")) {
rc = 1;
} else {
-int code = SSL_CONF_cmd_value_type(state.confCtx,
localArena.allocateString(name));
+int code = SSL_CONF_cmd_value_type(state.confCtx,
localArena.allocateFrom(name));
rc = 1;
long errCode = ERR_get_error();
if (errCode != 0) {
-var buf =
localArena.allocateArray(ValueLayout.JAVA_BYTE, new byte[128]);
+var buf =
localArena.allocateFrom(ValueLayout.JAVA_BYTE, new byte[128]);
ERR_error_string(errCode, buf);
log.error(sm.getString("opensslconf.checkFailed",
buf.getString(0)));
rc = 0;
@@ -481,11 +481,11 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
noOcspCheck = Boolean.valueOf(value);
rc = 1;
} else {
-rc = SSL_CONF_cmd(state.confCtx,
localArena.allocateString(name),
-localArena.allocateString(value));
+rc = SSL_CONF_cmd(state.confCtx,
localArena.allocateFrom(name),
+localArena.allocateFrom(value));
long errCode = ERR_get_error();
if (rc <= 0 || errCode != 0) {
-var buf =
localArena.allocateArray(ValueLayout.JAVA_BYTE, new byte[128]);
+var buf =
localArena.allocateFrom(ValueLayout.JAVA_BYTE, new byte[128]);
ERR_error_string(errCode, buf);
log.error(sm.getString("opensslconf.commandError",
name, value, buf.getString(0)));
rc = 0;
@@ -565,13 +565,13 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
// List the ciphers that the client is permitted to negotiate
if (minTlsVersion <= TLS1_2_VERSION()) {
if (SSL_CTX_set_cipher_list(state.sslCtx,
-localArena.allocateString(sslHostConfig.getCiphers()))
<= 0) {
+localArena.allocateFrom(sslHostConfig.getCiphers()))
<= 0) {
log.warn(sm.getString("engine.failedCipherList",
sslHostConfig.getCiphers()));
}
}
if (maxTlsVersion >= TLS1_3_VERSION() &&
(sslHostConfig.getCiphers() != SSLHostConfig.DEFAULT_TLS_CIPHERS)) {
if (SSL_CTX_set_ciphersuites(state.sslCtx,
-localArena.allocateString(sslHostConfig.getCiphers()))
<= 0) {
+localArena.allocateFrom(sslHostConfig.getCiphers()))
<= 0) {
log.warn(sm.getString("engine.failedCipherSuite",
sslHostConfig.getCiphers()));
}
[GitHub] [tomcat] fmarco76 commented on pull request #639: Custom ssl engine parameters
fmarco76 commented on PR #639: URL: https://github.com/apache/tomcat/pull/639#issuecomment-1643630772 > but it would be an incompatible API change Yes, the API would be slightly different between version 9 and 11. -- 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. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org 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
[Bug 66680] [StandardSession] Misleading warning "Cannot serialize Principal object for session"
https://bz.apache.org/bugzilla/show_bug.cgi?id=66680 --- Comment #3 from Tseko --- Hi (In reply to Christopher Schultz from comment #1) > Seems reasonable. Would you like to prepare a patch/PR for this? > > Please include an entry in the changelog if you do so. I'm not sure how to include an entry in the changelog, could you please do that or point me to a howto for doing 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
[GitHub] [tomcat] rmaucher commented on pull request #639: Custom ssl engine parameters
rmaucher commented on PR #639: URL: https://github.com/apache/tomcat/pull/639#issuecomment-1643614685 > @rmaucher thanks for the merge. I have tested cherry-picking to tomcat 9 and it required a couple of minor fixes to work. Is there something I can do to facilitate the backport? This seems difficult, AbstractJsseEndpoint would be the spot (same for 10.1), but it would be an incompatible API change (so probably not ok), and code written for 11 would not be compatible anyway. -- 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. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org 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
[GitHub] [tomcat] fmarco76 commented on pull request #639: Custom ssl engine parameters
fmarco76 commented on PR #639: URL: https://github.com/apache/tomcat/pull/639#issuecomment-1643609571 @rmaucher thanks for the merge. I have tested cherry-picking to tomcat 9 and it required a couple of minor fixes to work. Is there something I can do to facilitate the backport? -- 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. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org 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
Re: JNDIRealm not retrying connections on NamingException
On Thu, Jul 20, 2023 at 11:11 AM Felix Schumacher wrote: > > Hi all, > > at work, we have seen the following stacktrace without a retrying log message. > > javax.naming.NamingException: LDAP connection has been closed > at com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:133) > ~[?:1.8.0_342] > at com.sun.jndi.ldap.Connection.readReply(Connection.java:469) > ~[?:1.8.0_342] > at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:638) > ~[?:1.8.0_342] > at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:561) ~[?:1.8.0_342] > at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2013) ~[?:1.8.0_342] > at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1872) ~[?:1.8.0_342] > at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1797) ~[?:1.8.0_342] > at > com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392) > ~[?:1.8.0_342] > at > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) > ~[?:1.8.0_342] > at > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341) > ~[?:1.8.0_342] > at > javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267) > ~[?:1.8.0_342] > at > org.apache.catalina.realm.JNDIRealm.getUserBySearch(JNDIRealm.java:1610) > ~[catalina.jar:9.0.50.redhat-7] > at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1447) > ~[catalina.jar:9.0.50.redhat-7] > at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1376) > ~[catalina.jar:9.0.50.redhat-7] > at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2348) > ~[catalina.jar:9.0.50.redhat-7] > at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2288) > [catalina.jar:9.0.50.redhat-7] > at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2253) > [catalina.jar:9.0.50.redhat-7] > > That happens, because we are catching CommunicationException and > ServiceUnavailableException in getPrincipal instead of the more general > NamingException. > > We had a similar issue in Bug 61313. To fix that bug we changed the catch > clause from CommunicationException to NamingException. > > I think we should change the code in getPrincipal to catch the more general > exception, too. Does anyone know, why we catched those specialized > NamingExceptions instead of the general one? I think the rationale was very simple: IO errors are always recoverable by closing and retrying the connection. Other errors are "". Now reading your exception it is "NamingException: LDAP connection has been closed", where it should have been "CommunicationException: LDAP connection has been closed". This is unfortunate. Your proposed change would mean everything is assumed to be recoverable which is not good, but unavoidable if everything is reported as a NamingException. Rémy > > Regards > > Felix > > PS. I will do a PR, if we agree on changing the catch clause. > > PPS. The code to catch the exception is the same in current tomcat JNDIRealm > classes, even if the line numbers changed a bit. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] rmaucher closed pull request #639: Custom ssl engine parameters
rmaucher closed pull request #639: Custom ssl engine parameters URL: https://github.com/apache/tomcat/pull/639 -- 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. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org 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
[GitHub] [tomcat] rmaucher commented on pull request #639: Custom ssl engine parameters
rmaucher commented on PR #639: URL: https://github.com/apache/tomcat/pull/639#issuecomment-1643588616 I merged this change to Tomcat main branch (11). Backporting is not straightforward however as this is an API change stacked on top of a previous API change for Tomcat 11, so the code that uses it would be tied to 11 anyway. -- 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. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org 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 main updated (7e76d04f7d -> a5bcc5f525)
This is an automated email from the ASF dual-hosted git repository. remm pushed a change to branch main in repository https://gitbox.apache.org/repos/asf/tomcat.git from 7e76d04f7d Fix failure trying to persist configuration add a5bcc5f525 Improve extensibility of endpoints No new revisions were added by this update. Summary of changes: .../tomcat/util/net/AbstractNetworkChannelEndpoint.java| 1 + java/org/apache/tomcat/util/net/Nio2Endpoint.java | 13 - java/org/apache/tomcat/util/net/NioEndpoint.java | 14 +- java/org/apache/tomcat/util/net/SecureNio2Channel.java | 9 +++-- java/org/apache/tomcat/util/net/SecureNioChannel.java | 9 +++-- webapps/docs/changelog.xml | 4 6 files changed, 36 insertions(+), 14 deletions(-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
JNDIRealm not retrying connections on NamingException
Hi all, at work, we have seen the following stacktrace without a retrying log message. javax.naming.NamingException: LDAP connection has been closed at com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:133) ~[?:1.8.0_342] at com.sun.jndi.ldap.Connection.readReply(Connection.java:469) ~[?:1.8.0_342] at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:638) ~[?:1.8.0_342] at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:561) ~[?:1.8.0_342] at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2013) ~[?:1.8.0_342] at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1872) ~[?:1.8.0_342] at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1797) ~[?:1.8.0_342] at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392) ~[?:1.8.0_342] at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) ~[?:1.8.0_342] at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341) ~[?:1.8.0_342] at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267) ~[?:1.8.0_342] at org.apache.catalina.realm.JNDIRealm.getUserBySearch(JNDIRealm.java:1610) ~[catalina.jar:9.0.50.redhat-7] at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1447) ~[catalina.jar:9.0.50.redhat-7] at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1376) ~[catalina.jar:9.0.50.redhat-7] at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2348) ~[catalina.jar:9.0.50.redhat-7] at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2288) [catalina.jar:9.0.50.redhat-7] at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2253) [catalina.jar:9.0.50.redhat-7] That happens, because we are catching CommunicationException and ServiceUnavailableException in getPrincipal instead of the more general NamingException. We had a similar issue in Bug 61313. To fix that bug we changed the catch clause from CommunicationException to NamingException. I think we should change the code in getPrincipal to catch the more general exception, too. Does anyone know, why we catched those specialized NamingExceptions instead of the general one? Regards Felix PS. I will do a PR, if we agree on changing the catch clause. PPS. The code to catch the exception is the same in current tomcat JNDIRealm classes, even if the line numbers changed a bit. OpenPGP_0xEA6C3728EA91C4AF.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[GitHub] [tomcat] rmaucher commented on pull request #639: Custom ssl engine parameters
rmaucher commented on PR #639: URL: https://github.com/apache/tomcat/pull/639#issuecomment-1643431249 This proposed change looks good to me. -- 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. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org 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
