[JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC
by David Hanisch (JIRA)
[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plug... ]
David Hanisch edited comment on SECURITY-921 at 3/18/16 12:46 PM:
------------------------------------------------------------------
I observed the same issue. The first mech in mechList is not the only accepted "Kerberos V5". I agree the proposed patch is not correct since the provided mechToken is related to the first mech in list (defined this way by RFC).
There should be a new challenge to the browser with "Kerbors V5" as mech. I had a detailed look on it and found there is not. The next challenge is again a "Negotiate" without any token.
Seems to me the reason is here in NegotiationMechanism.java (line 122):
} finally {
negContext.clear();
}
This clears the perfectly prepared negTokenTarg from SPNEGOLoginModule.java.
When I change this to
} finally {
{color:#f79232} if (!negContext.isContinuationRequired()) {{color}
negContext.clear();
{color:#f79232} }{color}
}
then the the 401 contains this token and there is another GET from the browser mit mech "Kerberos V5" and the authentication succeeds.
One more thing:
I would like to comment on something in SPNEGOLoginModule.java what I think is not quite correct:
if( ({color:#f79232}(NegTokenTarg){color}negotiationContext.getResponseMessage()).getNegResult() != NegTokenTarg.REJECTED ) {
The response message is not necessarily a NegTokenTarg, may also be a Kerberos message.
I changed the if-then-elst to just:
return super.loginOk;
and added setContinuationRequired() in AcceptSecContext.run() where needed:
negotiationContext.setResponseMessage(negTokenTarg);
{color:#f79232}negotiationContext.setContinuationRequired(kerberosSupported);{color}
return Boolean.FALSE;
...
if (gssContext.isEstablished() == false)
{
{color:#f79232}negotiationContext.setContinuationRequired(true);{color}
return Boolean.FALSE;
...
catch (Exception e)
{
{color:#f79232}negotiationContext.setContinuationRequired(false);{color}
return e;
was (Author: dhanisch):
I observed the same issue. The first mech in mechList is not the only accepted "Kerberos V5". I agree the proposed patch is not correct since the proviced mechToken is related to the first mech in list (defined this way by RFC).
There should be a new challenge to the browser with "Kerbors V5" as mech. I had a detailed look on it and found there is not. The next challenge is again a "Negotiate" without any token.
Seems to me the reason is here in NegotiationMechanism.java (line 122):
} finally {
negContext.clear();
}
This clears the perfectly prepared negTokenTarg from SPNEGOLoginModule.java.
When I change this to
} finally {
{color:#f79232} if (!negContext.isContinuationRequired()) {{color}
negContext.clear();
{color:#f79232} }{color}
}
then the the 401 contains this token and there is another GET from the browser mit mech "Kerberos V5" and the authentication succeeds.
One more thing:
I would like to comment on something in SPNEGOLoginModule.java what I think is not quite correct:
if( ({color:#f79232}(NegTokenTarg){color}negotiationContext.getResponseMessage()).getNegResult() != NegTokenTarg.REJECTED ) {
The response message is not necessarily a NegTokenTarg, may also be a Kerberos message.
I changed the if-then-elst to just:
return super.loginOk;
and added setContinuationRequired() in AcceptSecContext.run() where needed:
negotiationContext.setResponseMessage(negTokenTarg);
{color:#f79232}negotiationContext.setContinuationRequired(kerberosSupported);{color}
return Boolean.FALSE;
...
if (gssContext.isEstablished() == false)
{
{color:#f79232}negotiationContext.setContinuationRequired(true);{color}
return Boolean.FALSE;
...
catch (Exception e)
{
{color:#f79232}negotiationContext.setContinuationRequired(false);{color}
return e;
> SPNEGO authentication fails on Windows-KDC
> ------------------------------------------
>
> Key: SECURITY-921
> URL: https://issues.jboss.org/browse/SECURITY-921
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_3_0_0_CR1
> Environment: *
> Reporter: Harald Krause
> Assignee: Darran Lofthouse
> Labels: web_security
>
> Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list:
> {code:java}
> if (mechList.get(0).equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> }
> else
> {
> boolean kerberosSupported = false;
> ...
> {code}
> But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids):
> * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5)
> * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for)
> * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx
> * oid: 1.3.6.1.4.1.311.2.2.10 NTLM
> So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid:
> {code:java}
> for (Oid oid : mechList)
> {
> if (oid.equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> break;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-428) HTTP Mechanism configuration during deployment
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-428?page=com.atlassian.jira.plugin.sy... ]
Pedro Igor edited comment on ELY-428 at 3/18/16 12:46 PM:
----------------------------------------------------------
Wouldn't the deployer be specific to Keycloak-SSO subsystem and to the Console SSO Use Case ?
My point is not really specific to WFLY but to any web container we support in elytron-web.
Beside that, IIRC, elytron-keycloak will replace Keycloak WildFly/Undertow Adapters once we have ELY fully integrated with the application server. Which will provide a much better integration with the server and solely based on ELY APIs. In this case, we must be able to support a eager approach to initialization.
I've in my session notes a minor change to the {{HttpServerAuthenticationMechanismFactory}} to allow the factory to put things in the application scope (such as the config) during the configuration of the security handler. So we could just grab these things from authentication mechanisms when actually evaluating a request.
was (Author: pcraveiro):
Wouldn't the deployer be specific to Keycloak-SSO subsystem and to the Console SSO Use Case ?
My point is not really specific to WFLY but to any web container we support in elytron-web.
Beside that, IIRC, elytron-keycloak will replace Keycloak WildFly/Undertow Adapters once we have ELY fully integrated with the application server. Which will provide a much better integration with the server and solely based on ELY APIs. In this case, we must be able to support a eager approach to initialization.
I've in my session notes a minor change to the ```HttpServerAuthenticationMechanismFactory``` to allow the factory to put things in the application scope (such as the config) during the configuration of the security handler. So we could just grab these things from authentication mechanisms when actually evaluating a request.
> HTTP Mechanism configuration during deployment
> ----------------------------------------------
>
> Key: ELY-428
> URL: https://issues.jboss.org/browse/ELY-428
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Affects Versions: 1.0.2.Final
> Reporter: Pedro Igor
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.Beta5
>
>
> It should be possible to configure a HTTP mechanism during deployment in order to parse/load configuration and reuse it in subsequent requests to an application.
> The most common use case for that is around mechanisms that need to read some configuration from inside a deployment (or provided by the mech config) when it is being deployed to the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-428) HTTP Mechanism configuration during deployment
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-428?page=com.atlassian.jira.plugin.sy... ]
Pedro Igor commented on ELY-428:
--------------------------------
Wouldn't the deployer be specific to Keycloak-SSO subsystem and to the Console SSO Use Case ?
My point is not really specific to WFLY but to any web container we support in elytron-web.
Beside that, IIRC, elytron-keycloak will replace Keycloak WildFly/Undertow Adapters once we have ELY fully integrated with the application server. Which will provide a much better integration with the server and solely based on ELY APIs. In this case, we must be able to support a eager approach to initialization.
I've in my session notes a minor change to the ```HttpServerAuthenticationMechanismFactory``` to allow the factory to put things in the application scope (such as the config) during the configuration of the security handler. So we could just grab these things from authentication mechanisms when actually evaluating a request.
> HTTP Mechanism configuration during deployment
> ----------------------------------------------
>
> Key: ELY-428
> URL: https://issues.jboss.org/browse/ELY-428
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Affects Versions: 1.0.2.Final
> Reporter: Pedro Igor
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.Beta5
>
>
> It should be possible to configure a HTTP mechanism during deployment in order to parse/load configuration and reuse it in subsequent requests to an application.
> The most common use case for that is around mechanisms that need to read some configuration from inside a deployment (or provided by the mech config) when it is being deployed to the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC
by David Hanisch (JIRA)
[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plug... ]
David Hanisch commented on SECURITY-921:
----------------------------------------
I observed the same issue. The first mech in mechList is not the only accepted "Kerberos V5". I agree the proposed patch is not correct since the proviced mechToken is related to the first mech in list (defined this way by RFC).
There should be a new challenge to the browser with "Kerbors V5" as mech. I had a detailed look on it and found there is not. The next challenge is again a "Negotiate" without any token.
Seems to me the reason is here in NegotiationMechanism.java (line 122):
} finally {
negContext.clear();
}
This clears the perfectly prepared negTokenTarg from SPNEGOLoginModule.java.
When I change this to
} finally {
{color:#f79232} if (!negContext.isContinuationRequired()) {{color}
negContext.clear();
{color:#f79232} }{color}
}
then the the 401 contains this token and there is another GET from the browser mit mech "Kerberos V5" and the authentication succeeds.
One more thing:
I would like to comment on something in SPNEGOLoginModule.java what I think is not quite correct:
if( ({color:#f79232}(NegTokenTarg){color}negotiationContext.getResponseMessage()).getNegResult() != NegTokenTarg.REJECTED ) {
The response message is not necessarily a NegTokenTarg, may also be a Kerberos message.
I changed the if-then-elst to just:
return super.loginOk;
and added setContinuationRequired() in AcceptSecContext.run() where needed:
negotiationContext.setResponseMessage(negTokenTarg);
{color:#f79232}negotiationContext.setContinuationRequired(kerberosSupported);{color}
return Boolean.FALSE;
...
if (gssContext.isEstablished() == false)
{
{color:#f79232}negotiationContext.setContinuationRequired(true);{color}
return Boolean.FALSE;
...
catch (Exception e)
{
{color:#f79232}negotiationContext.setContinuationRequired(false);{color}
return e;
> SPNEGO authentication fails on Windows-KDC
> ------------------------------------------
>
> Key: SECURITY-921
> URL: https://issues.jboss.org/browse/SECURITY-921
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_3_0_0_CR1
> Environment: *
> Reporter: Harald Krause
> Assignee: Darran Lofthouse
> Labels: web_security
>
> Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list:
> {code:java}
> if (mechList.get(0).equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> }
> else
> {
> boolean kerberosSupported = false;
> ...
> {code}
> But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids):
> * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5)
> * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for)
> * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx
> * oid: 1.3.6.1.4.1.311.2.2.10 NTLM
> So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid:
> {code:java}
> for (Oid oid : mechList)
> {
> if (oid.equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> break;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-428) HTTP Mechanism configuration during deployment
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-428?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-428:
--------------------------------------
For that situation when on WildFly we said you would write a deployer that can handle that processing in advance.
> HTTP Mechanism configuration during deployment
> ----------------------------------------------
>
> Key: ELY-428
> URL: https://issues.jboss.org/browse/ELY-428
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Affects Versions: 1.0.2.Final
> Reporter: Pedro Igor
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.Beta5
>
>
> It should be possible to configure a HTTP mechanism during deployment in order to parse/load configuration and reuse it in subsequent requests to an application.
> The most common use case for that is around mechanisms that need to read some configuration from inside a deployment (or provided by the mech config) when it is being deployed to the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6319) NPE in LocalEjbReceiver.removeClusterNodes during server shutdown
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6319?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-6319 at 3/18/16 11:43 AM:
---------------------------------------------------------------------
Hi Dimitii
I've been trying to find out why this NPE is occurring in the first place. It can certainly happen if the EJBClientContext which holds the cluster contexts being removed has already been closed (any request to get a cluster context returns null), but i'm not sure if or how that can happen yet.
I suspect it is related to the fact that we do not clean up stale cluster contexts in EJBClientContexts when a cluster is entirely removed in LocalEJBReceiver.registryRemoved(). I think this may be the source of the problem and should probably be fixed as it was in VersionOneProtocolChannelReceiver.
was (Author: rachmato):
Hi Dimitii
I've been trying to find out why this NPE is occurring in the first place. It can certainly happen of the EJBClientContext which holds the cluster contexts being removed has already been closed (any request to get a cluster context returns null), but i'm not sure if or how that can happen yet.
I suspect it is related to the fact that we do not clean up stale cluster contexts in EJBClientContexts when a cluster is entirely, removed in LocalEJBReceiver.registryRemoved(). I think this may be the source of the problem and should probably be fixed as it was in VersionOneProtocolChannelReceiver.
> NPE in LocalEjbReceiver.removeClusterNodes during server shutdown
> -----------------------------------------------------------------
>
> Key: WFLY-6319
> URL: https://issues.jboss.org/browse/WFLY-6319
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Ladislav Thon
> Assignee: Dmitrii Tikhomirov
>
> In a failover test that passivates sessions to a SQL database (though I think this isn't really relevant much), I've seen a NPE in {{LocalEjbReceiver.removeClusterNodes}}:
> {code}
> 04:09:29,330 WARN [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000004: Failure during stop of service jboss.ejb3.localEjbReceiver.value: java.lang.NullPointerException
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.removeClusterNodes(LocalEjbReceiver.java:701)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.disassociate(LocalEjbReceiver.java:681)
> at org.jboss.ejb.client.EJBClientContext.unregisterEJBReceiver(EJBClientContext.java:446)
> at org.jboss.ejb.client.EJBReceiverContext.close(EJBReceiverContext.java:57)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.stop(LocalEjbReceiver.java:410)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> This happens during server shutdown, so it probably doesn't affect anything.
> Logs:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-db-s...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-db-s...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6319) NPE in LocalEjbReceiver.removeClusterNodes during server shutdown
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6319?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-6319 at 3/18/16 11:43 AM:
---------------------------------------------------------------------
Hi Dimitii
I've been trying to find out why this NPE is occurring in the first place. It can certainly happen if the EJBClientContext which holds the cluster contexts being removed has already been closed (any request to get a cluster context returns null), but i'm not sure if or how that can happen yet.
I suspect it is related to the fact that we do not clean up stale cluster contexts in EJBClientContexts when a cluster is entirely removed in LocalEJBReceiver.registryRemoved(). I think this may be the source of the problem and should probably be fixed as it was in VersionOneProtocolChannelReceiver.
But its only a guess and needs to be confirmed.
was (Author: rachmato):
Hi Dimitii
I've been trying to find out why this NPE is occurring in the first place. It can certainly happen if the EJBClientContext which holds the cluster contexts being removed has already been closed (any request to get a cluster context returns null), but i'm not sure if or how that can happen yet.
I suspect it is related to the fact that we do not clean up stale cluster contexts in EJBClientContexts when a cluster is entirely removed in LocalEJBReceiver.registryRemoved(). I think this may be the source of the problem and should probably be fixed as it was in VersionOneProtocolChannelReceiver.
> NPE in LocalEjbReceiver.removeClusterNodes during server shutdown
> -----------------------------------------------------------------
>
> Key: WFLY-6319
> URL: https://issues.jboss.org/browse/WFLY-6319
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Ladislav Thon
> Assignee: Dmitrii Tikhomirov
>
> In a failover test that passivates sessions to a SQL database (though I think this isn't really relevant much), I've seen a NPE in {{LocalEjbReceiver.removeClusterNodes}}:
> {code}
> 04:09:29,330 WARN [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000004: Failure during stop of service jboss.ejb3.localEjbReceiver.value: java.lang.NullPointerException
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.removeClusterNodes(LocalEjbReceiver.java:701)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.disassociate(LocalEjbReceiver.java:681)
> at org.jboss.ejb.client.EJBClientContext.unregisterEJBReceiver(EJBClientContext.java:446)
> at org.jboss.ejb.client.EJBReceiverContext.close(EJBReceiverContext.java:57)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.stop(LocalEjbReceiver.java:410)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> This happens during server shutdown, so it probably doesn't affect anything.
> Logs:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-db-s...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-db-s...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6319) NPE in LocalEjbReceiver.removeClusterNodes during server shutdown
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6319?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-6319:
-------------------------------------------
Hi Dimitii
I've been trying to find out why this NPE is occurring in the first place. It can certainly happen of the EJBClientContext which holds the cluster contexts being removed has already been closed (any request to get a cluster context returns null), but i'm not sure if or how that can happen yet.
I suspect it is related to the fact that we do not clean up stale cluster contexts in EJBClientContexts when a cluster is entirely, removed in LocalEJBReceiver.registryRemoved(). I think this may be the source of the problem and should probably be fixed as it was in VersionOneProtocolChannelReceiver.
> NPE in LocalEjbReceiver.removeClusterNodes during server shutdown
> -----------------------------------------------------------------
>
> Key: WFLY-6319
> URL: https://issues.jboss.org/browse/WFLY-6319
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Ladislav Thon
> Assignee: Dmitrii Tikhomirov
>
> In a failover test that passivates sessions to a SQL database (though I think this isn't really relevant much), I've seen a NPE in {{LocalEjbReceiver.removeClusterNodes}}:
> {code}
> 04:09:29,330 WARN [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000004: Failure during stop of service jboss.ejb3.localEjbReceiver.value: java.lang.NullPointerException
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.removeClusterNodes(LocalEjbReceiver.java:701)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.disassociate(LocalEjbReceiver.java:681)
> at org.jboss.ejb.client.EJBClientContext.unregisterEJBReceiver(EJBClientContext.java:446)
> at org.jboss.ejb.client.EJBReceiverContext.close(EJBReceiverContext.java:57)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.stop(LocalEjbReceiver.java:410)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> This happens during server shutdown, so it probably doesn't affect anything.
> Logs:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-db-s...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-db-s...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JGRP-2032) TOA logs too much at DEBUG level
by Dan Berindei (JIRA)
Dan Berindei created JGRP-2032:
----------------------------------
Summary: TOA logs too much at DEBUG level
Key: JGRP-2032
URL: https://issues.jboss.org/browse/JGRP-2032
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.8
Reporter: Dan Berindei
Assignee: Bela Ban
Priority: Minor
Sent/delivered messages should only be logged at TRACE level, not DEBUG.
Exceptions should be logged at WARN level (or maybe ERROR), regardless of the current logging level.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month