[jira] [Commented] (CXF-7670) synthetic methods: equal candidates for handling the current request
[ https://issues.apache.org/jira/browse/CXF-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397497#comment-16397497 ] ASF GitHub Bot commented on CXF-7670: - K0zka commented on issue #388: [CXF-7670] create a single ClassResourceInfo per class + annotated method URL: https://github.com/apache/cxf/pull/388#issuecomment-372787363 . This is an automated message from the Apache Git Service. To respond to the message, please log on 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 > synthetic methods: equal candidates for handling the current request > > > Key: CXF-7670 > URL: https://issues.apache.org/jira/browse/CXF-7670 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.2.1, 3.2.2 > Environment: I have noticed this with kotlin projects. >Reporter: Laszlo Hornyak >Priority: Major > > When discovering JAX-RS annotations, CXF does not filter out synthetic > methods. If the compiler have created any synthetic methods out of the > annotated methods, it will store them as JAX-RS resource methods with > actually the same annotated method. > After startup, CXF will log each invocation on the duplicated resource > methods with a warning, which reduces performance, and generates quite some > log. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7678) Fluent setters support in Beanspector
[ https://issues.apache.org/jira/browse/CXF-7678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397146#comment-16397146 ] ASF GitHub Bot commented on CXF-7678: - scheras opened a new pull request #391: [CXF-7678] Fluent setters support in search extension URL: https://github.com/apache/cxf/pull/391 This is an automated message from the Apache Git Service. To respond to the message, please log on 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 > Fluent setters support in Beanspector > - > > Key: CXF-7678 > URL: https://issues.apache.org/jira/browse/CXF-7678 > Project: CXF > Issue Type: Improvement >Reporter: Simon Schierreich >Priority: Major > > [Beanspector|https://github.com/apache/cxf/blob/master/rt/rs/extensions/search/src/main/java/org/apache/cxf/jaxrs/ext/search/Beanspector.java] > class, which is part of JAX-RS Search extension, currently supports only > setters with void return type. Supporting fluent setters will be really > usefull. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7678) Fluent setters support in Beanspector
Simon Schierreich created CXF-7678: -- Summary: Fluent setters support in Beanspector Key: CXF-7678 URL: https://issues.apache.org/jira/browse/CXF-7678 Project: CXF Issue Type: Improvement Reporter: Simon Schierreich [Beanspector|https://github.com/apache/cxf/blob/master/rt/rs/extensions/search/src/main/java/org/apache/cxf/jaxrs/ext/search/Beanspector.java] class, which is part of JAX-RS Search extension, currently supports only setters with void return type. Supporting fluent setters will be really usefull. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7672) PrimitiveTextProvider: support java.net.URI and java.net.URL
[ https://issues.apache.org/jira/browse/CXF-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Markevich updated CXF-7672: -- Fix Version/s: (was: 3.1.15) 3.1.16 > PrimitiveTextProvider: support java.net.URI and java.net.URL > > > Key: CXF-7672 > URL: https://issues.apache.org/jira/browse/CXF-7672 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.14, 3.2.2 >Reporter: Alexey Markevich >Assignee: Alexey Markevich >Priority: Major > Fix For: 3.2.3, 3.1.16 > > > allow to read/write java.net.URI and java.net.URL as text/plain -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7677) With CXF 3.2.1, using UsernameToken, cannot receive password in callback
[ https://issues.apache.org/jira/browse/CXF-7677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396804#comment-16396804 ] Colm O hEigeartaigh commented on CXF-7677: -- >From WSS4J 1.6.x, the way UsernameToken passwords were validated was changed. >This blog post lays it all out: [http://coheigea.blogspot.ie/2011/02/usernametoken-processing-changes-in.html] Essentially it doesn't pass the password through to the CallbackHandler any more. Instead, the CallbackHandler should supply the password for validation given the username. If you want to do some custom validation then instead you can implement your own WSS4J Validator. > With CXF 3.2.1, using UsernameToken, cannot receive password in callback > > > Key: CXF-7677 > URL: https://issues.apache.org/jira/browse/CXF-7677 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.1 > Environment: Java 8. > CXF 3.2.1 > wss4j-2.1.jar > xmlsec-2.1.0.jar >Reporter: Sumeet Mahajan >Priority: Critical > Attachments: soap-request.xml > > > I am attaching my SOAP request. > It has SOAP Header with usernametoken which also has username and password in > plain text. > I wrote a CallbackHandler to receive this username and password on server. > I used to get the username and password in cxf 2.7.6 in my callbackhandler. > Whereas in cxf 3.2.1 I am no longer getting password. Its coming in as null. > I did follow the new classes (WSPasswordCallback) and changed the package etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7677) With CXF 3.2.1, using UsernameToken, cannot receive password in callback
[ https://issues.apache.org/jira/browse/CXF-7677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-7677. -- Resolution: Not A Problem Assignee: Colm O hEigeartaigh Marking as "Not a Problem". Please use the mailing lists instead if you need further help. > With CXF 3.2.1, using UsernameToken, cannot receive password in callback > > > Key: CXF-7677 > URL: https://issues.apache.org/jira/browse/CXF-7677 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.1 > Environment: Java 8. > CXF 3.2.1 > wss4j-2.1.jar > xmlsec-2.1.0.jar >Reporter: Sumeet Mahajan >Assignee: Colm O hEigeartaigh >Priority: Critical > Attachments: soap-request.xml > > > I am attaching my SOAP request. > It has SOAP Header with usernametoken which also has username and password in > plain text. > I wrote a CallbackHandler to receive this username and password on server. > I used to get the username and password in cxf 2.7.6 in my callbackhandler. > Whereas in cxf 3.2.1 I am no longer getting password. Its coming in as null. > I did follow the new classes (WSPasswordCallback) and changed the package etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CXF-7661) add isTimeout flag for Continutation so that we can easily know when the timeout happen outside CXF
[ https://issues.apache.org/jira/browse/CXF-7661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-7661. > add isTimeout flag for Continutation so that we can easily know when the > timeout happen outside CXF > --- > > Key: CXF-7661 > URL: https://issues.apache.org/jira/browse/CXF-7661 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.1.15, 3.2.3 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CXF-7653) Null pointer in JaxwsResponseCallback
[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-7653.
> Null pointer in JaxwsResponseCallback
> -
>
> Key: CXF-7653
> URL: https://issues.apache.org/jira/browse/CXF-7653
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.10
> Environment: AIX
>Reporter: Neal Johnson
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.1.15, 3.2.3
>
>
> Occasionally we'll get a null pointer in the JAXWS code.
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> When we receive a SOAP message with an empty body (example below) the
> (T)callback.get()[0] line in JaxwsResponseCallback throws a null pointer
> exception. We're still unsure why we're getting a message with an empty body
> in the first place, and if that's AIX related or we're just lucky in other
> operating systems.
> {{http://www.w3.org/2003/05/soap-envelope;>}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
> We did some debugging and checked where our code diverged between the two
> types of messages. The below chunk of code is where it starts to unravel.
> {code:java|title=Code from within
> DocLiteralInInterceptor.java|borderStyle=solid}
> MessageContentsList parameters = new MessageContentsList();
> Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.getBindingOperationInfo();
> boolean client = isRequestor(message);
> //if body is empty and we have BindingOperationInfo, we do not need to match
> //operation anymore, just return
> if (bop != null && !StaxUtils.toNextElement(xmlReader)) {
> // body may be empty for partial response to decoupled request
> return;
> }
> ...
> // Lots of logic
> ...
> message.setContent(List.class, parameters);
> {code}
> ~~~
> When we do a StaxUtils.toNextElement that returns false, as it hits the end
> of the body immediately. This causes it to return without setting the
> MessageContentsList as a list on the message. Later, when the code tries to
> do a .getContent(List) it doesn't find anything, and this leads to it setting
> null as the first element returned on callback.get()[0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CXF-7667) Don't add an STS operation in the DefaultSecurityTokenServiceProvider if no STSProperties are available
[ https://issues.apache.org/jira/browse/CXF-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-7667. > Don't add an STS operation in the DefaultSecurityTokenServiceProvider if no > STSProperties are available > --- > > Key: CXF-7667 > URL: https://issues.apache.org/jira/browse/CXF-7667 > Project: CXF > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Trivial > Fix For: 3.1.15, 3.2.3 > > > If the DefaultSecurityTokenServiceProvider is set up without an STSProperties > Object there will be an exception on the first invocation. Better instead to > log the error and not to add the specific STS operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CXF-6811) org.apache.cxf.common.util.ClassHelper.getJavaVersion() method will fail on JDK9
[
https://issues.apache.org/jira/browse/CXF-6811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-6811.
> org.apache.cxf.common.util.ClassHelper.getJavaVersion() method will fail on
> JDK9
>
>
> Key: CXF-6811
> URL: https://issues.apache.org/jira/browse/CXF-6811
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.1.5
>Reporter: Richard Opalka
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.1.15
>
>
> JDK9 will come with new versioning scheme, see:
> http://openjdk.java.net/jeps/223
> We identified the following snippet of code to be problematic for JDK9
> adoption:
> org.apache.cxf.common.util.ClassHelper
> {code}
> public static double getJavaVersion() {
> String version = System.getProperty("java.version");
> return Double.parseDouble(version.substring(0, 3));
> }
> {code}
> ATM this code fails on:
> Exception in thread "main" java.lang.NumberFormatException: For input string:
> "9-e"
> at
> jdk.internal.math.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2054)
> at
> jdk.internal.math.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
> at java.lang.Double.parseDouble(Double.java:539)
> at
> org.apache.cxf.common.util.ClassHelper.getJavaVersion(ClassHelper.java:90)
> with Early access JDK9.
> Once official JDK9 is released this code will fail on
> StringIndexOutOfBoundsException.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CXF-7522) WSRM - Exponential backoff not configurable for Redelivery
[ https://issues.apache.org/jira/browse/CXF-7522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-7522. > WSRM - Exponential backoff not configurable for Redelivery > -- > > Key: CXF-7522 > URL: https://issues.apache.org/jira/browse/CXF-7522 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.12 >Reporter: Gergan Dimitrov >Assignee: Daniel Kulp >Priority: Critical > Fix For: 3.1.15, 3.2.3 > > > For RedeliverCandidate, the exponential backoff is not configurable - the > hardcoded default value 2 is always used. Please make this value configurable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CXF-7471) WSRM - Use createResendCandidate() instead of constructor directly
[ https://issues.apache.org/jira/browse/CXF-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-7471. > WSRM - Use createResendCandidate() instead of constructor directly > -- > > Key: CXF-7471 > URL: https://issues.apache.org/jira/browse/CXF-7471 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 3.1.12 >Reporter: Gergan Dimitrov >Assignee: Daniel Kulp >Priority: Minor > Fix For: 3.1.15, 3.2.3 > > Original Estimate: 1h > Remaining Estimate: 1h > > In the RetransmissionQueueImpl, cacheUnacknowledged() method, line 350, the > resend candidate is created with constructor directly: > candidate = new ResendCandidate(message); > I see there is a method createResendCandidate, which can be extended, but its > used only for tests. As I need custom logic in the resend candidate, but I > want to reuse the rest of the functionality, it would be good if this method > is used instead of the constructor directly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CXF-7665) Provide an easy way to set the TLSClientParameters on the STSClient client object
[ https://issues.apache.org/jira/browse/CXF-7665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-7665. > Provide an easy way to set the TLSClientParameters on the STSClient client > object > - > > Key: CXF-7665 > URL: https://issues.apache.org/jira/browse/CXF-7665 > Project: CXF > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.1.15, 3.2.3 > > > This task is to provide an easy way to set the TLSClientParameters on the > STSClient client object. If you want to configure TLS in code, then the only > option is to create the STSClient Object and call "getClient()" and set the > TLSClientParameters on the associated HTTPConduit. This works OK for most > use-cases, but not for WS-SecureConversation, which configures the STSClient > in a specific way, which is tricky to reproduce if you are creating the > STSClient manually. > With this fix it'll be possible to call stsClient.setTlsClientParameters(X); -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CXF-7654) Swagger 2 document doesn't contain Info/BasePath on Karaf
[ https://issues.apache.org/jira/browse/CXF-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-7654. > Swagger 2 document doesn't contain Info/BasePath on Karaf > - > > Key: CXF-7654 > URL: https://issues.apache.org/jira/browse/CXF-7654 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.14, 3.2.2 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.1.15, 3.2.3 > > > The Swagger 2 document doesn't contain Info/BasePath when deployed on Karaf > when the endpoint is configured with a basepath of "/services/X". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CXF-7048) Response does not include SequenceAcknowledgement
[ https://issues.apache.org/jira/browse/CXF-7048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-7048. > Response does not include SequenceAcknowledgement > - > > Key: CXF-7048 > URL: https://issues.apache.org/jira/browse/CXF-7048 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.7 > Environment: JBoss EAP 6, Windows 7, Java 7, Visual Studio 12, CXF > 3.1.7 >Reporter: Andy Zhang >Assignee: Daniel Kulp >Priority: Blocker > Fix For: 3.1.15, 3.2.3 > > > I have a CXF web service, deployed to JBoss, and a dot net client. The > deliveryAssurance is AtMostOnce. > When the service is fast and the response includes SequenceAcknowledgement. > But when the service is slow the client usually sends retransmissions. The > response corresponding to the retransmission only includes the > SequenceAcknowledgement. When the request is successfully processed the > response is sent back to client without SequenceAcknowledgement. But the > client expects it always in the response. If the client does not find > SequenceAcknowledgement it returns a fault to the server saying "A reply > message was received with no acknowledgement." The client will keep waiting > till it times out. > Similarly the response of CloseSequence and TerminateSequence do not have > expected SequenceAcknowledgement either. > Could you please always include the SequenceAcknowledgement in the responses > if applicable? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CXF-7652) UriBuilderImpl: null-empty differentiation for query/matrix param
[
https://issues.apache.org/jira/browse/CXF-7652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-7652.
> UriBuilderImpl: null-empty differentiation for query/matrix param
> -
>
> Key: CXF-7652
> URL: https://issues.apache.org/jira/browse/CXF-7652
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Alexey Markevich
>Priority: Major
> Fix For: 3.1.15, 3.2.3
>
>
> UriBuilder.queryParam("q") -> "?q"
> UriBuilder.queryParam("q", "") -> "?q" ; expected "?q="
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CXF-7672) PrimitiveTextProvider: support java.net.URI and java.net.URL
[ https://issues.apache.org/jira/browse/CXF-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-7672. > PrimitiveTextProvider: support java.net.URI and java.net.URL > > > Key: CXF-7672 > URL: https://issues.apache.org/jira/browse/CXF-7672 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.14, 3.2.2 >Reporter: Alexey Markevich >Assignee: Alexey Markevich >Priority: Major > Fix For: 3.1.15, 3.2.3 > > > allow to read/write java.net.URI and java.net.URL as text/plain -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CXF-7508) WSRM - CloseSequenceResponse does not have acknowledgments
[
https://issues.apache.org/jira/browse/CXF-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-7508.
> WSRM - CloseSequenceResponse does not have acknowledgments
> --
>
> Key: CXF-7508
> URL: https://issues.apache.org/jira/browse/CXF-7508
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.1.12
>Reporter: Gergan Dimitrov
>Assignee: Daniel Kulp
>Priority: Blocker
> Fix For: 3.1.15, 3.2.3
>
>
> In the RMOutInterceptor, the addAcknowledgements() method is called, only if
> it is for application message, or explictly required sequence acknowledgment:
> boolean isAck = constants.getSequenceAckAction().equals(action);
> if (isApplicationMessage || isAck) {
> Bu the WSRM specification says that the destination MUST return
> acknowledgment for the received messages, when CloseSequence is received:
> Upon receipt of this message (CloseSequence), or subsequent to the RM
> Destination closing the Sequence of its own volition, the RM Destination MUST
> include a final SequenceAcknowledgement (within which the RM Destination MUST
> include the Final element) header block on any messages associated with the
> Sequence destined to the RM Source, including the CloseSequenceResponse
> message or on any Sequence fault Transmitted to the RM Source.
> CXF does not include final ack neither in CloseSequenceResponse, nor in
> TerminateSequenceResponse (which might not be sent, if client does not
> terminate). Therefore, the ack should be sent immediately to the
> CloseSequenceResponse.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CXF-7672) PrimitiveTextProvider: support java.net.URI and java.net.URL
[ https://issues.apache.org/jira/browse/CXF-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Markevich reassigned CXF-7672: - Assignee: Alexey Markevich > PrimitiveTextProvider: support java.net.URI and java.net.URL > > > Key: CXF-7672 > URL: https://issues.apache.org/jira/browse/CXF-7672 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.14, 3.2.2 >Reporter: Alexey Markevich >Assignee: Alexey Markevich >Priority: Major > Fix For: 3.1.15, 3.2.3 > > > allow to read/write java.net.URI and java.net.URL as text/plain -- This message was sent by Atlassian JIRA (v7.6.3#76005)
