[jira] [Commented] (CXF-7535) Support for Project Reactor as rx()
[ https://issues.apache.org/jira/browse/CXF-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245535#comment-16245535 ] Sergey Beryozkin commented on CXF-7535: --- Hi John, I think we now need to have some of code in rx2.server and reactor.server reused, specifically, StreamingAsyncSubscriber and JsonStreamingAsyncSubscriber are complete duplicates, with rx2.server.AbstractAsyncSubscriber and reactor.server.AsyncSubscriber varying slightly. I'd like to push it all to rt/frontend/jaxrs/ for a start, with rx-common to be introduced at a later stage once there's enough material there. Can you please explain why AbstractAsyncSubscriber and AsyncSubscriber are different ? > Support for Project Reactor as rx() > --- > > Key: CXF-7535 > URL: https://issues.apache.org/jira/browse/CXF-7535 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.2.0 >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 3.2.2 > > > It would be good if Project Reactor was supported as an rx() type in CXF. > https://github.com/apache/cxf/tree/master/rt/rs/extensions/rx - only shows rx > java and rx java 2. project reactor/reactor core seem like the v3's of this > api stack. > https://projectreactor.io/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7535) Support for Project Reactor as rx()
[ https://issues.apache.org/jira/browse/CXF-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245606#comment-16245606 ] John D. Ament commented on CXF-7535: Hi Sergey, I don't believe we can actually de-dupe them. AbstractSubscriber uses the reactor specific subscriber object, whereas AbstractAsyncSubscriber is designed for the RxJava class. So while the implementations of both are very similar, they each rely on the implementation specific subscription. DeafultSubscriber is from RxJava 2, and has no direct equivalent in Reactor. As for why there are subtle differences. In Project Reactor, you have a mono which is always 0/1. It doesn't make sense to send this over the wire as an array type. Likewise, a consumer should only ever try to read this as a single entry. Hence I had to make a small modification to support no prefix/suffix/separator. > Support for Project Reactor as rx() > --- > > Key: CXF-7535 > URL: https://issues.apache.org/jira/browse/CXF-7535 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.2.0 >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 3.2.2 > > > It would be good if Project Reactor was supported as an rx() type in CXF. > https://github.com/apache/cxf/tree/master/rt/rs/extensions/rx - only shows rx > java and rx java 2. project reactor/reactor core seem like the v3's of this > api stack. > https://projectreactor.io/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (CXF-7553) selectVariant doesn't take into account quality factors in Accept header
[
https://issues.apache.org/jira/browse/CXF-7553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy McCright reassigned CXF-7553:
--
Assignee: Andy McCright
> selectVariant doesn't take into account quality factors in Accept header
>
>
> Key: CXF-7553
> URL: https://issues.apache.org/jira/browse/CXF-7553
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.14, 3.2.1
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Minor
> Fix For: 3.1.15, 3.2.2
>
>
> We've got a customer moving from Apache Wink (JAX-RS 1.1) to CXF 3.1.X
> (JAX-RS 2.0) and they are seeing subtle differences in the behavior of the
> javax.ws.rs.core.Request.selectVariant method. According to the spec, the
> returned Variant should be one of the Variants passed in to the selectVariant
> method that is the closest match to the request (based not the Accept,
> Accept-Language, and Accept-Encoding headers). They see this behavior in
> Wink, but in CXF, they see that the first Variant in the passed-in list that
> matches the request's headers is chosen.
> For example, a request with "Accept: a/b, c/d; q=0.5" will return a response
> with "Content-Type: a/b" - assuming that the resource method produces a/b and
> c/d. However, when the user calls:
> List list = new ArrayList();
> Variant v1 = new Variant("a/b", (Locale) null, null);
> Variant v2 = new Variant("c/d", (Locale) null, null);
> Variant v3 = new Variant("not/used", (Locale) null, null);
> list.add(v3);
> list.add(v2);
> list.add(v1);
> assertSame(v1, Request.selectVariant(list));
> the assertion fails. Even though the user prefers a/b over c/d by a quality
> factor of 1 vs 0.5, the selectVariant method returns the Variant with c/d.
> This is because the RequestImpl's implementation of the selectVariant method
> only checks the request headers when intersecting the Mime (Media)Types.
> To match Wink's implementation (and my understanding of the spec, though to
> be fair, the spec is somewhat ambiguous...), I think CXF should take the
> request header's quality factors into account when determining which Variant
> to return.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7535) Support for Project Reactor as rx()
[ https://issues.apache.org/jira/browse/CXF-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245629#comment-16245629 ] Sergey Beryozkin commented on CXF-7535: --- Oh yeah, now I see the difference :-) > Support for Project Reactor as rx() > --- > > Key: CXF-7535 > URL: https://issues.apache.org/jira/browse/CXF-7535 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.2.0 >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 3.2.2 > > > It would be good if Project Reactor was supported as an rx() type in CXF. > https://github.com/apache/cxf/tree/master/rt/rs/extensions/rx - only shows rx > java and rx java 2. project reactor/reactor core seem like the v3's of this > api stack. > https://projectreactor.io/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7535) Support for Project Reactor as rx()
[ https://issues.apache.org/jira/browse/CXF-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245628#comment-16245628 ] Sergey Beryozkin commented on CXF-7535: --- AbstractAsyncSubscriber in rx2.server extends io.reactivex.subscribers.DefaultSubscriber and the one in reactor.server implements org.reactivestreams.Subscriber ? > Support for Project Reactor as rx() > --- > > Key: CXF-7535 > URL: https://issues.apache.org/jira/browse/CXF-7535 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.2.0 >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 3.2.2 > > > It would be good if Project Reactor was supported as an rx() type in CXF. > https://github.com/apache/cxf/tree/master/rt/rs/extensions/rx - only shows rx > java and rx java 2. project reactor/reactor core seem like the v3's of this > api stack. > https://projectreactor.io/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7535) Support for Project Reactor as rx()
[ https://issues.apache.org/jira/browse/CXF-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245632#comment-16245632 ] Sergey Beryozkin commented on CXF-7535: --- The reactor version may work though for rx2, I'll try > Support for Project Reactor as rx() > --- > > Key: CXF-7535 > URL: https://issues.apache.org/jira/browse/CXF-7535 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.2.0 >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 3.2.2 > > > It would be good if Project Reactor was supported as an rx() type in CXF. > https://github.com/apache/cxf/tree/master/rt/rs/extensions/rx - only shows rx > java and rx java 2. project reactor/reactor core seem like the v3's of this > api stack. > https://projectreactor.io/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CXF-7555) Failure to construct bean of {{org.apache.cxf.jaxrs.spring.SpringViewResolverProvider}}
Auke van Leeuwen created CXF-7555:
-
Summary: Failure to construct bean of
{{org.apache.cxf.jaxrs.spring.SpringViewResolverProvider}}
Key: CXF-7555
URL: https://issues.apache.org/jira/browse/CXF-7555
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.2.1
Reporter: Auke van Leeuwen
I'm using the {{cxf-spring-boot-starter-jaxrs}} module in my project that is
exposing a RESTful API. However upgrading from {{3.2.0}} to {{3.2.1}} broke my
application:
{noformat}
***
APPLICATION FAILED TO START
***
Description:
Parameter 1 of constructor in
org.apache.cxf.jaxrs.spring.SpringViewResolverProvider required a bean of type
'org.springframework.web.servlet.LocaleResolver' that could not be found.
- Bean method 'localeResolver' in
'WebMvcAutoConfiguration.WebMvcAutoConfigurationAdapter' not loaded because
@ConditionalOnProperty (spring.mvc.locale) did not find property 'locale'
{noformat}
It seems like {{org.apache.cxf.jaxrs.spring.SpringViewResolverProvider}} was
introduced in {{3.2.1}} but that assumes that I'm *also* using Spring MVC,
which I don't.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7555) Failure to construct bean of org.apache.cxf.jaxrs.spring.SpringViewResolverProvider
[
https://issues.apache.org/jira/browse/CXF-7555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Auke van Leeuwen updated CXF-7555:
--
Summary: Failure to construct bean of
org.apache.cxf.jaxrs.spring.SpringViewResolverProvider (was: Failure to
construct bean of {{org.apache.cxf.jaxrs.spring.SpringViewResolverProvider}})
> Failure to construct bean of
> org.apache.cxf.jaxrs.spring.SpringViewResolverProvider
> ---
>
> Key: CXF-7555
> URL: https://issues.apache.org/jira/browse/CXF-7555
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.1
>Reporter: Auke van Leeuwen
>
> I'm using the {{cxf-spring-boot-starter-jaxrs}} module in my project that is
> exposing a RESTful API. However upgrading from {{3.2.0}} to {{3.2.1}} broke
> my application:
> {noformat}
> ***
> APPLICATION FAILED TO START
> ***
> Description:
> Parameter 1 of constructor in
> org.apache.cxf.jaxrs.spring.SpringViewResolverProvider required a bean of
> type 'org.springframework.web.servlet.LocaleResolver' that could not be found.
> - Bean method 'localeResolver' in
> 'WebMvcAutoConfiguration.WebMvcAutoConfigurationAdapter' not loaded because
> @ConditionalOnProperty (spring.mvc.locale) did not find property 'locale'
> {noformat}
> It seems like {{org.apache.cxf.jaxrs.spring.SpringViewResolverProvider}} was
> introduced in {{3.2.1}} but that assumes that I'm *also* using Spring MVC,
> which I don't.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7555) Failure to construct bean of org.apache.cxf.jaxrs.spring.SpringViewResolverProvider
[
https://issues.apache.org/jira/browse/CXF-7555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245679#comment-16245679
]
Sergey Beryozkin commented on CXF-7555:
---
Hmm, why is that provider loaded, do you have some wild-card scanning enabled ?
> Failure to construct bean of
> org.apache.cxf.jaxrs.spring.SpringViewResolverProvider
> ---
>
> Key: CXF-7555
> URL: https://issues.apache.org/jira/browse/CXF-7555
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.1
>Reporter: Auke van Leeuwen
>
> I'm using the {{cxf-spring-boot-starter-jaxrs}} module in my project that is
> exposing a RESTful API. However upgrading from {{3.2.0}} to {{3.2.1}} broke
> my application:
> {noformat}
> ***
> APPLICATION FAILED TO START
> ***
> Description:
> Parameter 1 of constructor in
> org.apache.cxf.jaxrs.spring.SpringViewResolverProvider required a bean of
> type 'org.springframework.web.servlet.LocaleResolver' that could not be found.
> - Bean method 'localeResolver' in
> 'WebMvcAutoConfiguration.WebMvcAutoConfigurationAdapter' not loaded because
> @ConditionalOnProperty (spring.mvc.locale) did not find property 'locale'
> {noformat}
> It seems like {{org.apache.cxf.jaxrs.spring.SpringViewResolverProvider}} was
> introduced in {{3.2.1}} but that assumes that I'm *also* using Spring MVC,
> which I don't.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7555) Failure to construct bean of org.apache.cxf.jaxrs.spring.SpringViewResolverProvider
[
https://issues.apache.org/jira/browse/CXF-7555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245732#comment-16245732
]
Auke van Leeuwen commented on CXF-7555:
---
No, not that I know. We have a spring boot application which automagically
scans everything below the main spring boot class, but that is in another
package. Next to that I have this configuration in {{application.yml}}:
{noformat}
cxf:
jaxrs:
component-scan: true
classes-scan-packages: app.ourpackage.something
{noformat}
> Failure to construct bean of
> org.apache.cxf.jaxrs.spring.SpringViewResolverProvider
> ---
>
> Key: CXF-7555
> URL: https://issues.apache.org/jira/browse/CXF-7555
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.1
>Reporter: Auke van Leeuwen
>
> I'm using the {{cxf-spring-boot-starter-jaxrs}} module in my project that is
> exposing a RESTful API. However upgrading from {{3.2.0}} to {{3.2.1}} broke
> my application:
> {noformat}
> ***
> APPLICATION FAILED TO START
> ***
> Description:
> Parameter 1 of constructor in
> org.apache.cxf.jaxrs.spring.SpringViewResolverProvider required a bean of
> type 'org.springframework.web.servlet.LocaleResolver' that could not be found.
> - Bean method 'localeResolver' in
> 'WebMvcAutoConfiguration.WebMvcAutoConfigurationAdapter' not loaded because
> @ConditionalOnProperty (spring.mvc.locale) did not find property 'locale'
> {noformat}
> It seems like {{org.apache.cxf.jaxrs.spring.SpringViewResolverProvider}} was
> introduced in {{3.2.1}} but that assumes that I'm *also* using Spring MVC,
> which I don't.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7535) Support for Project Reactor as rx()
[ https://issues.apache.org/jira/browse/CXF-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245740#comment-16245740 ] John D. Ament commented on CXF-7535: There's some definite refactoring that can happen. Its probably not here though, probably a composition pattern to fix it. > Support for Project Reactor as rx() > --- > > Key: CXF-7535 > URL: https://issues.apache.org/jira/browse/CXF-7535 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.2.0 >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 3.2.2 > > > It would be good if Project Reactor was supported as an rx() type in CXF. > https://github.com/apache/cxf/tree/master/rt/rs/extensions/rx - only shows rx > java and rx java 2. project reactor/reactor core seem like the v3's of this > api stack. > https://projectreactor.io/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CXF-7555) Failure to construct bean of org.apache.cxf.jaxrs.spring.SpringViewResolverProvider
[
https://issues.apache.org/jira/browse/CXF-7555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245762#comment-16245762
]
Auke van Leeuwen edited comment on CXF-7555 at 11/9/17 2:51 PM:
I have the following logs related to the wiring of this class:
{noformat}
2017-11-09 15:29:29.443 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.c.e.PropertySourcesPropertyResolver : Could not find key
'cxf.jaxrs.classes-scan' in any property source
2017-11-09 15:29:29.443 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.c.e.PropertySourcesPropertyResolver : Found key 'cxf.jaxrs.component-scan'
in PropertySource 'applicationConfigurationProperties' with value of type
Boolean
2017-11-09 15:29:29.458 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.b.f.s.DefaultListableBeanFactory : Returning cached instance of
singleton bean 'autoConfigurationReport'
2017-11-09 15:29:29.458 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.b.f.s.DefaultListableBeanFactory : Returning cached instance of
singleton bean 'autoConfigurationReport'
2017-11-09 15:29:29.458 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.c.e.PropertySourcesPropertyResolver : Found key 'cxf.jaxrs.component-scan'
in PropertySource 'applicationConfigurationProperties' with value of type
Boolean
2017-11-09 15:29:29.458 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.c.e.PropertySourcesPropertyResolver : Could not find key
'cxf.jaxrs.classes-scan' in any property source
2017-11-09 15:29:29.459 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.b.f.s.DefaultListableBeanFactory : Returning cached instance of
singleton bean 'autoConfigurationReport'
2017-11-09 15:29:29.465 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.c.a.ClassPathBeanDefinitionScanner : JSR-250
'javax.annotation.ManagedBean' found and supported for component scanning
2017-11-09 15:29:29.465 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.c.a.ClassPathBeanDefinitionScanner : JSR-330 'javax.inject.Named'
annotation found and supported for component scanning
2017-11-09 15:29:29.466 DEBUG [payment-service,,,] 98756 --- [ main]
.i.s.PathMatchingResourcePatternResolver : Resolved classpath location
[org/apache/cxf/jaxrs/spring/] to resources [URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/]]
2017-11-09 15:29:29.466 DEBUG [payment-service,,,] 98756 --- [ main]
.i.s.PathMatchingResourcePatternResolver : Looking for matching resources in
jar file
[file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar]
2017-11-09 15:29:29.469 DEBUG [payment-service,,,] 98756 --- [ main]
.i.s.PathMatchingResourcePatternResolver : Resolved location pattern
[classpath*:org/apache/cxf/jaxrs/spring/**/*.class] to resources [URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/AbstractJaxrsClassesScanServer.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/AbstractSpringComponentScanServer.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/AbstractSpringConfigurationFactory.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/JAXRSServerFactoryBeanDefinitionParser$SpringJAXRSServerFactoryBean$1.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/JAXRSServerFactoryBeanDefinitionParser$SpringJAXRSServerFactoryBean.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/JAXRSServerFactoryBeanDefinitionParser.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/JaxRsConfig.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/NamespaceHandler.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/SpringComponentScanServer.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs
[jira] [Resolved] (CXF-7547) Problem to generate Java from WADL file when method id defined
[
https://issues.apache.org/jira/browse/CXF-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-7547.
---
Resolution: Fixed
Assignee: Sergey Beryozkin
Fix Version/s: 3.2.2
3.1.15
I've inlined that id calculation code, should be ok now
> Problem to generate Java from WADL file when method id defined
> ---
>
> Key: CXF-7547
> URL: https://issues.apache.org/jira/browse/CXF-7547
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.14, 3.2.1
> Environment: All Plataforms
>Reporter: Evaristo Wychoski Benfatti
>Assignee: Sergey Beryozkin
>Priority: Minor
> Labels: patch
> Fix For: 3.1.15, 3.2.2
>
>
> The following code base
> {code:java}
> @Path("/baz")
> public class Baz {
> @GET
> @Path("/foo/{id}")
> @Produces("text/plain")
> public String get(@PathParam int id);
> }
> {code}
> generates a similar wadl as follow as result of {{Java2Wadl}} process:
> {code:xml}
> http://wadl.dev.java.net/2009/02";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> When we run after the {{Wadl2Java}} process against previous wadl as input,
> the process takes to the following java definition class as output:
> {code:java}
> @Path("/baz")
> public class Baz {
> @GET
> @Path("/foo/{id}")
> @Produces("text/plain")
> public String getId(@PathParam int id);
> }
> {code}
> According to
> {{tools/wadlto/jaxrs/src/main/java/org/apache/cxf/tools/wadlto/jaxrs/SourceGenerator.java}}
> a wadl method element generates the path as complement to the java method
> name when it does not have an id atribute or when it is the even value of
> name atribute.
> When id is not defined this behavior is right, but when both of atributes are
> defined in order to get the even class used to generate the wadl file as
> result of {{Wadl2Java}} process this is not.
> The solution to enable creating the even code is check if the id is present
> or not at wadl file as follow:
> {code:java}
> // Line 796 instead of this
> if (methodNameLowerCase.equals(genMethodName)) {
> // this code
> if (methodNameLowerCase.equals(genMethodName) && methodNameLowerCase
> == id) {
> {code}
> The above code check if methodNameLowerCase is the even reference of id, only
> in this case, the normal behavior is applied.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7555) Failure to construct bean of org.apache.cxf.jaxrs.spring.SpringViewResolverProvider
[
https://issues.apache.org/jira/browse/CXF-7555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245779#comment-16245779
]
Sergey Beryozkin commented on CXF-7555:
---
does it go inside subpackages as well, say if we push this provider to a
".spring.view" package ?
> Failure to construct bean of
> org.apache.cxf.jaxrs.spring.SpringViewResolverProvider
> ---
>
> Key: CXF-7555
> URL: https://issues.apache.org/jira/browse/CXF-7555
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.1
>Reporter: Auke van Leeuwen
>
> I'm using the {{cxf-spring-boot-starter-jaxrs}} module in my project that is
> exposing a RESTful API. However upgrading from {{3.2.0}} to {{3.2.1}} broke
> my application:
> {noformat}
> ***
> APPLICATION FAILED TO START
> ***
> Description:
> Parameter 1 of constructor in
> org.apache.cxf.jaxrs.spring.SpringViewResolverProvider required a bean of
> type 'org.springframework.web.servlet.LocaleResolver' that could not be found.
> - Bean method 'localeResolver' in
> 'WebMvcAutoConfiguration.WebMvcAutoConfigurationAdapter' not loaded because
> @ConditionalOnProperty (spring.mvc.locale) did not find property 'locale'
> {noformat}
> It seems like {{org.apache.cxf.jaxrs.spring.SpringViewResolverProvider}} was
> introduced in {{3.2.1}} but that assumes that I'm *also* using Spring MVC,
> which I don't.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7555) Failure to construct bean of org.apache.cxf.jaxrs.spring.SpringViewResolverProvider
[
https://issues.apache.org/jira/browse/CXF-7555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245762#comment-16245762
]
Auke van Leeuwen commented on CXF-7555:
---
I have the following logs related to the wiring of this class:
{noformat}
2017-11-09 15:29:29.443 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.c.e.PropertySourcesPropertyResolver : Could not find key
'cxf.jaxrs.classes-scan' in any property source
2017-11-09 15:29:29.443 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.c.e.PropertySourcesPropertyResolver : Found key 'cxf.jaxrs.component-scan'
in PropertySource 'applicationConfigurationProperties' with value of type
Boolean
2017-11-09 15:29:29.458 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.b.f.s.DefaultListableBeanFactory : Returning cached instance of
singleton bean 'autoConfigurationReport'
2017-11-09 15:29:29.458 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.b.f.s.DefaultListableBeanFactory : Returning cached instance of
singleton bean 'autoConfigurationReport'
2017-11-09 15:29:29.458 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.c.e.PropertySourcesPropertyResolver : Found key 'cxf.jaxrs.component-scan'
in PropertySource 'applicationConfigurationProperties' with value of type
Boolean
2017-11-09 15:29:29.458 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.c.e.PropertySourcesPropertyResolver : Could not find key
'cxf.jaxrs.classes-scan' in any property source
2017-11-09 15:29:29.459 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.b.f.s.DefaultListableBeanFactory : Returning cached instance of
singleton bean 'autoConfigurationReport'
2017-11-09 15:29:29.465 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.c.a.ClassPathBeanDefinitionScanner : JSR-250
'javax.annotation.ManagedBean' found and supported for component scanning
2017-11-09 15:29:29.465 DEBUG [payment-service,,,] 98756 --- [ main]
o.s.c.a.ClassPathBeanDefinitionScanner : JSR-330 'javax.inject.Named'
annotation found and supported for component scanning
2017-11-09 15:29:29.466 DEBUG [payment-service,,,] 98756 --- [ main]
.i.s.PathMatchingResourcePatternResolver : Resolved classpath location
[org/apache/cxf/jaxrs/spring/] to resources [URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/]]
2017-11-09 15:29:29.466 DEBUG [payment-service,,,] 98756 --- [ main]
.i.s.PathMatchingResourcePatternResolver : Looking for matching resources in
jar file
[file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar]
2017-11-09 15:29:29.469 DEBUG [payment-service,,,] 98756 --- [ main]
.i.s.PathMatchingResourcePatternResolver : Resolved location pattern
[classpath*:org/apache/cxf/jaxrs/spring/**/*.class] to resources [URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/AbstractJaxrsClassesScanServer.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/AbstractSpringComponentScanServer.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/AbstractSpringConfigurationFactory.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/JAXRSServerFactoryBeanDefinitionParser$SpringJAXRSServerFactoryBean$1.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/JAXRSServerFactoryBeanDefinitionParser$SpringJAXRSServerFactoryBean.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/JAXRSServerFactoryBeanDefinitionParser.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/JaxRsConfig.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/NamespaceHandler.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/SpringComponentScanServer.class],
URL
[jar:file:/Users/avanleeuwen/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/3.2.1/cxf-rt-frontend-jaxrs-3.2.1.jar!/org/apache/cxf/jaxrs/spring/SpringJax
[jira] [Commented] (CXF-7555) Failure to construct bean of org.apache.cxf.jaxrs.spring.SpringViewResolverProvider
[
https://issues.apache.org/jira/browse/CXF-7555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245791#comment-16245791
]
Auke van Leeuwen commented on CXF-7555:
---
Yes, component scanning scans the whole tree 'below' the base package.
> Failure to construct bean of
> org.apache.cxf.jaxrs.spring.SpringViewResolverProvider
> ---
>
> Key: CXF-7555
> URL: https://issues.apache.org/jira/browse/CXF-7555
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.1
>Reporter: Auke van Leeuwen
>
> I'm using the {{cxf-spring-boot-starter-jaxrs}} module in my project that is
> exposing a RESTful API. However upgrading from {{3.2.0}} to {{3.2.1}} broke
> my application:
> {noformat}
> ***
> APPLICATION FAILED TO START
> ***
> Description:
> Parameter 1 of constructor in
> org.apache.cxf.jaxrs.spring.SpringViewResolverProvider required a bean of
> type 'org.springframework.web.servlet.LocaleResolver' that could not be found.
> - Bean method 'localeResolver' in
> 'WebMvcAutoConfiguration.WebMvcAutoConfigurationAdapter' not loaded because
> @ConditionalOnProperty (spring.mvc.locale) did not find property 'locale'
> {noformat}
> It seems like {{org.apache.cxf.jaxrs.spring.SpringViewResolverProvider}} was
> introduced in {{3.2.1}} but that assumes that I'm *also* using Spring MVC,
> which I don't.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7535) Support for Project Reactor as rx()
[ https://issues.apache.org/jira/browse/CXF-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245794#comment-16245794 ] Sergey Beryozkin commented on CXF-7535: --- Updating the abstract subscriber in rx2 be the same as in the reactor case worked just fine, and its extensions do look the same to me, they are not even supposed to work with Mono... To me the only diff seems to be in the Reactive2Invoker vs ReactorInvoker which is fine of course > Support for Project Reactor as rx() > --- > > Key: CXF-7535 > URL: https://issues.apache.org/jira/browse/CXF-7535 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.2.0 >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 3.2.2 > > > It would be good if Project Reactor was supported as an rx() type in CXF. > https://github.com/apache/cxf/tree/master/rt/rs/extensions/rx - only shows rx > java and rx java 2. project reactor/reactor core seem like the v3's of this > api stack. > https://projectreactor.io/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CXF-7556) Get Rx2 and Reactor AsyncSubscriber utility code reused
Sergey Beryozkin created CXF-7556: - Summary: Get Rx2 and Reactor AsyncSubscriber utility code reused Key: CXF-7556 URL: https://issues.apache.org/jira/browse/CXF-7556 Project: CXF Issue Type: Improvement Components: JAX-RS Reporter: Sergey Beryozkin Fix For: 3.2.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (CXF-7556) Get Rx2 and Reactor AsyncSubscriber utility code reused
[ https://issues.apache.org/jira/browse/CXF-7556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin reassigned CXF-7556: - Assignee: Sergey Beryozkin > Get Rx2 and Reactor AsyncSubscriber utility code reused > > > Key: CXF-7556 > URL: https://issues.apache.org/jira/browse/CXF-7556 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 3.2.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7535) Support for Project Reactor as rx()
[ https://issues.apache.org/jira/browse/CXF-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245855#comment-16245855 ] Sergey Beryozkin commented on CXF-7535: --- FYI, https://issues.apache.org/jira/browse/CXF-7556 I've made Rx2Java related code (AbstracAsyncSubscriber -> AbstractSubscriber) the same as in the Reactor one, and now these 3 classes are identical - nothing specific to either RxJava2 or Reactor. I'd like to return to your Flux vs Mono case a bit later but for now I'll just create a shared reactive module which will depend only on reactive streams org API, we have a good start :-) > Support for Project Reactor as rx() > --- > > Key: CXF-7535 > URL: https://issues.apache.org/jira/browse/CXF-7535 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.2.0 >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 3.2.2 > > > It would be good if Project Reactor was supported as an rx() type in CXF. > https://github.com/apache/cxf/tree/master/rt/rs/extensions/rx - only shows rx > java and rx java 2. project reactor/reactor core seem like the v3's of this > api stack. > https://projectreactor.io/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7552) wsdl2java fails on SwA WSDL using SOAP 1.2 Bindings
[
https://issues.apache.org/jira/browse/CXF-7552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245858#comment-16245858
]
Daniel Kulp commented on CXF-7552:
--
I'm not getting that error at all with the attached wsdl and the latest 3.1.14
release.There are other issues that make the attached wsdl invalid, but the
error above is not what I'm seeing at all.
{code}
WSDLToJava Error: Non unique body parts, operation [ echoXML ] and operation [
echoMultipleXML ] in binding
{http://apache.org/xml_attachments}XMLAttachmentPortType_SOAPBinding have the
same body block: {http://apache.org/xml_attachments}doc
{code}
> wsdl2java fails on SwA WSDL using SOAP 1.2 Bindings
> ---
>
> Key: CXF-7552
> URL: https://issues.apache.org/jira/browse/CXF-7552
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13
>Reporter: Russell Orf
> Attachments: xml_attachments.wsdl
>
>
> I'm attempting to create a JAX-WS Web Service client from a SwA WSDL and
> receiving the below error.
> {noformat}
> Loading FrontEnd jaxws ...
> Loading DataBinding jaxb ...
> wsdl2java -client -d /home/rorf/workspace/service-client/.cxftmp/src
> -classdir /home/rorf/workspace/service-client/target/classes -p
> http://apache.org/xml_attachments=org.apache.xml_attachments -impl -validate
> -exsh false -dns true -dex true -wsdlLocation
> file:/home/rorf/workspace/service-client/src/main/resources/xml_attachments.wsdl
> -verbose -defaultValues -fe jaxws -db jaxb -wv 1.1
> file:/home/rorf/workspace/service-client/src/main/resources/xml_attachments.wsdl
> wsdl2java - Apache CXF 3.1.13
> WSDLToJava Error:
> line 40 column 36 of
> file:/home/rorf/workspace/service-client/src/main/resources/xml_attachments.wsdl:
> cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration
> can be found for element 'soap:body'.
> org.apache.cxf.tools.common.ToolException:
> line 40 column 36 of
> file:/home/rorf/workspace/service-client/src/main/resources/xml_attachments.wsdl:
> cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration
> can be found for element 'soap:body'.
> at
> org.apache.cxf.tools.validator.internal.SchemaValidator.validate(SchemaValidator.java:207)
> at
> org.apache.cxf.tools.validator.internal.SchemaValidator.validate(SchemaValidator.java:120)
> at
> org.apache.cxf.tools.validator.internal.SchemaValidator.isValid(SchemaValidator.java:103)
> at
> org.apache.cxf.tools.validator.internal.WSDL11Validator.isValid(WSDL11Validator.java:157)
> at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.validate(JAXWSDefinitionBuilder.java:207)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:204)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:415)
> at
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:185)
> {noformat}
> I've noticed this command succeeds when modifying the WSDL to use the
> namespace for SOAP v1.1 instead of v1.2.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7396) CachedOutputStream doesn't delete temp files
[ https://issues.apache.org/jira/browse/CXF-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245863#comment-16245863 ] Daniel Kulp commented on CXF-7396: -- Would need a test case for this. Everything looks OK with current tests. > CachedOutputStream doesn't delete temp files > > > Key: CXF-7396 > URL: https://issues.apache.org/jira/browse/CXF-7396 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.8 >Reporter: Matthew Roth >Priority: Minor > Fix For: NeedMoreInfo > > > In the CachedOutputStream the method maybeDeleteTempFile doesn't always > delete the temp file when it should. > > this.streamList.remove(stream) > Doesn't remove the stream, occasionally the stream is not in the list causing > the check of this.streamList().isEmpty() to fail. Also occurs when > this.streamList() contains multiple streams. > This seems occur when too many large requests are processed in a row. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CXF-7396) CachedOutputStream doesn't delete temp files
[ https://issues.apache.org/jira/browse/CXF-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-7396: - Fix Version/s: NeedMoreInfo > CachedOutputStream doesn't delete temp files > > > Key: CXF-7396 > URL: https://issues.apache.org/jira/browse/CXF-7396 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.8 >Reporter: Matthew Roth >Priority: Minor > Fix For: NeedMoreInfo > > > In the CachedOutputStream the method maybeDeleteTempFile doesn't always > delete the temp file when it should. > > this.streamList.remove(stream) > Doesn't remove the stream, occasionally the stream is not in the list causing > the check of this.streamList().isEmpty() to fail. Also occurs when > this.streamList() contains multiple streams. > This seems occur when too many large requests are processed in a row. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7527) JAXRS UriInfo.getMatchedUris does return matched URIs twice for sub resources
[
https://issues.apache.org/jira/browse/CXF-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245909#comment-16245909
]
Sergey Beryozkin commented on CXF-7527:
---
[~andymc] Hi Andy, what's your opinion on this one ? thanks
> JAXRS UriInfo.getMatchedUris does return matched URIs twice for sub resources
> -
>
> Key: CXF-7527
> URL: https://issues.apache.org/jira/browse/CXF-7527
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.12
>Reporter: Lenoire
> Attachments: uriinfo-issues.jar
>
>
> Invoking method {{UriInfo.getMatchedURIs()}} return matched resource URI
> twice when invoked from SubResource method.
> See attachment for a junit test reproducing the issue (=>
> {{testMatchedUrisFromSubResource()}})
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7547) Problem to generate Java from WADL file when method id defined
[
https://issues.apache.org/jira/browse/CXF-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245948#comment-16245948
]
Evaristo Wychoski Benfatti commented on CXF-7547:
-
Thanks. Could you please update the PR?
https://github.com/apache/cxf/pull/333
> Problem to generate Java from WADL file when method id defined
> ---
>
> Key: CXF-7547
> URL: https://issues.apache.org/jira/browse/CXF-7547
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.14, 3.2.1
> Environment: All Plataforms
>Reporter: Evaristo Wychoski Benfatti
>Assignee: Sergey Beryozkin
>Priority: Minor
> Labels: patch
> Fix For: 3.1.15, 3.2.2
>
>
> The following code base
> {code:java}
> @Path("/baz")
> public class Baz {
> @GET
> @Path("/foo/{id}")
> @Produces("text/plain")
> public String get(@PathParam int id);
> }
> {code}
> generates a similar wadl as follow as result of {{Java2Wadl}} process:
> {code:xml}
> http://wadl.dev.java.net/2009/02";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> When we run after the {{Wadl2Java}} process against previous wadl as input,
> the process takes to the following java definition class as output:
> {code:java}
> @Path("/baz")
> public class Baz {
> @GET
> @Path("/foo/{id}")
> @Produces("text/plain")
> public String getId(@PathParam int id);
> }
> {code}
> According to
> {{tools/wadlto/jaxrs/src/main/java/org/apache/cxf/tools/wadlto/jaxrs/SourceGenerator.java}}
> a wadl method element generates the path as complement to the java method
> name when it does not have an id atribute or when it is the even value of
> name atribute.
> When id is not defined this behavior is right, but when both of atributes are
> defined in order to get the even class used to generate the wadl file as
> result of {{Wadl2Java}} process this is not.
> The solution to enable creating the even code is check if the id is present
> or not at wadl file as follow:
> {code:java}
> // Line 796 instead of this
> if (methodNameLowerCase.equals(genMethodName)) {
> // this code
> if (methodNameLowerCase.equals(genMethodName) && methodNameLowerCase
> == id) {
> {code}
> The above code check if methodNameLowerCase is the even reference of id, only
> in this case, the normal behavior is applied.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7547) Problem to generate Java from WADL file when method id defined
[
https://issues.apache.org/jira/browse/CXF-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245956#comment-16245956
]
Sergey Beryozkin commented on CXF-7547:
---
Would you like me to close it ?
> Problem to generate Java from WADL file when method id defined
> ---
>
> Key: CXF-7547
> URL: https://issues.apache.org/jira/browse/CXF-7547
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.14, 3.2.1
> Environment: All Plataforms
>Reporter: Evaristo Wychoski Benfatti
>Assignee: Sergey Beryozkin
>Priority: Minor
> Labels: patch
> Fix For: 3.1.15, 3.2.2
>
>
> The following code base
> {code:java}
> @Path("/baz")
> public class Baz {
> @GET
> @Path("/foo/{id}")
> @Produces("text/plain")
> public String get(@PathParam int id);
> }
> {code}
> generates a similar wadl as follow as result of {{Java2Wadl}} process:
> {code:xml}
> http://wadl.dev.java.net/2009/02";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> When we run after the {{Wadl2Java}} process against previous wadl as input,
> the process takes to the following java definition class as output:
> {code:java}
> @Path("/baz")
> public class Baz {
> @GET
> @Path("/foo/{id}")
> @Produces("text/plain")
> public String getId(@PathParam int id);
> }
> {code}
> According to
> {{tools/wadlto/jaxrs/src/main/java/org/apache/cxf/tools/wadlto/jaxrs/SourceGenerator.java}}
> a wadl method element generates the path as complement to the java method
> name when it does not have an id atribute or when it is the even value of
> name atribute.
> When id is not defined this behavior is right, but when both of atributes are
> defined in order to get the even class used to generate the wadl file as
> result of {{Wadl2Java}} process this is not.
> The solution to enable creating the even code is check if the id is present
> or not at wadl file as follow:
> {code:java}
> // Line 796 instead of this
> if (methodNameLowerCase.equals(genMethodName)) {
> // this code
> if (methodNameLowerCase.equals(genMethodName) && methodNameLowerCase
> == id) {
> {code}
> The above code check if methodNameLowerCase is the even reference of id, only
> in this case, the normal behavior is applied.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7547) Problem to generate Java from WADL file when method id defined
[
https://issues.apache.org/jira/browse/CXF-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245966#comment-16245966
]
Evaristo Wychoski Benfatti commented on CXF-7547:
-
Yes, it does not make sense anymore, you have already applied the fix by
another commit.
> Problem to generate Java from WADL file when method id defined
> ---
>
> Key: CXF-7547
> URL: https://issues.apache.org/jira/browse/CXF-7547
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.14, 3.2.1
> Environment: All Plataforms
>Reporter: Evaristo Wychoski Benfatti
>Assignee: Sergey Beryozkin
>Priority: Minor
> Labels: patch
> Fix For: 3.1.15, 3.2.2
>
>
> The following code base
> {code:java}
> @Path("/baz")
> public class Baz {
> @GET
> @Path("/foo/{id}")
> @Produces("text/plain")
> public String get(@PathParam int id);
> }
> {code}
> generates a similar wadl as follow as result of {{Java2Wadl}} process:
> {code:xml}
> http://wadl.dev.java.net/2009/02";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> When we run after the {{Wadl2Java}} process against previous wadl as input,
> the process takes to the following java definition class as output:
> {code:java}
> @Path("/baz")
> public class Baz {
> @GET
> @Path("/foo/{id}")
> @Produces("text/plain")
> public String getId(@PathParam int id);
> }
> {code}
> According to
> {{tools/wadlto/jaxrs/src/main/java/org/apache/cxf/tools/wadlto/jaxrs/SourceGenerator.java}}
> a wadl method element generates the path as complement to the java method
> name when it does not have an id atribute or when it is the even value of
> name atribute.
> When id is not defined this behavior is right, but when both of atributes are
> defined in order to get the even class used to generate the wadl file as
> result of {{Wadl2Java}} process this is not.
> The solution to enable creating the even code is check if the id is present
> or not at wadl file as follow:
> {code:java}
> // Line 796 instead of this
> if (methodNameLowerCase.equals(genMethodName)) {
> // this code
> if (methodNameLowerCase.equals(genMethodName) && methodNameLowerCase
> == id) {
> {code}
> The above code check if methodNameLowerCase is the even reference of id, only
> in this case, the normal behavior is applied.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7547) Problem to generate Java from WADL file when method id defined
[
https://issues.apache.org/jira/browse/CXF-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245980#comment-16245980
]
Sergey Beryozkin commented on CXF-7547:
---
Sure, we'll take care tomorrow. signing off now
> Problem to generate Java from WADL file when method id defined
> ---
>
> Key: CXF-7547
> URL: https://issues.apache.org/jira/browse/CXF-7547
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.14, 3.2.1
> Environment: All Plataforms
>Reporter: Evaristo Wychoski Benfatti
>Assignee: Sergey Beryozkin
>Priority: Minor
> Labels: patch
> Fix For: 3.1.15, 3.2.2
>
>
> The following code base
> {code:java}
> @Path("/baz")
> public class Baz {
> @GET
> @Path("/foo/{id}")
> @Produces("text/plain")
> public String get(@PathParam int id);
> }
> {code}
> generates a similar wadl as follow as result of {{Java2Wadl}} process:
> {code:xml}
> http://wadl.dev.java.net/2009/02";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> When we run after the {{Wadl2Java}} process against previous wadl as input,
> the process takes to the following java definition class as output:
> {code:java}
> @Path("/baz")
> public class Baz {
> @GET
> @Path("/foo/{id}")
> @Produces("text/plain")
> public String getId(@PathParam int id);
> }
> {code}
> According to
> {{tools/wadlto/jaxrs/src/main/java/org/apache/cxf/tools/wadlto/jaxrs/SourceGenerator.java}}
> a wadl method element generates the path as complement to the java method
> name when it does not have an id atribute or when it is the even value of
> name atribute.
> When id is not defined this behavior is right, but when both of atributes are
> defined in order to get the even class used to generate the wadl file as
> result of {{Wadl2Java}} process this is not.
> The solution to enable creating the even code is check if the id is present
> or not at wadl file as follow:
> {code:java}
> // Line 796 instead of this
> if (methodNameLowerCase.equals(genMethodName)) {
> // this code
> if (methodNameLowerCase.equals(genMethodName) && methodNameLowerCase
> == id) {
> {code}
> The above code check if methodNameLowerCase is the even reference of id, only
> in this case, the normal behavior is applied.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7527) JAXRS UriInfo.getMatchedUris does return matched URIs twice for sub resources
[
https://issues.apache.org/jira/browse/CXF-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16246524#comment-16246524
]
Andy McCright commented on CXF-7527:
Hi [~sergey_beryozkin], this looks like a bug to me. I modified the test app a
little and deployed it to Liberty - when I invoked GET
{{http://localhost:9080/CXF7527/my/resource/aValue/subresource}} , I got
{{/my/resource/aValue/subresource/,/my/resource/aValue/subresource,/my/resource/aValue}}
When I ran in the EE8 RI (Glassfish 5 - keep in mind that this is JAX-RS 2.1,
not 2.0, but I don't recall anything changing in the 2.1 spec wrt UriInfo), I
got {{my/resource/aValue/subresource,my/resource/aValue}}
I did a little debugging of UriInfoImpl and it looks like it adds _essentially_
the same path twice. It loops through the MethodInvocationInfos on the stack -
there are two (one for the method on Resource, and one for the SubResource).
The first time through the loop it adds {{/my/resource/aValue}} as the CRI's
URI template - then it adds {{/my/resource/aValue/subresource}} as the ORI's
URI template - it also sets that as the sumPath. The second time through (the
MethodInvocationInfo for SubResource's method), there is no CRI URI template
(so nothing added), but it finds an ORI URI template of "/" (implicit?) that it
appends to the sumPath and then adds it to the List. I think that is wrong -
it should not add the URI that basically is the previous URI plus a "/".
I can try to code up a fix for it.
Thanks, Andy
> JAXRS UriInfo.getMatchedUris does return matched URIs twice for sub resources
> -
>
> Key: CXF-7527
> URL: https://issues.apache.org/jira/browse/CXF-7527
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.12
>Reporter: Lenoire
> Attachments: uriinfo-issues.jar
>
>
> Invoking method {{UriInfo.getMatchedURIs()}} return matched resource URI
> twice when invoked from SubResource method.
> See attachment for a junit test reproducing the issue (=>
> {{testMatchedUrisFromSubResource()}})
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7527) JAXRS UriInfo.getMatchedUris does return matched URIs twice for sub resources
[
https://issues.apache.org/jira/browse/CXF-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16246964#comment-16246964
]
ASF GitHub Bot commented on CXF-7527:
-
andymc12 opened a new pull request #337: [CXF-7527] getMatchedURIs to avoid
duplicate URIs
URL: https://github.com/apache/cxf/pull/337
The UriInfo.getMatchedURIs method currently returns "duplicate" URI
entries when called from a method that is not annotated with an
@Path annotation. The "duplicate" URI is basically the same URI but
with a trailing slash. This was first discovered when using sub
resource locators, but could also occur in simpler scenarios (like
a resource method annotated with @GET but not @Path).
When comparing against the javadoc and the RI, it looks like the
URIs we were returning started with a slash, where the RI and
javadoc examples do not. This commit removes the starting slash as
well.
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
> JAXRS UriInfo.getMatchedUris does return matched URIs twice for sub resources
> -
>
> Key: CXF-7527
> URL: https://issues.apache.org/jira/browse/CXF-7527
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.12
>Reporter: Lenoire
> Attachments: uriinfo-issues.jar
>
>
> Invoking method {{UriInfo.getMatchedURIs()}} return matched resource URI
> twice when invoked from SubResource method.
> See attachment for a junit test reproducing the issue (=>
> {{testMatchedUrisFromSubResource()}})
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
