[jira] [Commented] (CXF-7235) MessageSelector is not set in JMSConfiguration due to missing property in JMSEndpoint
[ https://issues.apache.org/jira/browse/CXF-7235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851215#comment-15851215 ] ASF GitHub Bot commented on CXF-7235: - Github user cschneider commented on the issue: https://github.com/apache/cxf/pull/231 No problem. Please also remember to close the PR once the changes are applied unless it auto closes. Btw. If you have changes in your PR you do not need to create a new PR. You can add commits and you can even use git reset to undo several commits, put them into one commit and do a push -f. While this is bad in master it is ok on a branch that only you work on. Christian > MessageSelector is not set in JMSConfiguration due to missing property in > JMSEndpoint > - > > Key: CXF-7235 > URL: https://issues.apache.org/jira/browse/CXF-7235 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.1.4 > Environment: JBoss EAP >Reporter: Michel Meier >Assignee: Christian Schneider >Priority: Minor > Fix For: 3.2.0 > > > Hi, > i was facing the issue, that the messageSelector property for JMSConsumers in > the org.apache.cxf.transport.jms.util.PollingMessageListenerContainer was not > set. After digging in the source it figured out, that the attribute > messageSelector is missing in the class > org.apache.cxf.transport.jms.uri.JMSEndpoint > which is used to map all JMS related properties via > org.apache.cxf.transport.jms.JMSConfigFactory to the property holding class > org.apache.cxf.transport.jms.uri.JMSConfiguration > which is used at the end to register the JMS Consumers > The Solution is to add the propertygessageSelector to class > org.apache.cxf.transport.jms.uri.JMSEndpoint > and add the mapping in org.apache.cxf.transport.jms.JMSConfigFactory -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (FEDIZ-188) Make "Reply" a CallbackType in the Fediz plugin configuration
Colm O hEigeartaigh created FEDIZ-188: - Summary: Make "Reply" a CallbackType in the Fediz plugin configuration Key: FEDIZ-188 URL: https://issues.apache.org/jira/browse/FEDIZ-188 Project: CXF-Fediz Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 1.4.0 Currently, the "Reply" configuration option in the Fediz plugin configuration is a String. However you may wish to set a custom wreply address depending on the request context. Therefore it makes more sense to make it a CallbackType (String or CallbackHandler implementation) to allow pluggable configuration. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (FEDIZ-188) Make "Reply" a CallbackType in the Fediz plugin configuration
[ https://issues.apache.org/jira/browse/FEDIZ-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved FEDIZ-188. --- Resolution: Fixed > Make "Reply" a CallbackType in the Fediz plugin configuration > - > > Key: FEDIZ-188 > URL: https://issues.apache.org/jira/browse/FEDIZ-188 > Project: CXF-Fediz > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 1.4.0 > > > Currently, the "Reply" configuration option in the Fediz plugin configuration > is a String. However you may wish to set a custom wreply address depending on > the request context. Therefore it makes more sense to make it a CallbackType > (String or CallbackHandler implementation) to allow pluggable configuration. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CXF-7237) Upgrade to SpringBoot 1.5.x
[ https://issues.apache.org/jira/browse/CXF-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-7237. --- Resolution: Fixed Assignee: Sergey Beryozkin > Upgrade to SpringBoot 1.5.x > --- > > Key: CXF-7237 > URL: https://issues.apache.org/jira/browse/CXF-7237 > Project: CXF > Issue Type: Improvement > Components: Integration >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 3.2.0 > > > Right now CXF SpringBoot starters depend on SpringBoot 1.4.x and they have > also been updated to make sure they can be run with SpringBoot 1.5.x. > The question is if we should upgrade CXF starters to depend on 1.5.x, i.e, do > we still care if SpringBoot 1.4.x can run CXF starters ? Even if we upgrade > to 1.5.x they can still probably run with 1.4.x given that as far as API > which CXF depends upon has not changed, but it would be worth confirming. > At the moment it appears that we should upgrade to 1.5.x if one of the > following happens: > - 1.5.x users report some other issues blocking them from using CXF starters > currently depending on 1.4.x > - CXF starters gets enhanced to use 1.5.x features > - 1.4.x becomes a legacy SpringBoot branch -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CXF-7241) JAX-RS ContainerRequestContext#setRequestUri() will cause a 404 when Uri contains a query string
[ https://issues.apache.org/jira/browse/CXF-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851853#comment-15851853 ] ASF GitHub Bot commented on CXF-7241: - Github user asfgit closed the pull request at: https://github.com/apache/cxf/pull/234 > JAX-RS ContainerRequestContext#setRequestUri() will cause a 404 when Uri > contains a query string > > > Key: CXF-7241 > URL: https://issues.apache.org/jira/browse/CXF-7241 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.9 >Reporter: Ezequiel Rosas Garcia > > Hi all. > I have a PreMatching filter that attempts to set query parameters using > #setRequestUri(). However, doing this causes CXF to always return 404 and > never set the new query parameters. > Then only exception to this was when the original URI both had no query > parameters and ended without an slash. > I have a little test to show what I mean: > https://github.com/nhtzr/osgiee-web/blob/master/src/test/java/mx/nhtzr/osgiee/web/internal/MyFilterTest.java > I also have a proposed fix: > https://github.com/apache/cxf/pull/234 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CXF-7241) JAX-RS ContainerRequestContext#setRequestUri() will cause a 404 when Uri contains a query string
[ https://issues.apache.org/jira/browse/CXF-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851856#comment-15851856 ] Sergey Beryozkin commented on CXF-7241: --- Thanks for the patch, I've applied it minor updates - the same code should work with another setRequestUri overload, the raw values should be set to preserve the encoded chars if any for JAX-RS Encoded annotations to work, and I only resetting a query if the new one is not null - it is not clear yet if resetting the existing queries with a possible null is expected thanks > JAX-RS ContainerRequestContext#setRequestUri() will cause a 404 when Uri > contains a query string > > > Key: CXF-7241 > URL: https://issues.apache.org/jira/browse/CXF-7241 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.9 >Reporter: Ezequiel Rosas Garcia > > Hi all. > I have a PreMatching filter that attempts to set query parameters using > #setRequestUri(). However, doing this causes CXF to always return 404 and > never set the new query parameters. > Then only exception to this was when the original URI both had no query > parameters and ended without an slash. > I have a little test to show what I mean: > https://github.com/nhtzr/osgiee-web/blob/master/src/test/java/mx/nhtzr/osgiee/web/internal/MyFilterTest.java > I also have a proposed fix: > https://github.com/apache/cxf/pull/234 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (CXF-7241) JAX-RS ContainerRequestContext#setRequestUri() will cause a 404 when Uri contains a query string
[ https://issues.apache.org/jira/browse/CXF-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851856#comment-15851856 ] Sergey Beryozkin edited comment on CXF-7241 at 2/3/17 6:12 PM: --- Thanks for the patch, I've applied it with the minor updates - the same code should work with another setRequestUri overload, the raw values should be set to preserve the encoded chars if any for JAX-RS Encoded annotations to work, and I only resetting a query if the new one is not null - it is not clear yet if resetting the existing queries with a possible null is expected thanks was (Author: sergey_beryozkin): Thanks for the patch, I've applied it minor updates - the same code should work with another setRequestUri overload, the raw values should be set to preserve the encoded chars if any for JAX-RS Encoded annotations to work, and I only resetting a query if the new one is not null - it is not clear yet if resetting the existing queries with a possible null is expected thanks > JAX-RS ContainerRequestContext#setRequestUri() will cause a 404 when Uri > contains a query string > > > Key: CXF-7241 > URL: https://issues.apache.org/jira/browse/CXF-7241 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.9 >Reporter: Ezequiel Rosas Garcia > Fix For: 3.2.0, 3.1.11 > > > Hi all. > I have a PreMatching filter that attempts to set query parameters using > #setRequestUri(). However, doing this causes CXF to always return 404 and > never set the new query parameters. > Then only exception to this was when the original URI both had no query > parameters and ended without an slash. > I have a little test to show what I mean: > https://github.com/nhtzr/osgiee-web/blob/master/src/test/java/mx/nhtzr/osgiee/web/internal/MyFilterTest.java > I also have a proposed fix: > https://github.com/apache/cxf/pull/234 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CXF-7241) JAX-RS ContainerRequestContext#setRequestUri() will cause a 404 when Uri contains a query string
[ https://issues.apache.org/jira/browse/CXF-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-7241. --- Resolution: Fixed Assignee: Sergey Beryozkin Fix Version/s: 3.1.11 3.2.0 > JAX-RS ContainerRequestContext#setRequestUri() will cause a 404 when Uri > contains a query string > > > Key: CXF-7241 > URL: https://issues.apache.org/jira/browse/CXF-7241 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.9 >Reporter: Ezequiel Rosas Garcia >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.11 > > > Hi all. > I have a PreMatching filter that attempts to set query parameters using > #setRequestUri(). However, doing this causes CXF to always return 404 and > never set the new query parameters. > Then only exception to this was when the original URI both had no query > parameters and ended without an slash. > I have a little test to show what I mean: > https://github.com/nhtzr/osgiee-web/blob/master/src/test/java/mx/nhtzr/osgiee/web/internal/MyFilterTest.java > I also have a proposed fix: > https://github.com/apache/cxf/pull/234 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CXF-7242) New cxf-rt-features-logging doesn't log incoming payloads
Daniel Kulp created CXF-7242: Summary: New cxf-rt-features-logging doesn't log incoming payloads Key: CXF-7242 URL: https://issues.apache.org/jira/browse/CXF-7242 Project: CXF Issue Type: Bug Components: logging Affects Versions: 3.1.10 Reporter: Daniel Kulp Assignee: Daniel Kulp The LoggingInInterceptor in the logging feature cannot log the payload. It runs in the PRE_INVOKE phase at which point the entire content stream is consumed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
