[jira] [Created] (CXF-8367) Micrometer always reports OUTCOME=UNKNOWN
Stefan Berger created CXF-8367:
--
Summary: Micrometer always reports OUTCOME=UNKNOWN
Key: CXF-8367
URL: https://issues.apache.org/jira/browse/CXF-8367
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime
Affects Versions: 3.4.1
Reporter: Stefan Berger
When I use the new MetricsFeature introduced in CXF-8213, the metrics look like
this in positive cases:
{code:java}
cxf_server_requests_seconds_count{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
1.0
cxf_server_requests_seconds_sum{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
0.221690028
{code}
In this case, Message.RESPONSE_CODE is null when the
MetricsMessageOutInterceptor is called.
In success cases, this Message attribute is set in the
MessageSenderEndingInterceptor when
AbstractHTTPDestination.getResponseCodeFromMessage() is called.
MetricsMessageOutInterceptor is called before that interceptor, that's why
Message.RESPONSE_CODE is not set.
There are 2 solution options, as far as I understand:
# Move the MetricsMessageOutInterceptor after the
MessageSenderEndingInterceptor (the consequences of that are unknown to me)
# Adjust the StandardTags.status() method to treat null values as 200
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CXF-8367) Micrometer always reports OUTCOME=UNKNOWN
[
https://issues.apache.org/jira/browse/CXF-8367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Berger updated CXF-8367:
---
Description:
When I use the new MetricsFeature introduced in CXF-8213, the metrics look like
this in positive cases:
{code:java}
cxf_server_requests_seconds_count{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
1.0
cxf_server_requests_seconds_sum{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
0.221690028
{code}
In this case, Message.RESPONSE_CODE is null when the
MetricsMessageOutInterceptor is called.
In success cases, this Message attribute is set in the
MessageSenderEndingInterceptor when
AbstractHTTPDestination.getResponseCodeFromMessage() is called.
MetricsMessageOutInterceptor is called before that interceptor, that's why
Message.RESPONSE_CODE is not set.
There are 2 solution options, as far as I understand:
# Move the MetricsMessageOutInterceptor after the
MessageSenderEndingInterceptor (the consequences of that are unknown to me)
# Adjust the StandardTags.status() method to treat null values as 200
There's also another problem of the faultCode being LOGICAL_RUNTIME_FAULT in my
success cases. This is because the MAPAggregatorImpl always calls
exchange.setOutFaultMessage(). The code inside of
JaxwsFaultCodeProvider.getFaultCode() assumes that ex.getOutFaultMessage() !=
null indicates a Fault.
was:
When I use the new MetricsFeature introduced in CXF-8213, the metrics look like
this in positive cases:
{code:java}
cxf_server_requests_seconds_count{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
1.0
cxf_server_requests_seconds_sum{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
0.221690028
{code}
In this case, Message.RESPONSE_CODE is null when the
MetricsMessageOutInterceptor is called.
In success cases, this Message attribute is set in the
MessageSenderEndingInterceptor when
AbstractHTTPDestination.getResponseCodeFromMessage() is called.
MetricsMessageOutInterceptor is called before that interceptor, that's why
Message.RESPONSE_CODE is not set.
There are 2 solution options, as far as I understand:
# Move the MetricsMessageOutInterceptor after the
MessageSenderEndingInterceptor (the consequences of that are unknown to me)
# Adjust the StandardTags.status() method to treat null values as 200
> Micrometer always reports OUTCOME=UNKNOWN
> -
>
> Key: CXF-8367
> URL: https://issues.apache.org/jira/browse/CXF-8367
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.4.1
>Reporter: Stefan Berger
>Priority: Major
>
> When I use the new MetricsFeature introduced in CXF-8213, the metrics look
> like this in positive cases:
> {code:java}
> cxf_server_requests_seconds_count{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
> 1.0
> cxf_server_requests_seconds_sum{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
> 0.221690028
> {code}
> In this case, Message.RESPONSE_CODE is null when the
> MetricsMessageOutInterceptor is called.
> In success cases, this Message attribute is set in the
> MessageSenderEndingInterceptor when
> AbstractHTTPDestination.getResponseCodeFromMessage() is called.
> MetricsMessageOutInterceptor is called before that interceptor, that's why
> Message.RESPONSE_CODE is not set.
> There are 2 solution options, as far as I understand:
> # Move the MetricsMessageOutInterceptor after the
> MessageSenderEndingInterceptor (the consequences of that are unknown to me)
> # Adjust the StandardTags.status() method to treat null values as 200
>
> There's also another problem of the faultCode being LOGICAL_RUNTIME_FAULT in
> my success cases. This is because the MAPAggregatorImpl always calls
> exchange.setOutFaultMessage(). The code inside of
> JaxwsFaultCodeProvider.getFaultCode() assumes that ex.getOutFaultMessage() !=
> null indicates a Fault.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CXF-8367) Micrometer always reports outcome=UNKNOWN on success cases
[
https://issues.apache.org/jira/browse/CXF-8367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Berger updated CXF-8367:
---
Summary: Micrometer always reports outcome=UNKNOWN on success cases (was:
Micrometer always reports OUTCOME=UNKNOWN)
> Micrometer always reports outcome=UNKNOWN on success cases
> --
>
> Key: CXF-8367
> URL: https://issues.apache.org/jira/browse/CXF-8367
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.4.1
>Reporter: Stefan Berger
>Priority: Major
>
> When I use the new MetricsFeature introduced in CXF-8213, the metrics look
> like this in positive cases:
> {code:java}
> cxf_server_requests_seconds_count{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
> 1.0
> cxf_server_requests_seconds_sum{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
> 0.221690028
> {code}
> In this case, Message.RESPONSE_CODE is null when the
> MetricsMessageOutInterceptor is called.
> In success cases, this Message attribute is set in the
> MessageSenderEndingInterceptor when
> AbstractHTTPDestination.getResponseCodeFromMessage() is called.
> MetricsMessageOutInterceptor is called before that interceptor, that's why
> Message.RESPONSE_CODE is not set.
> There are 2 solution options, as far as I understand:
> # Move the MetricsMessageOutInterceptor after the
> MessageSenderEndingInterceptor (the consequences of that are unknown to me)
> # Adjust the StandardTags.status() method to treat null values as 200
>
> There's also another problem of the faultCode being LOGICAL_RUNTIME_FAULT in
> my success cases. This is because the MAPAggregatorImpl always calls
> exchange.setOutFaultMessage(). The code inside of
> JaxwsFaultCodeProvider.getFaultCode() assumes that ex.getOutFaultMessage() !=
> null indicates a Fault.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CXF-8365) LoggingInInterceptor could not be extended / logs only once
[
https://issues.apache.org/jira/browse/CXF-8365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229450#comment-17229450
]
Freeman Yue Fang commented on CXF-8365:
---
Hi [~cachescrubber],
No, we can't do it.
The expected default behaviour of LoggingInInterceptor is that it should print
incoming message once and only once, no matter the incoming message is legal or
not. Currently it works as expected.
If you have any other different requirements, you can always extends your own
LoggingInInterceptor.
Best Regards
Freeman
> LoggingInInterceptor could not be extended / logs only once
> ---
>
> Key: CXF-8365
> URL: https://issues.apache.org/jira/browse/CXF-8365
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime, logging
>Affects Versions: 3.4.0
>Reporter: Lars Uffmann
>Assignee: Freeman Yue Fang
>Priority: Major
>
> Coming with CXF-8257 {{org.apache.cxf.ext.logging.LoggingInInterceptor}} will
> log a given message only once:
> {code:java}
> public void handleMessage(Message message) throws Fault {
> if (isLoggingDisabledNow(message)) {
> return;
> } else {
> //ensure only logging once for a certain message
> //this can prevent message logging again when fault
> //happen after PRE_INVOKE phase(rewind calls into
> LoggingInFaultInterceptor)
> message.put(LIVE_LOGGING_PROP, Boolean.FALSE);
> }
> {code}
> Filtering is done per message, not per Interceptor instance. We use a custom
> {{MyLoggingInInterceptor}} which subclasses the {{LoggingInInterceptor}}. (We
> Subclass in order to use different {{LogEventSender).}} So two distinct
> interceptor instances are applied to the Endpoint/Bus/Client but the message
> is logged only in the first invocation.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CXF-8365) LoggingInInterceptor could not be extended / logs only once
[
https://issues.apache.org/jira/browse/CXF-8365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang resolved CXF-8365.
---
Resolution: Information Provided
> LoggingInInterceptor could not be extended / logs only once
> ---
>
> Key: CXF-8365
> URL: https://issues.apache.org/jira/browse/CXF-8365
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime, logging
>Affects Versions: 3.4.0
>Reporter: Lars Uffmann
>Assignee: Freeman Yue Fang
>Priority: Major
>
> Coming with CXF-8257 {{org.apache.cxf.ext.logging.LoggingInInterceptor}} will
> log a given message only once:
> {code:java}
> public void handleMessage(Message message) throws Fault {
> if (isLoggingDisabledNow(message)) {
> return;
> } else {
> //ensure only logging once for a certain message
> //this can prevent message logging again when fault
> //happen after PRE_INVOKE phase(rewind calls into
> LoggingInFaultInterceptor)
> message.put(LIVE_LOGGING_PROP, Boolean.FALSE);
> }
> {code}
> Filtering is done per message, not per Interceptor instance. We use a custom
> {{MyLoggingInInterceptor}} which subclasses the {{LoggingInInterceptor}}. (We
> Subclass in order to use different {{LogEventSender).}} So two distinct
> interceptor instances are applied to the Endpoint/Bus/Client but the message
> is logged only in the first invocation.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CXF-8368) org.apache.cxf.rs.security.oauth2.services.AuthorizationCodeGrantService#createAuthorizationData wrongly sets code_challenge
Romain Manni-Bucau created CXF-8368: --- Summary: org.apache.cxf.rs.security.oauth2.services.AuthorizationCodeGrantService#createAuthorizationData wrongly sets code_challenge Key: CXF-8368 URL: https://issues.apache.org/jira/browse/CXF-8368 Project: CXF Issue Type: Bug Affects Versions: 3.4.1 Reporter: Romain Manni-Bucau org.apache.cxf.rs.security.oauth2.services.AuthorizationCodeGrantService#createAuthorizationData sets code challenge after parent createAuthorizationData which calls org.apache.cxf.rs.security.oauth2.services.RedirectionBasedGrantService#createAuthorizationData which calls org.apache.cxf.rs.security.oauth2.provider.JoseSessionTokenProvider#createSessionToken (when used) so the state will be created before the challenge is set which breaks the flow. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CXF-8369) [oauth2] code_challenge_method not forwarded
Romain Manni-Bucau created CXF-8369: --- Summary: [oauth2] code_challenge_method not forwarded Key: CXF-8369 URL: https://issues.apache.org/jira/browse/CXF-8369 Project: CXF Issue Type: Bug Affects Versions: 3.4.1 Reporter: Romain Manni-Bucau code_challenge_method should be forwarded in state > AuthorizationCodeRegistration > ServerAuthorizationCodeGrant to enable to automatically find the CodeVerifierTransformer to use instead of hardcoding it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CXF-8370) org.apache.cxf.rs.security.oauth2.services.RedirectionBasedGrantService#startAuthorization(javax.ws.rs.core.MultivaluedMap) shouldn't req
Romain Manni-Bucau created CXF-8370: --- Summary: org.apache.cxf.rs.security.oauth2.services.RedirectionBasedGrantService#startAuthorization(javax.ws.rs.core.MultivaluedMap) shouldn't require an user Key: CXF-8370 URL: https://issues.apache.org/jira/browse/CXF-8370 Project: CXF Issue Type: Bug Affects Versions: 3.4.1 Reporter: Romain Manni-Bucau Currently starting an authorization_code flow requires an UserContext because of org.apache.cxf.rs.security.oauth2.services.RedirectionBasedGrantService#getAndValidateSecurityContext but if it is required then you can never login (until you use 2 auth methods). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CXF-8367) Micrometer always reports outcome=UNKNOWN on success cases
[
https://issues.apache.org/jira/browse/CXF-8367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-8367:
-
Assignee: Andriy Redko
> Micrometer always reports outcome=UNKNOWN on success cases
> --
>
> Key: CXF-8367
> URL: https://issues.apache.org/jira/browse/CXF-8367
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.4.1
>Reporter: Stefan Berger
>Assignee: Andriy Redko
>Priority: Major
>
> When I use the new MetricsFeature introduced in CXF-8213, the metrics look
> like this in positive cases:
> {code:java}
> cxf_server_requests_seconds_count{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
> 1.0
> cxf_server_requests_seconds_sum{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
> 0.221690028
> {code}
> In this case, Message.RESPONSE_CODE is null when the
> MetricsMessageOutInterceptor is called.
> In success cases, this Message attribute is set in the
> MessageSenderEndingInterceptor when
> AbstractHTTPDestination.getResponseCodeFromMessage() is called.
> MetricsMessageOutInterceptor is called before that interceptor, that's why
> Message.RESPONSE_CODE is not set.
> There are 2 solution options, as far as I understand:
> # Move the MetricsMessageOutInterceptor after the
> MessageSenderEndingInterceptor (the consequences of that are unknown to me)
> # Adjust the StandardTags.status() method to treat null values as 200
>
> There's also another problem of the faultCode being LOGICAL_RUNTIME_FAULT in
> my success cases. This is because the MAPAggregatorImpl always calls
> exchange.setOutFaultMessage(). The code inside of
> JaxwsFaultCodeProvider.getFaultCode() assumes that ex.getOutFaultMessage() !=
> null indicates a Fault.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CXF-8367) Micrometer always reports outcome=UNKNOWN on success cases
[
https://issues.apache.org/jira/browse/CXF-8367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229664#comment-17229664
]
Andriy Redko commented on CXF-8367:
---
Thanks for the issue, [~bergers] , I think for the response code, the 2nd
option would be a trivial fix. Regarding faultCode & MAPAggregatorImpl, it is
not clear yet what would be the appropriate change but we'll look into it,
thank you.
> Micrometer always reports outcome=UNKNOWN on success cases
> --
>
> Key: CXF-8367
> URL: https://issues.apache.org/jira/browse/CXF-8367
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.4.1
>Reporter: Stefan Berger
>Assignee: Andriy Redko
>Priority: Major
>
> When I use the new MetricsFeature introduced in CXF-8213, the metrics look
> like this in positive cases:
> {code:java}
> cxf_server_requests_seconds_count{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
> 1.0
> cxf_server_requests_seconds_sum{exception="None",faultCode="LOGICAL_RUNTIME_FAULT",method="POST",operation="operation1",outcome="UNKNOWN",status="UNKNOWN",uri="/myendpoint",}
> 0.221690028
> {code}
> In this case, Message.RESPONSE_CODE is null when the
> MetricsMessageOutInterceptor is called.
> In success cases, this Message attribute is set in the
> MessageSenderEndingInterceptor when
> AbstractHTTPDestination.getResponseCodeFromMessage() is called.
> MetricsMessageOutInterceptor is called before that interceptor, that's why
> Message.RESPONSE_CODE is not set.
> There are 2 solution options, as far as I understand:
> # Move the MetricsMessageOutInterceptor after the
> MessageSenderEndingInterceptor (the consequences of that are unknown to me)
> # Adjust the StandardTags.status() method to treat null values as 200
>
> There's also another problem of the faultCode being LOGICAL_RUNTIME_FAULT in
> my success cases. This is because the MAPAggregatorImpl always calls
> exchange.setOutFaultMessage(). The code inside of
> JaxwsFaultCodeProvider.getFaultCode() assumes that ex.getOutFaultMessage() !=
> null indicates a Fault.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CXF-8365) LoggingInInterceptor could not be extended / logs only once
[
https://issues.apache.org/jira/browse/CXF-8365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229762#comment-17229762
]
Lars Uffmann commented on CXF-8365:
---
Hello [~ffang] ,
??The expected default behaviour of LoggingInInterceptor is that it should
print incoming message once and only once??
I do not argue that requirement. But the way it is actually implemented
prevents more then one instance of LoggingInInterceptor to log the message,
even when they use different LogEventSender implementations and are added to
the interceptor chain up on purpose. Just think about it one more time. Is my
latest code snippet is not a legitimate usage of LoggingInInterceptor, which
should be supported? Anyway, thanks for your time and patience.
Regards,
Lars
> LoggingInInterceptor could not be extended / logs only once
> ---
>
> Key: CXF-8365
> URL: https://issues.apache.org/jira/browse/CXF-8365
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime, logging
>Affects Versions: 3.4.0
>Reporter: Lars Uffmann
>Assignee: Freeman Yue Fang
>Priority: Major
>
> Coming with CXF-8257 {{org.apache.cxf.ext.logging.LoggingInInterceptor}} will
> log a given message only once:
> {code:java}
> public void handleMessage(Message message) throws Fault {
> if (isLoggingDisabledNow(message)) {
> return;
> } else {
> //ensure only logging once for a certain message
> //this can prevent message logging again when fault
> //happen after PRE_INVOKE phase(rewind calls into
> LoggingInFaultInterceptor)
> message.put(LIVE_LOGGING_PROP, Boolean.FALSE);
> }
> {code}
> Filtering is done per message, not per Interceptor instance. We use a custom
> {{MyLoggingInInterceptor}} which subclasses the {{LoggingInInterceptor}}. (We
> Subclass in order to use different {{LogEventSender).}} So two distinct
> interceptor instances are applied to the Endpoint/Bus/Client but the message
> is logged only in the first invocation.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
