[jira] [Created] (CXF-7561) CrossOriginResourceSharing annotation on a super interface is not interpreted
Valer Micle created CXF-7561:
Summary: CrossOriginResourceSharing annotation on a super
interface is not interpreted
Key: CXF-7561
URL: https://issues.apache.org/jira/browse/CXF-7561
Project: CXF
Issue Type: Bug
Components: JAX-RS Security
Affects Versions: 3.1.14
Reporter: Valer Micle
Hi,
I have multiple endpoints and I would like to apply the same CORS configuration
for all services.
What I've done is to create a root interface like this:
{code}
@CrossOriginResourceSharing(
allowAllOrigins = true,
allowCredentials = true,
maxAge = 1209600,
allowHeaders = {"X-HTTP-Method-Override"},
exposeHeaders = {"X-Total-Count"}
)
public interface CorsEnabledService {
}
{code}
and then I've extended on all my actual services this interface:
{code}
@Path("/example1")
public interface ExampleService extends CorsEnabledService {
@GET
@Path("/")
@Produces({MediaType.APPLICATION_JSON})
Response getResults();
}
@Path("/example2")
public interface SecondExampleService extends CorsEnabledService {
@GET
@Path("/")
@Produces({MediaType.APPLICATION_JSON})
Response getSecondResults();
}
{code}
This is not working and I have to duplicate the cors related annotation
everywhere.
Isn't this supposed to work? It will be awesome to have it working.
I see this as a bug since defining common annotations is quite a common
practice and I would expect this to work.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251196#comment-16251196
]
Sergey Beryozkin commented on CXF-7544:
---
Hi Andriy,
Can you please first check if a CDIClassUnwrapper idea works as suggested by
John ?
FYI, in case of Spring proxies, I've been always recommending users to simply
create an interface, example, with the code above in mind, it would be
something like this:
{code:java}
interface Injectable {
@Context
public setResourceInfo(ResourceInfo resourceInfo);
}
public class BookStoreRequestFilter implements ContainerRequestFilter,
Injectable {
private ResourceInfo resourceInfo;
public setResourceInfo(ResourceInfo resourceInfo) {
this.resourceInfo = resourceInfo;
}
}
{code}
and it has always worked, the interface are always retained during the
proxification. Can you try this as well ?
Seeing a POC branch would be interesting :-), and indeed having the CXF JAX-RS
itself not to deal with the injection 'manually' would be nice, though I agree
it is the kind of change that perhaps should go to the next/new CXF master
Thanks
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251196#comment-16251196
]
Sergey Beryozkin edited comment on CXF-7544 at 11/14/17 10:26 AM:
--
Hi Andriy,
Can you please first check if a CDIClassUnwrapper idea works as suggested by
John ?
FYI, in case of Spring proxies, I've been always recommending users to simply
create an interface, example, with the code above in mind, it would be
something like this:
{code:java}
interface Injectable {
@Context
public setResourceInfo(ResourceInfo resourceInfo);
}
public class BookStoreRequestFilter implements ContainerRequestFilter,
Injectable {
private ResourceInfo resourceInfo;
public setResourceInfo(ResourceInfo resourceInfo) {
this.resourceInfo = resourceInfo;
}
}
{code}
and it has always worked, the interfaces are always retained during the
proxification. Can you try this as well ?
Seeing a POC branch would be interesting :-), and indeed having the CXF JAX-RS
itself not to deal with the injection 'manually' would be nice, though I agree
it is the kind of change that perhaps should go to the next/new CXF master
Thanks
was (Author: sergey_beryozkin):
Hi Andriy,
Can you please first check if a CDIClassUnwrapper idea works as suggested by
John ?
FYI, in case of Spring proxies, I've been always recommending users to simply
create an interface, example, with the code above in mind, it would be
something like this:
{code:java}
interface Injectable {
@Context
public setResourceInfo(ResourceInfo resourceInfo);
}
public class BookStoreRequestFilter implements ContainerRequestFilter,
Injectable {
private ResourceInfo resourceInfo;
public setResourceInfo(ResourceInfo resourceInfo) {
this.resourceInfo = resourceInfo;
}
}
{code}
and it has always worked, the interface are always retained during the
proxification. Can you try this as well ?
Seeing a POC branch would be interesting :-), and indeed having the CXF JAX-RS
itself not to deal with the injection 'manually' would be nice, though I agree
it is the kind of change that perhaps should go to the next/new CXF master
Thanks
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of C
[jira] [Updated] (CXF-7561) CrossOriginResourceSharing annotation on a super interface is not interpreted
[
https://issues.apache.org/jira/browse/CXF-7561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated CXF-7561:
--
Fix Version/s: 3.2.2
3.1.15
> CrossOriginResourceSharing annotation on a super interface is not interpreted
> -
>
> Key: CXF-7561
> URL: https://issues.apache.org/jira/browse/CXF-7561
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS Security
>Affects Versions: 3.1.14
>Reporter: Valer Micle
> Fix For: 3.1.15, 3.2.2
>
>
> Hi,
> I have multiple endpoints and I would like to apply the same CORS
> configuration for all services.
> What I've done is to create a root interface like this:
> {code}
> @CrossOriginResourceSharing(
> allowAllOrigins = true,
> allowCredentials = true,
> maxAge = 1209600,
> allowHeaders = {"X-HTTP-Method-Override"},
> exposeHeaders = {"X-Total-Count"}
> )
> public interface CorsEnabledService {
> }
> {code}
> and then I've extended on all my actual services this interface:
> {code}
> @Path("/example1")
> public interface ExampleService extends CorsEnabledService {
> @GET
> @Path("/")
> @Produces({MediaType.APPLICATION_JSON})
> Response getResults();
> }
> @Path("/example2")
> public interface SecondExampleService extends CorsEnabledService {
> @GET
> @Path("/")
> @Produces({MediaType.APPLICATION_JSON})
> Response getSecondResults();
> }
> {code}
> This is not working and I have to duplicate the cors related annotation
> everywhere.
> Isn't this supposed to work? It will be awesome to have it working.
> I see this as a bug since defining common annotations is quite a common
> practice and I would expect this to work.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CXF-7562) ext.logging: truncated flag not set
Franz Forsthofer created CXF-7562: - Summary: ext.logging: truncated flag not set Key: CXF-7562 URL: https://issues.apache.org/jira/browse/CXF-7562 Project: CXF Issue Type: Bug Components: logging Affects Versions: 3.2.1, 3.1.14 Reporter: Franz Forsthofer Fix For: 3.1.15, 3.2.2 In the ext.logging feature the log event (LogEvent) has the attribute truncated which indicates whether the logged payloud was trancated or not. This attribute is not set correctly by the interceptors - org.apache.cxf.ext.logging.LoggingInInterceptor - org.apache.cxf.ext.logging.LoggingOutInterceptor I will add a patch via github. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251272#comment-16251272
]
Andriy Redko commented on CXF-7544:
---
Hey Sergey,
Yeah, I think the interface would be helpful but it is more like a workaround.
The CDIClassUnwrapper is useful indeed, I am relying on it in the solution I
have, will send the PR shortly just to get some feedback from you guys.
However, the CDIClassUnwrapper does not solve the problem. Here is the flow I
am observing in case of simple filter from the description of this issue.
1. The ServerProviderFactory creates the provider instance -> this is just a
proxy at the moment
2. The request comes in, ServerProviderFactory runs request filters -> this is
were the instance behind the proxy is instantiated and injection happens (and
we would never have direct access to it from CXF side)
So basically the issue I am solving is this: when CDI creates the instance of
the bean (corresponding to providers), try to trace it back to the ProviderInfo
through the ServerProviderFactory and inject the contextual properties. Hope it
make sense :)
Thanks.
Best Regards,
Andriy Redko
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251274#comment-16251274
]
Sergey Beryozkin commented on CXF-7544:
---
Hi Andriy
Would it lead though to new callback interfaces/etc. I'd have no probs with
asking users to create interfaces. Though lest see your PR :-)
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251274#comment-16251274
]
Sergey Beryozkin edited comment on CXF-7544 at 11/14/17 11:43 AM:
--
Hi Andriy
Would it lead though to new callback interfaces/etc ? I'd have no probs with
asking users to create interfaces. Though lets see your PR :-)
was (Author: sergey_beryozkin):
Hi Andriy
Would it lead though to new callback interfaces/etc. I'd have no probs with
asking users to create interfaces. Though lest see your PR :-)
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251277#comment-16251277
]
Sergey Beryozkin commented on CXF-7544:
---
In general, rather than trying to add various add-ons in the CXF JAX-RS core
for CDI to inject, I'd consider doing encapsulating the current 'manual' code
into a default injection strategy and then move on to providing a CDI one, on
the next master
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251283#comment-16251283
]
Andriy Redko commented on CXF-7544:
---
Yes, this is the goal, extract the generic injection strategy which should be
easy pluggable into dependency injection frameworks (like CDI) lifecycle.
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251292#comment-16251292
]
Sergey Beryozkin commented on CXF-7544:
---
IMHO it should be the other way around, dependency injection framework be
pluggable into CXF JAX-RS core.
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251293#comment-16251293
]
Sergey Beryozkin commented on CXF-7544:
---
Never mind, I haven;t even seen the PR :-), sorry.
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251357#comment-16251357
]
Andriy Redko commented on CXF-7544:
---
The game of words :) but I think we are meaning the same thing. The PR for this
issue is much simpler in scope (more like interim fix).
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251374#comment-16251374
]
ASF GitHub Bot commented on CXF-7544:
-
reta opened a new pull request #339: CXF-7544: Support @Context-based injection
into proxied CDI beans
URL: https://github.com/apache/cxf/pull/339
The issue pop up as part of https://github.com/apache/cxf/pull/330
discussion. In case when provider / feature / resource is a proxied CDI bean,
the contextual class members (annotated with @Context) are not injected.
More broadly,iIn some circumstances (like using `@ApplicationScoped`
annotation for example) the CDI runtime will create a proxy class for a
particular bean. As the result, the CXF side is going to bind the particular
provider metadata to this proxy instance. It looks logical and unambiguous.
However, the interesting things are happening when CXF will try to inject
contextual proxies (`@Context` annotations) into the provider instance. The
injections are successful but the target object for them will be the proxy
instance (not the real instance behind it). Consequently, at runtime, when the
proxy delegates the call to a backing instance, all contextual proxies are null
in there (simply put, not set).
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
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251377#comment-16251377
]
ASF GitHub Bot commented on CXF-7544:
-
reta commented on issue #339: CXF-7544: Support @Context-based injection into
proxied CDI beans
URL: https://github.com/apache/cxf/pull/339#issuecomment-344261613
@johnament @sberyozkin @rmannibucau could you guys take a look? The are few
things I don't like (but don't have a better idea yet how to implement). The PR
solves the simplest case with field injection (at the moment).
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
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251392#comment-16251392
]
ASF GitHub Bot commented on CXF-7544:
-
rmannibucau commented on issue #339: CXF-7544: Support @Context-based injection
into proxied CDI beans
URL: https://github.com/apache/cxf/pull/339#issuecomment-344263525
@reta did you try implementing it wrapping the bean annotated type (or
attributes) to add a CxfInjectionInterceptor annotation binding and implement
it with a @AroundConstruct? Should work for all "handlable" cases and looks
more or less as complicated as this PR
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
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251418#comment-16251418
]
ASF GitHub Bot commented on CXF-7544:
-
johnament commented on a change in pull request #339: CXF-7544: Support
@Context-based injection into proxied CDI beans
URL: https://github.com/apache/cxf/pull/339#discussion_r150841179
##
File path:
integration/cdi/src/main/java/org/apache/cxf/cdi/CdiClassUnwrapper.java
##
@@ -22,8 +22,18 @@
import org.apache.cxf.common.util.ClassUnwrapper;
+/**
+ * Unwraps the CDI proxy classes into real classes.
+ */
class CdiClassUnwrapper implements ClassUnwrapper {
-private static final Pattern PROXY_PATTERN =
Pattern.compile(".+\\$\\$.+Proxy");
+/**
+ * Known proxy patterns for OWB and Weld:
+ *
+ * Xxx$$OwbNormalScopeProxy0
+ * Xxx$Proxy$_$$_WeldClientProxy
+ *
+ */
+private static final Pattern PROXY_PATTERN =
Pattern.compile(".+\\$\\$.+Proxy\\d*");
Review comment:
are you sure its always digits on the end?
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
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251431#comment-16251431
]
Sergey Beryozkin commented on CXF-7544:
---
Hey Andriy
First of all thanks for the effort, you are always taking on the tricky issues
:-)
I agree this PR would qualify as an interim solution. I can see the newly added
ServerProviderFactory methods are only called from CDI and they do not affect
the existing logic of the ServerProviderFactory, so it's prob safe enough to
merge even to 3.2.2-SNAPSHOT with the expectations that these
ServerProviderFactory callback methods will be eventually gone.
That said, I'd not hesitate to use another interim solution till a new master
opening soon enough, which us doing nothing and asking users do the interfaces
:-), it works and thus is quite reasonable.
With the new master opening, I'd propose starting with a strategy approach
along these lines: CXF JAX-RS submits all the valid ClassResourceInfos to
InjectionStrategy. It won't CDI/etc calling back, it will be CXF asking the
strategy to inject onto a provided set of classes. As I said the default one
will do what is done now, it will check @Context (fields/constructors) and if
it can see it it will inject. CDI will instead will also check @Inject and may
also delegate to the default one otherwise, etc. We'll have a lot of time to do
it right on the new master. I believe Jersey is doing @Inject of standard
JAX-RS contexts via a similar mechanisms for a while.
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251485#comment-16251485
]
ASF GitHub Bot commented on CXF-7544:
-
reta commented on a change in pull request #339: CXF-7544: Support
@Context-based injection into proxied CDI beans
URL: https://github.com/apache/cxf/pull/339#discussion_r150854464
##
File path:
integration/cdi/src/main/java/org/apache/cxf/cdi/CdiClassUnwrapper.java
##
@@ -22,8 +22,18 @@
import org.apache.cxf.common.util.ClassUnwrapper;
+/**
+ * Unwraps the CDI proxy classes into real classes.
+ */
class CdiClassUnwrapper implements ClassUnwrapper {
-private static final Pattern PROXY_PATTERN =
Pattern.compile(".+\\$\\$.+Proxy");
+/**
+ * Known proxy patterns for OWB and Weld:
+ *
+ * Xxx$$OwbNormalScopeProxy0
+ * Xxx$Proxy$_$$_WeldClientProxy
+ *
+ */
+private static final Pattern PROXY_PATTERN =
Pattern.compile(".+\\$\\$.+Proxy\\d*");
Review comment:
I see it consistently on OWB but it may not be always (hereby `\d*` to make
this part optional)
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
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251493#comment-16251493
]
ASF GitHub Bot commented on CXF-7544:
-
reta commented on issue #339: CXF-7544: Support @Context-based injection into
proxied CDI beans
URL: https://github.com/apache/cxf/pull/339#issuecomment-344284976
@rmannibucau Yes, I tried this approach first thing (and would very likely
complement this PR to handle the `@Context` arguments in constructors). The
issue I hit hard is that I couldn't trace back the `ServerProviderFactory` to
use for constructor injection :( Plus, the `InvocationContext::target` is set
to `null` so I don't have access to the instance being constructed (very likely
because is being constructed indeed).
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
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251495#comment-16251495
]
ASF GitHub Bot commented on CXF-7544:
-
reta commented on issue #339: CXF-7544: Support @Context-based injection into
proxied CDI beans
URL: https://github.com/apache/cxf/pull/339#issuecomment-344284976
@rmannibucau Yes, I tried this approach first thing (and would very likely
complement this PR to handle the `@Context` arguments in constructors). The
issue I hit hard is that I couldn't trace back the `ServerProviderFactory` to
use for constructor injection :( Plus, the `InvocationContext::target` is set
to `null` so I don't have access to the instance being constructed (very likely
because it is being constructed indeed).
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
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251494#comment-16251494
]
ASF GitHub Bot commented on CXF-7544:
-
reta commented on issue #339: CXF-7544: Support @Context-based injection into
proxied CDI beans
URL: https://github.com/apache/cxf/pull/339#issuecomment-344284976
@rmannibucau Yes, I tried this approach first thing (and would very likely
complement this PR to handle the `@Context` arguments in constructors). The
issue I hit hard is that I couldn't trace back the `ServerProviderFactory` to
use for constructor injection :( Plus, the `InvocationContext::target` is set
to `null` so I don't have access to the instance being constructed (very likely
because ше is being constructed indeed).
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
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251498#comment-16251498
]
ASF GitHub Bot commented on CXF-7544:
-
rmannibucau commented on issue #339: CXF-7544: Support @Context-based injection
into proxied CDI beans
URL: https://github.com/apache/cxf/pull/339#issuecomment-344285631
You should have the instance after having called proceed normally if you
return an Object, no? - or just use a lazy init in @AroundInvoke even if less
elegant.
If you add an interceptor in the JAXRSCdiExtension you can pass to the
interceptor the ServerProviderfactory and be contextual without any later
lookup.
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
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (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:all-tabpanel
]
Russell Orf updated CXF-7552:
-
Affects Version/s: (was: 3.1.13)
3.1.14
> 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.14
>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] [Updated] (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:all-tabpanel
]
Russell Orf updated CXF-7552:
-
Component/s: Tooling
Soap Binding
> 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
> Components: Soap Binding, Tooling
>Affects Versions: 3.1.14
>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] [Updated] (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:all-tabpanel
]
Russell Orf updated CXF-7552:
-
Labels: features (was: )
> 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
> Components: Soap Binding, Tooling
>Affects Versions: 3.1.14
>Reporter: Russell Orf
> Labels: features
> 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-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251622#comment-16251622
]
ASF GitHub Bot commented on CXF-7544:
-
johnament commented on a change in pull request #339: CXF-7544: Support
@Context-based injection into proxied CDI beans
URL: https://github.com/apache/cxf/pull/339#discussion_r150880615
##
File path:
integration/cdi/src/main/java/org/apache/cxf/cdi/CdiClassUnwrapper.java
##
@@ -22,8 +22,18 @@
import org.apache.cxf.common.util.ClassUnwrapper;
+/**
+ * Unwraps the CDI proxy classes into real classes.
+ */
class CdiClassUnwrapper implements ClassUnwrapper {
-private static final Pattern PROXY_PATTERN =
Pattern.compile(".+\\$\\$.+Proxy");
+/**
+ * Known proxy patterns for OWB and Weld:
+ *
+ * Xxx$$OwbNormalScopeProxy0
+ * Xxx$Proxy$_$$_WeldClientProxy
+ *
+ */
+private static final Pattern PROXY_PATTERN =
Pattern.compile(".+\\$\\$.+Proxy\\d*");
Review comment:
should it perhaps then be `.*`
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
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
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=16251652#comment-16251652
]
Andy McCright commented on CXF-7527:
[~nlenoire] I merged the changes in PR
[https://github.com/apache/cxf/pull/337]. Is it possible for you to verify
that this resolves the problem for you?
> 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] [Resolved] (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 resolved CXF-7556. --- Resolution: Fixed > 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=16251694#comment-16251694 ] Sergey Beryozkin commented on CXF-7535: --- I've added cxf-rt-rs-extension-reactvestreams and moved the shared code there and works nicely with both Rxjava2 and Reactor, we can keep adding reactivestreams-only aware code to that module, for the server or client, such that stays portable between RxJava2/Reactor/etc I still have some comments re Mono and Flux, will do asap > 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-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=16251694#comment-16251694 ] Sergey Beryozkin edited comment on CXF-7535 at 11/14/17 4:43 PM: - I've added cxf-rt-rs-extension-reactvestreams and moved the shared code there and it works nicely with both Rxjava2 and Reactor, we can keep adding reactivestreams-only aware code to that module, for the server or client, such that it stays portable between RxJava2/Reactor/etc I still have some comments re Mono and Flux, will do asap was (Author: sergey_beryozkin): I've added cxf-rt-rs-extension-reactvestreams and moved the shared code there and works nicely with both Rxjava2 and Reactor, we can keep adding reactivestreams-only aware code to that module, for the server or client, such that stays portable between RxJava2/Reactor/etc I still have some comments re Mono and Flux, will do asap > 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-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:comment-tabpanel&focusedCommentId=16251766#comment-16251766
]
ASF GitHub Bot commented on CXF-7553:
-
andymc12 closed pull request #335: [CXF-7553] Consider the req headers' quality
factors in selectVariant
URL: https://github.com/apache/cxf/pull/335
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/RequestImpl.java
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/RequestImpl.java
index 09148549d9e..8eb6738e78c 100644
--- a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/RequestImpl.java
+++ b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/RequestImpl.java
@@ -68,46 +68,60 @@ public Variant selectVariant(List vars) throws
IllegalArgumentException
List acceptLangs = headers.getAcceptableLanguages();
List acceptEncs = parseAcceptEnc(
headers.getRequestHeaders().getFirst(HttpHeaders.ACCEPT_ENCODING));
-
+List requestVariants = sortAllCombinations(acceptMediaTypes,
acceptLangs, acceptEncs);
List varyValues = new LinkedList();
-
-List matchingVars = new LinkedList();
-for (Variant var : vars) {
-MediaType mt = var.getMediaType();
-Locale lang = var.getLanguage();
-String enc = var.getEncoding();
-
-boolean mtMatched = mt == null || acceptMediaTypes.isEmpty()
-|| JAXRSUtils.intersectMimeTypes(acceptMediaTypes, mt).size()
!= 0;
-if (mtMatched) {
-handleVaryValues(varyValues, HttpHeaders.ACCEPT);
-}
-
-boolean langMatched = lang == null || acceptLangs.isEmpty()
-|| isLanguageMatched(acceptLangs, lang);
-if (langMatched) {
-handleVaryValues(varyValues, HttpHeaders.ACCEPT_LANGUAGE);
-}
-
-boolean encMatched = acceptEncs.isEmpty() || enc == null
-|| isEncMatached(acceptEncs, enc);
-if (encMatched) {
-handleVaryValues(varyValues, HttpHeaders.ACCEPT_ENCODING);
-}
-
-if (mtMatched && encMatched && langMatched) {
-matchingVars.add(var);
+for (Variant requestVar : requestVariants) {
+for (Variant var : vars) {
+MediaType mt = var.getMediaType();
+Locale lang = var.getLanguage();
+String enc = var.getEncoding();
+
+boolean mtMatched = mt == null ||
requestVar.getMediaType().isCompatible(mt);
+if (mtMatched) {
+handleVaryValues(varyValues, HttpHeaders.ACCEPT);
+}
+
+boolean langMatched = lang == null ||
isLanguageMatched(requestVar.getLanguage(), lang);
+if (langMatched) {
+handleVaryValues(varyValues, HttpHeaders.ACCEPT_LANGUAGE);
+}
+
+boolean encMatched = acceptEncs.isEmpty() || enc == null
+|| isEncMatached(requestVar.getEncoding(), enc);
+if (encMatched) {
+handleVaryValues(varyValues, HttpHeaders.ACCEPT_ENCODING);
+}
+
+if (mtMatched && encMatched && langMatched) {
+addVaryHeader(varyValues);
+return var;
+}
}
}
-if (matchingVars.size() > 0) {
-addVaryHeader(varyValues);
-Collections.sort(matchingVars, new VariantComparator());
-return matchingVars.get(0);
-}
return null;
}
-private static void handleVaryValues(List varyValues, String
...values) {
+private static List sortAllCombinations(List
mediaTypes,
+ List langs,
+ List encs) {
+List requestVars = new LinkedList<>();
+for (MediaType mt : mediaTypes) {
+for (Locale lang : langs) {
+if (encs.size() < 1) {
+requestVars.add(new Variant(mt, lang, null));
+} else {
+for (String enc : encs) {
+requestVars.add(new Variant(mt, lang, enc));
+}
+}
+
+}
+}
+Collections.sort(requestVars, VariantComparator.INSTANCE);
+return requestVars;
+}
+
+private static void handleVaryValues(List varyValues,
String...values) {
[jira] [Commented] (FEDIZ-212) Multiple OIDC logout return to login page
[
https://issues.apache.org/jira/browse/FEDIZ-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251817#comment-16251817
]
ASF GitHub Bot commented on FEDIZ-212:
--
gonzalad closed pull request #20: FEDIZ-212: fix logout when no httpSession
present
URL: https://github.com/apache/cxf-fediz/pull/20
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/services/oidc/src/main/java/org/apache/cxf/fediz/service/oidc/logout/LogoutService.java
b/services/oidc/src/main/java/org/apache/cxf/fediz/service/oidc/logout/LogoutService.java
index 7dff3b82..997d43db 100644
---
a/services/oidc/src/main/java/org/apache/cxf/fediz/service/oidc/logout/LogoutService.java
+++
b/services/oidc/src/main/java/org/apache/cxf/fediz/service/oidc/logout/LogoutService.java
@@ -58,6 +58,7 @@
private FedizSubjectCreator subjectCreator = new FedizSubjectCreator();
private BackChannelLogoutHandler backChannelLogoutHandler;
private List logoutHandlers;
+private boolean allowAnonymousLogout;
@POST
public Response initiateLogoutPost(MultivaluedMap params) {
@@ -71,18 +72,22 @@ public Response initiateLogoutGet() {
protected Response doInitiateLogout(MultivaluedMap params)
{
IdToken idTokenHint = getIdTokenHint(params);
-OidcUserSubject subject = subjectCreator.createUserSubject(mc, params);
-
Client client = getClient(params, idTokenHint);
-if (backChannelLogoutHandler != null) {
-backChannelLogoutHandler.handleLogout(client, subject,
idTokenHint);
-}
-if (logoutHandlers != null) {
-for (LogoutHandler handler : logoutHandlers) {
-handler.handleLogout(client, subject);
+if (!allowAnonymousLogout ||
mc.getSecurityContext().getUserPrincipal() != null) {
+OidcUserSubject subject = subjectCreator.createUserSubject(mc,
params);
+
+if (backChannelLogoutHandler != null) {
+backChannelLogoutHandler.handleLogout(client, subject,
idTokenHint);
+}
+if (logoutHandlers != null) {
+
+for (LogoutHandler handler : logoutHandlers) {
+handler.handleLogout(client, subject);
+}
}
}
+
// Clear OIDC session now
mc.getHttpServletRequest().getSession().invalidate();
@@ -113,7 +118,7 @@ private URI getClientLogoutUri(Client client,
MultivaluedMap par
String clientLogoutUriParam = params.getFirst(CLIENT_LOGOUT_URI);
if (uris.length > 1) {
if (clientLogoutUriParam == null
-|| !new
HashSet<>(Arrays.asList(uris)).contains(clientLogoutUriParam)) {
+|| !new
HashSet<>(Arrays.asList(uris)).contains(clientLogoutUriParam)) {
throw new BadRequestException();
}
uriStr = clientLogoutUriParam;
@@ -177,6 +182,10 @@ public void
setBackChannelLogoutHandler(BackChannelLogoutHandler handler) {
this.backChannelLogoutHandler = handler;
}
+public void setAllowAnonymousLogout(boolean allowAnonymousLogout) {
+this.allowAnonymousLogout = allowAnonymousLogout;
+}
+
public void close() {
if (backChannelLogoutHandler != null) {
backChannelLogoutHandler.close();
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
> Multiple OIDC logout return to login page
> -
>
> Key: FEDIZ-212
> URL: https://issues.apache.org/jira/browse/FEDIZ-212
> Project: CXF-Fediz
> Issue Type: Bug
>Affects Versions: 1.4.2
>Reporter: gonzalad
> Fix For: 1.4.3
>
>
> I'm using Fediz SSO global logout.
> Scenario :
> * start a clean incognito session
> * user logs to OIDC Client 1
> * user logs to OIDC Client 2 (in another tab, same browser window)
> * user logs out OIDC Client 1
> * now user switched tab to OIDC Client 2
> * user logs out from OIDC Client 2
> On the last logout, the user is automatically rerouted to IDP login UI.
> Looking at network view of Chrome dev toolbar, we see when the user is
> redirected back from IDP to OIDC (/oidc/login), that the OIDC redirects back
> to logout : /oidc/idp/logout.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (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 resolved CXF-7553.
Resolution: Fixed
> 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] [Resolved] (FEDIZ-212) Multiple OIDC logout return to login page
[ https://issues.apache.org/jira/browse/FEDIZ-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gonzalad resolved FEDIZ-212. Resolution: Fixed > Multiple OIDC logout return to login page > - > > Key: FEDIZ-212 > URL: https://issues.apache.org/jira/browse/FEDIZ-212 > Project: CXF-Fediz > Issue Type: Bug >Affects Versions: 1.4.2 >Reporter: gonzalad > Fix For: 1.4.3 > > > I'm using Fediz SSO global logout. > Scenario : > * start a clean incognito session > * user logs to OIDC Client 1 > * user logs to OIDC Client 2 (in another tab, same browser window) > * user logs out OIDC Client 1 > * now user switched tab to OIDC Client 2 > * user logs out from OIDC Client 2 > On the last logout, the user is automatically rerouted to IDP login UI. > Looking at network view of Chrome dev toolbar, we see when the user is > redirected back from IDP to OIDC (/oidc/login), that the OIDC redirects back > to logout : /oidc/idp/logout. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251947#comment-16251947
]
ASF GitHub Bot commented on CXF-7544:
-
reta commented on issue #339: CXF-7544: Support @Context-based injection into
proxied CDI beans
URL: https://github.com/apache/cxf/pull/339#issuecomment-344359630
@rmannibucau Thank a lot for the advice, I will retry the implementation
with `@AroundInvoke`, the `ServerProviderfactory` sadly is not a singleton but
per-factory bean (so there could be more than one) ... Anyway, this is
something very CXFy, figuring out the way to do that :)
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
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251945#comment-16251945
]
ASF GitHub Bot commented on CXF-7544:
-
reta commented on issue #339: CXF-7544: Support @Context-based injection into
proxied CDI beans
URL: https://github.com/apache/cxf/pull/339#issuecomment-344359630
@rmannibucau Thank a lot for the advice, I will try the implementation with
`@AroundInvoke`, the `ServerProviderfactory` sadly is not a singleton but
per-factory bean (so there could be more than one) ... Anyway, this is
something very CXFy, figuring out the way to do that :)
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
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251953#comment-16251953
]
ASF GitHub Bot commented on CXF-7544:
-
reta commented on a change in pull request #339: CXF-7544: Support
@Context-based injection into proxied CDI beans
URL: https://github.com/apache/cxf/pull/339#discussion_r150928467
##
File path:
integration/cdi/src/main/java/org/apache/cxf/cdi/CdiClassUnwrapper.java
##
@@ -22,8 +22,18 @@
import org.apache.cxf.common.util.ClassUnwrapper;
+/**
+ * Unwraps the CDI proxy classes into real classes.
+ */
class CdiClassUnwrapper implements ClassUnwrapper {
-private static final Pattern PROXY_PATTERN =
Pattern.compile(".+\\$\\$.+Proxy");
+/**
+ * Known proxy patterns for OWB and Weld:
+ *
+ * Xxx$$OwbNormalScopeProxy0
+ * Xxx$Proxy$_$$_WeldClientProxy
+ *
+ */
+private static final Pattern PROXY_PATTERN =
Pattern.compile(".+\\$\\$.+Proxy\\d*");
Review comment:
Hm ... not sure,`\d*` could be explained (and I have example for it), .* not
sure
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
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CXF-7563) URI gets
Daniyar Yeralin created CXF-7563:
Summary: URI gets
Key: CXF-7563
URL: https://issues.apache.org/jira/browse/CXF-7563
Project: CXF
Issue Type: Bug
Components: JAX-RS
Environment: Tested on two systems:
1) Darwin 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017;
root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64
2) Linux 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64
x86_64 x86_64 GNU/Linux
Reporter: Daniyar Yeralin
Priority: Minor
When using SpringBoot + JAX-RS server (with two service beans from *2 separate
packages*) combined with Swagger2Feature (to generate swagger.json for provided
ServiceBeans), URIs for these services get appended with '_1' (under
"operationId" inside swagger.json)
Sample Java class:
{code:java}
@SpringBootApplication
public class DemoApplication {
@Autowired
private SampleService sampleService;
@Autowired
private SampleServiceInternal sampleServiceInternal;
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
@Bean(destroyMethod = "shutdown")
public SpringBus cxf() {
return new SpringBus();
}
@Bean(destroyMethod = "destroy")
@DependsOn("cxf")
public Server jaxRsServer() {
final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
factory.setServiceBeans(Arrays.asList(sampleService,
sampleServiceInternal));
factory.setBus(cxf());
factory.setAddress("/");
factory.setFeatures(Arrays.asList(configureSwagger()));
return factory.create();
}
private Swagger2Feature configureSwagger() {
Swagger2Feature feature = new Swagger2Feature();
feature.setBasePath("/");
return feature;
}
}
{code}
Swagger.json:
{code:json}
// 20171114155626
// http://localhost:17070/services/swagger.json
{
"swagger": "2.0",
"info": {
"description": "The Application",
"version": "1.0.0",
"title": "Sample REST Application",
"contact": {
"name": "us...@cxf.apache.org"
},
"license": {
"name": "Apache 2.0 License",
"url": "http://www.apache.org/licenses/LICENSE-2.0.html";
}
},
"basePath": "/services",
"tags": Array[2][
{
"name": "internal"
},
{
"name": "test"
}
],
"paths": {
"/Internal/internal": {
"get": {
"tags": Array[1][
"internal"
],
"operationId": "getInternal_1",
"parameters": Array[0][
],
"responses": {
"200": {
"description": "successful operation",
"schema": {
"type": "string"
},
"headers": {
}
}
}
}
},
"/test/test": {
"get": {
"tags": Array[1][
"test"
],
"operationId": "getTest_1",
"parameters": Array[0][
],
"responses": {
"200": {
"description": "successful operation",
"schema": {
"type": "string"
},
"headers": {
}
}
}
}
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7563) Swagger.json is generated with modified URI (appens '_1')
[
https://issues.apache.org/jira/browse/CXF-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniyar Yeralin updated CXF-7563:
-
Summary: Swagger.json is generated with modified URI (appens '_1') (was:
URI gets )
> Swagger.json is generated with modified URI (appens '_1')
> -
>
> Key: CXF-7563
> URL: https://issues.apache.org/jira/browse/CXF-7563
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Environment: Tested on two systems:
> 1) Darwin 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017;
> root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64
> 2) Linux 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64
> x86_64 x86_64 GNU/Linux
>Reporter: Daniyar Yeralin
>Priority: Minor
>
> When using SpringBoot + JAX-RS server (with two service beans from *2
> separate packages*) combined with Swagger2Feature (to generate swagger.json
> for provided ServiceBeans), URIs for these services get appended with '_1'
> (under "operationId" inside swagger.json)
> Sample Java class:
> {code:java}
> @SpringBootApplication
> public class DemoApplication {
> @Autowired
> private SampleService sampleService;
> @Autowired
> private SampleServiceInternal sampleServiceInternal;
> public static void main(String[] args) {
> SpringApplication.run(DemoApplication.class, args);
> }
> @Bean(destroyMethod = "shutdown")
> public SpringBus cxf() {
> return new SpringBus();
> }
> @Bean(destroyMethod = "destroy")
> @DependsOn("cxf")
> public Server jaxRsServer() {
> final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
> factory.setServiceBeans(Arrays.asList(sampleService,
> sampleServiceInternal));
> factory.setBus(cxf());
> factory.setAddress("/");
> factory.setFeatures(Arrays.asList(configureSwagger()));
> return factory.create();
> }
> private Swagger2Feature configureSwagger() {
> Swagger2Feature feature = new Swagger2Feature();
> feature.setBasePath("/");
> return feature;
> }
> }
> {code}
> Swagger.json:
> {code:json}
> // 20171114155626
> // http://localhost:17070/services/swagger.json
> {
> "swagger": "2.0",
> "info": {
> "description": "The Application",
> "version": "1.0.0",
> "title": "Sample REST Application",
> "contact": {
> "name": "us...@cxf.apache.org"
> },
> "license": {
> "name": "Apache 2.0 License",
> "url": "http://www.apache.org/licenses/LICENSE-2.0.html";
> }
> },
> "basePath": "/services",
> "tags": Array[2][
> {
> "name": "internal"
> },
> {
> "name": "test"
> }
> ],
> "paths": {
> "/Internal/internal": {
> "get": {
> "tags": Array[1][
> "internal"
> ],
> "operationId": "getInternal_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> },
> "/test/test": {
> "get": {
> "tags": Array[1][
> "test"
> ],
> "operationId": "getTest_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7563) Swagger.json is generated with modified URI (appens '_1')
[
https://issues.apache.org/jira/browse/CXF-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniyar Yeralin updated CXF-7563:
-
Description:
When using SpringBoot + JAX-RS server (with two service beans from *2 separate
packages*) combined with Swagger2Feature (to generate swagger.json for provided
ServiceBeans), URIs for these services get appended with '_1' (under
"operationId" inside swagger.json)
Structure:
!https://i.imgur.com/Q0hh4O3.png!
Sample Java class:
{code:java}
@SpringBootApplication
public class DemoApplication {
@Autowired
private SampleService sampleService;
@Autowired
private SampleServiceInternal sampleServiceInternal;
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
@Bean(destroyMethod = "shutdown")
public SpringBus cxf() {
return new SpringBus();
}
@Bean(destroyMethod = "destroy")
@DependsOn("cxf")
public Server jaxRsServer() {
final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
factory.setServiceBeans(Arrays.asList(sampleService,
sampleServiceInternal));
factory.setBus(cxf());
factory.setAddress("/");
factory.setFeatures(Arrays.asList(configureSwagger()));
return factory.create();
}
private Swagger2Feature configureSwagger() {
Swagger2Feature feature = new Swagger2Feature();
feature.setBasePath("/");
return feature;
}
}
{code}
Swagger.json:
{code:json}
// 20171114155626
// http://localhost:17070/services/swagger.json
{
"swagger": "2.0",
"info": {
"description": "The Application",
"version": "1.0.0",
"title": "Sample REST Application",
"contact": {
"name": "us...@cxf.apache.org"
},
"license": {
"name": "Apache 2.0 License",
"url": "http://www.apache.org/licenses/LICENSE-2.0.html";
}
},
"basePath": "/services",
"tags": Array[2][
{
"name": "internal"
},
{
"name": "test"
}
],
"paths": {
"/Internal/internal": {
"get": {
"tags": Array[1][
"internal"
],
"operationId": "getInternal_1",
"parameters": Array[0][
],
"responses": {
"200": {
"description": "successful operation",
"schema": {
"type": "string"
},
"headers": {
}
}
}
}
},
"/test/test": {
"get": {
"tags": Array[1][
"test"
],
"operationId": "getTest_1",
"parameters": Array[0][
],
"responses": {
"200": {
"description": "successful operation",
"schema": {
"type": "string"
},
"headers": {
}
}
}
}
}
}
}
{code}
was:
When using SpringBoot + JAX-RS server (with two service beans from *2 separate
packages*) combined with Swagger2Feature (to generate swagger.json for provided
ServiceBeans), URIs for these services get appended with '_1' (under
"operationId" inside swagger.json)
Sample Java class:
{code:java}
@SpringBootApplication
public class DemoApplication {
@Autowired
private SampleService sampleService;
@Autowired
private SampleServiceInternal sampleServiceInternal;
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
@Bean(destroyMethod = "shutdown")
public SpringBus cxf() {
return new SpringBus();
}
@Bean(destroyMethod = "destroy")
@DependsOn("cxf")
public Server jaxRsServer() {
final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
factory.setServiceBeans(Arrays.asList(sampleService,
sampleServiceInternal));
factory.setBus(cxf());
factory.setAddress("/");
factory.setFeatures(Arrays.asList(configureSwagger()));
return factory.create();
}
private Swagger2Feature configureSwagger() {
Swagger2Feature feature = new Swagger2Feature();
feature.setBasePath("/");
return feature;
}
}
{code}
Swagger.json:
{code:json}
// 20171114155626
// http://localhost:17070/services/swagger.json
{
"swagger": "2.0",
"info": {
"description": "The Application",
"version": "1.0.0",
"title": "Sample REST Application",
"contact": {
"name": "us...@cxf.apache.org"
},
"license": {
"name": "Apache 2.0 License",
"url": "http://www.apache.org/licenses/LICENSE-2.0.html";
}
},
"basePath": "/services",
"tags": Array[2][
{
"name": "internal"
},
{
"name": "test"
}
],
"paths": {
"/Internal/internal": {
"get": {
"tags": Array[1][
"internal"
],
"operatio
[jira] [Updated] (CXF-7563) Swagger.json is generated with modified URI (appens '_1')
[
https://issues.apache.org/jira/browse/CXF-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniyar Yeralin updated CXF-7563:
-
Description:
When using SpringBoot + JAX-RS server (with two service beans from *2 separate
packages*) combined with Swagger2Feature (to generate swagger.json for provided
ServiceBeans), URIs for these services get appended with '_1' (under
"operationId" inside swagger.json)
Sample (Gradle + IDEA) project:
https://github.com/yeralin/ReproduceBug-CXF-7563-
Structure:
!https://i.imgur.com/Q0hh4O3.png!
Sample Java class:
{code:java}
@SpringBootApplication
public class DemoApplication {
@Autowired
private SampleService sampleService;
@Autowired
private SampleServiceInternal sampleServiceInternal;
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
@Bean(destroyMethod = "shutdown")
public SpringBus cxf() {
return new SpringBus();
}
@Bean(destroyMethod = "destroy")
@DependsOn("cxf")
public Server jaxRsServer() {
final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
factory.setServiceBeans(Arrays.asList(sampleService,
sampleServiceInternal));
factory.setBus(cxf());
factory.setAddress("/");
factory.setFeatures(Arrays.asList(configureSwagger()));
return factory.create();
}
private Swagger2Feature configureSwagger() {
Swagger2Feature feature = new Swagger2Feature();
feature.setBasePath("/");
return feature;
}
}
{code}
Swagger.json:
{code:json}
// 20171114155626
// http://localhost:17070/services/swagger.json
{
"swagger": "2.0",
"info": {
"description": "The Application",
"version": "1.0.0",
"title": "Sample REST Application",
"contact": {
"name": "us...@cxf.apache.org"
},
"license": {
"name": "Apache 2.0 License",
"url": "http://www.apache.org/licenses/LICENSE-2.0.html";
}
},
"basePath": "/services",
"tags": Array[2][
{
"name": "internal"
},
{
"name": "test"
}
],
"paths": {
"/Internal/internal": {
"get": {
"tags": Array[1][
"internal"
],
"operationId": "getInternal_1",
"parameters": Array[0][
],
"responses": {
"200": {
"description": "successful operation",
"schema": {
"type": "string"
},
"headers": {
}
}
}
}
},
"/test/test": {
"get": {
"tags": Array[1][
"test"
],
"operationId": "getTest_1",
"parameters": Array[0][
],
"responses": {
"200": {
"description": "successful operation",
"schema": {
"type": "string"
},
"headers": {
}
}
}
}
}
}
}
{code}
was:
When using SpringBoot + JAX-RS server (with two service beans from *2 separate
packages*) combined with Swagger2Feature (to generate swagger.json for provided
ServiceBeans), URIs for these services get appended with '_1' (under
"operationId" inside swagger.json)
Structure:
!https://i.imgur.com/Q0hh4O3.png!
Sample Java class:
{code:java}
@SpringBootApplication
public class DemoApplication {
@Autowired
private SampleService sampleService;
@Autowired
private SampleServiceInternal sampleServiceInternal;
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
@Bean(destroyMethod = "shutdown")
public SpringBus cxf() {
return new SpringBus();
}
@Bean(destroyMethod = "destroy")
@DependsOn("cxf")
public Server jaxRsServer() {
final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
factory.setServiceBeans(Arrays.asList(sampleService,
sampleServiceInternal));
factory.setBus(cxf());
factory.setAddress("/");
factory.setFeatures(Arrays.asList(configureSwagger()));
return factory.create();
}
private Swagger2Feature configureSwagger() {
Swagger2Feature feature = new Swagger2Feature();
feature.setBasePath("/");
return feature;
}
}
{code}
Swagger.json:
{code:json}
// 20171114155626
// http://localhost:17070/services/swagger.json
{
"swagger": "2.0",
"info": {
"description": "The Application",
"version": "1.0.0",
"title": "Sample REST Application",
"contact": {
"name": "us...@cxf.apache.org"
},
"license": {
"name": "Apache 2.0 License",
"url": "http://www.apache.org/licenses/LICENSE-2.0.html";
}
},
"basePath": "/services",
"tags": Array[2][
{
"name": "internal"
},
{
"name": "test"
}
],
[jira] [Commented] (CXF-7563) Swagger.json is generated with modified URI (appens '_1')
[
https://issues.apache.org/jira/browse/CXF-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16252179#comment-16252179
]
Daniyar Yeralin commented on CXF-7563:
--
Interesting observation: when beans' classes are placed under one package (i.e.
put SampleService and SampleServiceInternal under
`reproduce.bug.demo.service`), URI will be rendered fine (without '_1').
> Swagger.json is generated with modified URI (appens '_1')
> -
>
> Key: CXF-7563
> URL: https://issues.apache.org/jira/browse/CXF-7563
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Environment: Tested on two systems:
> 1) Darwin 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017;
> root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64
> 2) Linux 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64
> x86_64 x86_64 GNU/Linux
>Reporter: Daniyar Yeralin
>Priority: Minor
>
> When using SpringBoot + JAX-RS server (with two service beans from *2
> separate packages*) combined with Swagger2Feature (to generate swagger.json
> for provided ServiceBeans), URIs for these services get appended with '_1'
> (under "operationId" inside swagger.json)
> Sample (Gradle + IDEA) project:
> https://github.com/yeralin/ReproduceBug-CXF-7563-
> Structure:
> !https://i.imgur.com/Q0hh4O3.png!
> Sample Java class:
> {code:java}
> @SpringBootApplication
> public class DemoApplication {
> @Autowired
> private SampleService sampleService;
> @Autowired
> private SampleServiceInternal sampleServiceInternal;
> public static void main(String[] args) {
> SpringApplication.run(DemoApplication.class, args);
> }
> @Bean(destroyMethod = "shutdown")
> public SpringBus cxf() {
> return new SpringBus();
> }
> @Bean(destroyMethod = "destroy")
> @DependsOn("cxf")
> public Server jaxRsServer() {
> final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
> factory.setServiceBeans(Arrays.asList(sampleService,
> sampleServiceInternal));
> factory.setBus(cxf());
> factory.setAddress("/");
> factory.setFeatures(Arrays.asList(configureSwagger()));
> return factory.create();
> }
> private Swagger2Feature configureSwagger() {
> Swagger2Feature feature = new Swagger2Feature();
> feature.setBasePath("/");
> return feature;
> }
> }
> {code}
> Swagger.json:
> {code:json}
> // 20171114155626
> // http://localhost:17070/services/swagger.json
> {
> "swagger": "2.0",
> "info": {
> "description": "The Application",
> "version": "1.0.0",
> "title": "Sample REST Application",
> "contact": {
> "name": "us...@cxf.apache.org"
> },
> "license": {
> "name": "Apache 2.0 License",
> "url": "http://www.apache.org/licenses/LICENSE-2.0.html";
> }
> },
> "basePath": "/services",
> "tags": Array[2][
> {
> "name": "internal"
> },
> {
> "name": "test"
> }
> ],
> "paths": {
> "/Internal/internal": {
> "get": {
> "tags": Array[1][
> "internal"
> ],
> "operationId": "getInternal_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> },
> "/test/test": {
> "get": {
> "tags": Array[1][
> "test"
> ],
> "operationId": "getTest_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CXF-7563) Swagger.json is generated with modified URI (appens '_1')
[
https://issues.apache.org/jira/browse/CXF-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16252179#comment-16252179
]
Daniyar Yeralin edited comment on CXF-7563 at 11/14/17 9:10 PM:
Interesting observation: when beans' classes are placed under one package (i.e.
put both SampleService and SampleServiceInternal under
`reproduce.bug.demo.service`), URI will be rendered fine (without '_1').
was (Author: daniyar94):
Interesting observation: when beans' classes are placed under one package (i.e.
put SampleService and SampleServiceInternal under
`reproduce.bug.demo.service`), URI will be rendered fine (without '_1').
> Swagger.json is generated with modified URI (appens '_1')
> -
>
> Key: CXF-7563
> URL: https://issues.apache.org/jira/browse/CXF-7563
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Environment: Tested on two systems:
> 1) Darwin 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017;
> root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64
> 2) Linux 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64
> x86_64 x86_64 GNU/Linux
>Reporter: Daniyar Yeralin
>Priority: Minor
>
> When using SpringBoot + JAX-RS server (with two service beans from *2
> separate packages*) combined with Swagger2Feature (to generate swagger.json
> for provided ServiceBeans), URIs for these services get appended with '_1'
> (under "operationId" inside swagger.json)
> Sample (Gradle + IDEA) project:
> https://github.com/yeralin/ReproduceBug-CXF-7563-
> Structure:
> !https://i.imgur.com/Q0hh4O3.png!
> Sample Java class:
> {code:java}
> @SpringBootApplication
> public class DemoApplication {
> @Autowired
> private SampleService sampleService;
> @Autowired
> private SampleServiceInternal sampleServiceInternal;
> public static void main(String[] args) {
> SpringApplication.run(DemoApplication.class, args);
> }
> @Bean(destroyMethod = "shutdown")
> public SpringBus cxf() {
> return new SpringBus();
> }
> @Bean(destroyMethod = "destroy")
> @DependsOn("cxf")
> public Server jaxRsServer() {
> final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
> factory.setServiceBeans(Arrays.asList(sampleService,
> sampleServiceInternal));
> factory.setBus(cxf());
> factory.setAddress("/");
> factory.setFeatures(Arrays.asList(configureSwagger()));
> return factory.create();
> }
> private Swagger2Feature configureSwagger() {
> Swagger2Feature feature = new Swagger2Feature();
> feature.setBasePath("/");
> return feature;
> }
> }
> {code}
> Swagger.json:
> {code:json}
> // 20171114155626
> // http://localhost:17070/services/swagger.json
> {
> "swagger": "2.0",
> "info": {
> "description": "The Application",
> "version": "1.0.0",
> "title": "Sample REST Application",
> "contact": {
> "name": "us...@cxf.apache.org"
> },
> "license": {
> "name": "Apache 2.0 License",
> "url": "http://www.apache.org/licenses/LICENSE-2.0.html";
> }
> },
> "basePath": "/services",
> "tags": Array[2][
> {
> "name": "internal"
> },
> {
> "name": "test"
> }
> ],
> "paths": {
> "/Internal/internal": {
> "get": {
> "tags": Array[1][
> "internal"
> ],
> "operationId": "getInternal_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> },
> "/test/test": {
> "get": {
> "tags": Array[1][
> "test"
> ],
> "operationId": "getTest_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CXF-7563) Swagger.json is generated with modified URI (appens '_1')
[
https://issues.apache.org/jira/browse/CXF-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16252179#comment-16252179
]
Daniyar Yeralin edited comment on CXF-7563 at 11/14/17 9:10 PM:
Interesting observation: when beans' classes are placed under one package (i.e.
put both SampleService and SampleServiceInternal under
`reproduce.bug.demo.service` package), URI will be rendered fine (without '_1').
was (Author: daniyar94):
Interesting observation: when beans' classes are placed under one package (i.e.
put both SampleService and SampleServiceInternal under
`reproduce.bug.demo.service`), URI will be rendered fine (without '_1').
> Swagger.json is generated with modified URI (appens '_1')
> -
>
> Key: CXF-7563
> URL: https://issues.apache.org/jira/browse/CXF-7563
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Environment: Tested on two systems:
> 1) Darwin 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017;
> root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64
> 2) Linux 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64
> x86_64 x86_64 GNU/Linux
>Reporter: Daniyar Yeralin
>Priority: Minor
>
> When using SpringBoot + JAX-RS server (with two service beans from *2
> separate packages*) combined with Swagger2Feature (to generate swagger.json
> for provided ServiceBeans), URIs for these services get appended with '_1'
> (under "operationId" inside swagger.json)
> Sample (Gradle + IDEA) project:
> https://github.com/yeralin/ReproduceBug-CXF-7563-
> Structure:
> !https://i.imgur.com/Q0hh4O3.png!
> Sample Java class:
> {code:java}
> @SpringBootApplication
> public class DemoApplication {
> @Autowired
> private SampleService sampleService;
> @Autowired
> private SampleServiceInternal sampleServiceInternal;
> public static void main(String[] args) {
> SpringApplication.run(DemoApplication.class, args);
> }
> @Bean(destroyMethod = "shutdown")
> public SpringBus cxf() {
> return new SpringBus();
> }
> @Bean(destroyMethod = "destroy")
> @DependsOn("cxf")
> public Server jaxRsServer() {
> final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
> factory.setServiceBeans(Arrays.asList(sampleService,
> sampleServiceInternal));
> factory.setBus(cxf());
> factory.setAddress("/");
> factory.setFeatures(Arrays.asList(configureSwagger()));
> return factory.create();
> }
> private Swagger2Feature configureSwagger() {
> Swagger2Feature feature = new Swagger2Feature();
> feature.setBasePath("/");
> return feature;
> }
> }
> {code}
> Swagger.json:
> {code:json}
> // 20171114155626
> // http://localhost:17070/services/swagger.json
> {
> "swagger": "2.0",
> "info": {
> "description": "The Application",
> "version": "1.0.0",
> "title": "Sample REST Application",
> "contact": {
> "name": "us...@cxf.apache.org"
> },
> "license": {
> "name": "Apache 2.0 License",
> "url": "http://www.apache.org/licenses/LICENSE-2.0.html";
> }
> },
> "basePath": "/services",
> "tags": Array[2][
> {
> "name": "internal"
> },
> {
> "name": "test"
> }
> ],
> "paths": {
> "/Internal/internal": {
> "get": {
> "tags": Array[1][
> "internal"
> ],
> "operationId": "getInternal_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> },
> "/test/test": {
> "get": {
> "tags": Array[1][
> "test"
> ],
> "operationId": "getTest_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7563) Swagger.json is generated with modified URI (appends '_1')
[
https://issues.apache.org/jira/browse/CXF-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniyar Yeralin updated CXF-7563:
-
Summary: Swagger.json is generated with modified URI (appends '_1') (was:
Swagger.json is generated with modified URI (appens '_1'))
> Swagger.json is generated with modified URI (appends '_1')
> --
>
> Key: CXF-7563
> URL: https://issues.apache.org/jira/browse/CXF-7563
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Environment: Tested on two systems:
> 1) Darwin 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017;
> root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64
> 2) Linux 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64
> x86_64 x86_64 GNU/Linux
>Reporter: Daniyar Yeralin
>Priority: Minor
>
> When using SpringBoot + JAX-RS server (with two service beans from *2
> separate packages*) combined with Swagger2Feature (to generate swagger.json
> for provided ServiceBeans), URIs for these services get appended with '_1'
> (under "operationId" inside swagger.json)
> Sample (Gradle + IDEA) project:
> https://github.com/yeralin/ReproduceBug-CXF-7563-
> Structure:
> !https://i.imgur.com/Q0hh4O3.png!
> Sample Java class:
> {code:java}
> @SpringBootApplication
> public class DemoApplication {
> @Autowired
> private SampleService sampleService;
> @Autowired
> private SampleServiceInternal sampleServiceInternal;
> public static void main(String[] args) {
> SpringApplication.run(DemoApplication.class, args);
> }
> @Bean(destroyMethod = "shutdown")
> public SpringBus cxf() {
> return new SpringBus();
> }
> @Bean(destroyMethod = "destroy")
> @DependsOn("cxf")
> public Server jaxRsServer() {
> final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
> factory.setServiceBeans(Arrays.asList(sampleService,
> sampleServiceInternal));
> factory.setBus(cxf());
> factory.setAddress("/");
> factory.setFeatures(Arrays.asList(configureSwagger()));
> return factory.create();
> }
> private Swagger2Feature configureSwagger() {
> Swagger2Feature feature = new Swagger2Feature();
> feature.setBasePath("/");
> return feature;
> }
> }
> {code}
> Swagger.json:
> {code:json}
> // 20171114155626
> // http://localhost:17070/services/swagger.json
> {
> "swagger": "2.0",
> "info": {
> "description": "The Application",
> "version": "1.0.0",
> "title": "Sample REST Application",
> "contact": {
> "name": "us...@cxf.apache.org"
> },
> "license": {
> "name": "Apache 2.0 License",
> "url": "http://www.apache.org/licenses/LICENSE-2.0.html";
> }
> },
> "basePath": "/services",
> "tags": Array[2][
> {
> "name": "internal"
> },
> {
> "name": "test"
> }
> ],
> "paths": {
> "/Internal/internal": {
> "get": {
> "tags": Array[1][
> "internal"
> ],
> "operationId": "getInternal_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> },
> "/test/test": {
> "get": {
> "tags": Array[1][
> "test"
> ],
> "operationId": "getTest_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CXF-7564) codegen-plugin fails on wsdl2java goal
Michal Hlavac created CXF-7564:
--
Summary: codegen-plugin fails on wsdl2java goal
Key: CXF-7564
URL: https://issues.apache.org/jira/browse/CXF-7564
Project: CXF
Issue Type: Bug
Components: Soap Binding
Affects Versions: 3.2.1
Environment: {code}
Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
2017-10-18T09:58:13+02:00)
Maven home: /opt/apache/apache-maven
Java version: 1.8.0_151, vendor: Oracle Corporation
Java home: /usr/java/jdk1.8.0_151/jre
Default locale: sk_SK, platform encoding: UTF-8
OS name: "linux", version: "4.13.11-1-default", arch: "amd64", family: "unix"
{code}
Reporter: Michal Hlavac
cxf-codegen-plugin fails everytime when running `wsdl2java` goal with error:
{code}
Execution generate-wsdl of goal
org.apache.cxf:cxf-codegen-plugin:3.2.1:wsdl2java failed: Could not find jaxws
frontend within classpath
{code}
Sample project to reproduce issue in attachment. It works if you change plugin
version to 3.2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7564) codegen-plugin fails on wsdl2java goal
[
https://issues.apache.org/jira/browse/CXF-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michal Hlavac updated CXF-7564:
---
Attachment: wsdl-example.zip
> codegen-plugin fails on wsdl2java goal
> --
>
> Key: CXF-7564
> URL: https://issues.apache.org/jira/browse/CXF-7564
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 3.2.1
> Environment: {code}
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T09:58:13+02:00)
> Maven home: /opt/apache/apache-maven
> Java version: 1.8.0_151, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_151/jre
> Default locale: sk_SK, platform encoding: UTF-8
> OS name: "linux", version: "4.13.11-1-default", arch: "amd64", family: "unix"
> {code}
>Reporter: Michal Hlavac
> Attachments: wsdl-example.zip
>
>
> cxf-codegen-plugin fails everytime when running `wsdl2java` goal with error:
> {code}
> Execution generate-wsdl of goal
> org.apache.cxf:cxf-codegen-plugin:3.2.1:wsdl2java failed: Could not find
> jaxws frontend within classpath
> {code}
> Sample project to reproduce issue in attachment. It works if you change
> plugin version to 3.2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7563) non-unique operationIds in swagger.json result in '_1' appended
[
https://issues.apache.org/jira/browse/CXF-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniyar Yeralin updated CXF-7563:
-
Affects Version/s: 3.1.11
Description:
We are using SpringBoot + JAX-RS server and define two service beans from *2
separate packages*. The jaxrs server is configured with Swagger2Feature to
generate the swagger.json, but the operationIds and thus the URIs for these
services get appended with '_1'.
Sample (Gradle + IDEA) project:
https://github.com/yeralin/ReproduceBug-CXF-7563-
Structure:
!https://i.imgur.com/Q0hh4O3.png!
Sample Java class:
{code:java}
@SpringBootApplication
public class DemoApplication {
@Autowired
private SampleService sampleService;
@Autowired
private SampleServiceInternal sampleServiceInternal;
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
@Bean(destroyMethod = "shutdown")
public SpringBus cxf() {
return new SpringBus();
}
@Bean(destroyMethod = "destroy")
@DependsOn("cxf")
public Server jaxRsServer() {
final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
factory.setServiceBeans(Arrays.asList(sampleService,
sampleServiceInternal));
factory.setBus(cxf());
factory.setAddress("/");
factory.setFeatures(Arrays.asList(configureSwagger()));
return factory.create();
}
private Swagger2Feature configureSwagger() {
Swagger2Feature feature = new Swagger2Feature();
feature.setBasePath("/");
return feature;
}
}
{code}
Swagger.json:
{code:json}
// 20171114155626
// http://localhost:17070/services/swagger.json
{
"swagger": "2.0",
"info": {
"description": "The Application",
"version": "1.0.0",
"title": "Sample REST Application",
"contact": {
"name": "us...@cxf.apache.org"
},
"license": {
"name": "Apache 2.0 License",
"url": "http://www.apache.org/licenses/LICENSE-2.0.html";
}
},
"basePath": "/services",
"tags": Array[2][
{
"name": "internal"
},
{
"name": "test"
}
],
"paths": {
"/Internal/internal": {
"get": {
"tags": Array[1][
"internal"
],
"operationId": "getInternal_1",
"parameters": Array[0][
],
"responses": {
"200": {
"description": "successful operation",
"schema": {
"type": "string"
},
"headers": {
}
}
}
}
},
"/test/test": {
"get": {
"tags": Array[1][
"test"
],
"operationId": "getTest_1",
"parameters": Array[0][
],
"responses": {
"200": {
"description": "successful operation",
"schema": {
"type": "string"
},
"headers": {
}
}
}
}
}
}
}
{code}
was:
When using SpringBoot + JAX-RS server (with two service beans from *2 separate
packages*) combined with Swagger2Feature (to generate swagger.json for provided
ServiceBeans), URIs for these services get appended with '_1' (under
"operationId" inside swagger.json)
Sample (Gradle + IDEA) project:
https://github.com/yeralin/ReproduceBug-CXF-7563-
Structure:
!https://i.imgur.com/Q0hh4O3.png!
Sample Java class:
{code:java}
@SpringBootApplication
public class DemoApplication {
@Autowired
private SampleService sampleService;
@Autowired
private SampleServiceInternal sampleServiceInternal;
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
@Bean(destroyMethod = "shutdown")
public SpringBus cxf() {
return new SpringBus();
}
@Bean(destroyMethod = "destroy")
@DependsOn("cxf")
public Server jaxRsServer() {
final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
factory.setServiceBeans(Arrays.asList(sampleService,
sampleServiceInternal));
factory.setBus(cxf());
factory.setAddress("/");
factory.setFeatures(Arrays.asList(configureSwagger()));
return factory.create();
}
private Swagger2Feature configureSwagger() {
Swagger2Feature feature = new Swagger2Feature();
feature.setBasePath("/");
return feature;
}
}
{code}
Swagger.json:
{code:json}
// 20171114155626
// http://localhost:17070/services/swagger.json
{
"swagger": "2.0",
"info": {
"description": "The Application",
"version": "1.0.0",
"title": "Sample REST Application",
"contact": {
"name": "us...@cxf.apache.org"
},
"license": {
"name": "Apache 2.0 License",
"url": "http://www.apache.org/licenses/LICENSE-2.0.html";
}
},
"baseP
[jira] [Updated] (CXF-7563) Non-unique operationIds in swagger.json result in '_1' appended
[
https://issues.apache.org/jira/browse/CXF-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniyar Yeralin updated CXF-7563:
-
Summary: Non-unique operationIds in swagger.json result in '_1' appended
(was: non-unique operationIds in swagger.json result in '_1' appended)
> Non-unique operationIds in swagger.json result in '_1' appended
> ---
>
> Key: CXF-7563
> URL: https://issues.apache.org/jira/browse/CXF-7563
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.11
> Environment: Tested on two systems:
> 1) Darwin 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017;
> root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64
> 2) Linux 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64
> x86_64 x86_64 GNU/Linux
>Reporter: Daniyar Yeralin
>Priority: Minor
>
> We are using SpringBoot + JAX-RS server and define two service beans from *2
> separate packages*. The jaxrs server is configured with Swagger2Feature to
> generate the swagger.json, but the operationIds and thus the URIs for these
> services get appended with '_1'.
> Sample (Gradle + IDEA) project:
> https://github.com/yeralin/ReproduceBug-CXF-7563-
> Structure:
> !https://i.imgur.com/Q0hh4O3.png!
> Sample Java class:
> {code:java}
> @SpringBootApplication
> public class DemoApplication {
> @Autowired
> private SampleService sampleService;
> @Autowired
> private SampleServiceInternal sampleServiceInternal;
> public static void main(String[] args) {
> SpringApplication.run(DemoApplication.class, args);
> }
> @Bean(destroyMethod = "shutdown")
> public SpringBus cxf() {
> return new SpringBus();
> }
> @Bean(destroyMethod = "destroy")
> @DependsOn("cxf")
> public Server jaxRsServer() {
> final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
> factory.setServiceBeans(Arrays.asList(sampleService,
> sampleServiceInternal));
> factory.setBus(cxf());
> factory.setAddress("/");
> factory.setFeatures(Arrays.asList(configureSwagger()));
> return factory.create();
> }
> private Swagger2Feature configureSwagger() {
> Swagger2Feature feature = new Swagger2Feature();
> feature.setBasePath("/");
> return feature;
> }
> }
> {code}
> Swagger.json:
> {code:json}
> // 20171114155626
> // http://localhost:17070/services/swagger.json
> {
> "swagger": "2.0",
> "info": {
> "description": "The Application",
> "version": "1.0.0",
> "title": "Sample REST Application",
> "contact": {
> "name": "us...@cxf.apache.org"
> },
> "license": {
> "name": "Apache 2.0 License",
> "url": "http://www.apache.org/licenses/LICENSE-2.0.html";
> }
> },
> "basePath": "/services",
> "tags": Array[2][
> {
> "name": "internal"
> },
> {
> "name": "test"
> }
> ],
> "paths": {
> "/Internal/internal": {
> "get": {
> "tags": Array[1][
> "internal"
> ],
> "operationId": "getInternal_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> },
> "/test/test": {
> "get": {
> "tags": Array[1][
> "test"
> ],
> "operationId": "getTest_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7563) Non-unique operationIds in swagger.json result in '_1' appended
[
https://issues.apache.org/jira/browse/CXF-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniyar Yeralin updated CXF-7563:
-
Description:
We are using SpringBoot + JAX-RS server and define two service beans that lie
under *2 separate packages*. The jaxrs server is configured with
Swagger2Feature to generate the swagger.json, but the operationIds and thus the
URIs for these services get appended with '_1'.
Sample (Gradle + IDEA) project:
https://github.com/yeralin/ReproduceBug-CXF-7563-
Structure:
!https://i.imgur.com/Q0hh4O3.png!
Sample Java class:
{code:java}
@SpringBootApplication
public class DemoApplication {
@Autowired
private SampleService sampleService;
@Autowired
private SampleServiceInternal sampleServiceInternal;
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
@Bean(destroyMethod = "shutdown")
public SpringBus cxf() {
return new SpringBus();
}
@Bean(destroyMethod = "destroy")
@DependsOn("cxf")
public Server jaxRsServer() {
final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
factory.setServiceBeans(Arrays.asList(sampleService,
sampleServiceInternal));
factory.setBus(cxf());
factory.setAddress("/");
factory.setFeatures(Arrays.asList(configureSwagger()));
return factory.create();
}
private Swagger2Feature configureSwagger() {
Swagger2Feature feature = new Swagger2Feature();
feature.setBasePath("/");
return feature;
}
}
{code}
Swagger.json:
{code:json}
// 20171114155626
// http://localhost:17070/services/swagger.json
{
"swagger": "2.0",
"info": {
"description": "The Application",
"version": "1.0.0",
"title": "Sample REST Application",
"contact": {
"name": "us...@cxf.apache.org"
},
"license": {
"name": "Apache 2.0 License",
"url": "http://www.apache.org/licenses/LICENSE-2.0.html";
}
},
"basePath": "/services",
"tags": Array[2][
{
"name": "internal"
},
{
"name": "test"
}
],
"paths": {
"/Internal/internal": {
"get": {
"tags": Array[1][
"internal"
],
"operationId": "getInternal_1",
"parameters": Array[0][
],
"responses": {
"200": {
"description": "successful operation",
"schema": {
"type": "string"
},
"headers": {
}
}
}
}
},
"/test/test": {
"get": {
"tags": Array[1][
"test"
],
"operationId": "getTest_1",
"parameters": Array[0][
],
"responses": {
"200": {
"description": "successful operation",
"schema": {
"type": "string"
},
"headers": {
}
}
}
}
}
}
}
{code}
was:
We are using SpringBoot + JAX-RS server and define two service beans from *2
separate packages*. The jaxrs server is configured with Swagger2Feature to
generate the swagger.json, but the operationIds and thus the URIs for these
services get appended with '_1'.
Sample (Gradle + IDEA) project:
https://github.com/yeralin/ReproduceBug-CXF-7563-
Structure:
!https://i.imgur.com/Q0hh4O3.png!
Sample Java class:
{code:java}
@SpringBootApplication
public class DemoApplication {
@Autowired
private SampleService sampleService;
@Autowired
private SampleServiceInternal sampleServiceInternal;
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
@Bean(destroyMethod = "shutdown")
public SpringBus cxf() {
return new SpringBus();
}
@Bean(destroyMethod = "destroy")
@DependsOn("cxf")
public Server jaxRsServer() {
final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
factory.setServiceBeans(Arrays.asList(sampleService,
sampleServiceInternal));
factory.setBus(cxf());
factory.setAddress("/");
factory.setFeatures(Arrays.asList(configureSwagger()));
return factory.create();
}
private Swagger2Feature configureSwagger() {
Swagger2Feature feature = new Swagger2Feature();
feature.setBasePath("/");
return feature;
}
}
{code}
Swagger.json:
{code:json}
// 20171114155626
// http://localhost:17070/services/swagger.json
{
"swagger": "2.0",
"info": {
"description": "The Application",
"version": "1.0.0",
"title": "Sample REST Application",
"contact": {
"name": "us...@cxf.apache.org"
},
"license": {
"name": "Apache 2.0 License",
"url": "http://www.apache.org/licenses/LICENSE-2.0.html";
}
},
"basePath": "/services",
"tags":
[jira] [Updated] (CXF-7563) Non-unique operationIds in swagger.json result in '_1' appended
[
https://issues.apache.org/jira/browse/CXF-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniyar Yeralin updated CXF-7563:
-
Description:
We are using SpringBoot + JAX-RS server and define two service beans that lie
under *2 separate packages*. The jaxrs server is configured with
Swagger2Feature to generate the swagger.json, but the operationIds and thus the
URIs for these services get appended with '_1'.
Sample (Gradle + IDEA) project:
https://github.com/yeralin/ReproduceBug-CXF-7563-
Structure:
!https://i.imgur.com/Q0hh4O3.png!
Sample Java class:
{code:java}
@SpringBootApplication
public class DemoApplication {
@Autowired
private SampleService sampleService;
@Autowired
private SampleServiceInternal sampleServiceInternal;
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
@Bean(destroyMethod = "shutdown")
public SpringBus cxf() {
return new SpringBus();
}
@Bean(destroyMethod = "destroy")
@DependsOn("cxf")
public Server jaxRsServer() {
final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
factory.setServiceBeans(Arrays.asList(sampleService,
sampleServiceInternal));
factory.setBus(cxf());
factory.setAddress("/");
factory.setFeatures(Arrays.asList(configureSwagger()));
return factory.create();
}
private Swagger2Feature configureSwagger() {
Swagger2Feature feature = new Swagger2Feature();
feature.setBasePath("/");
return feature;
}
}
{code}
Swagger.json:
{code:javascript}
// 20171114155626
// http://localhost:17070/services/swagger.json
{
"swagger": "2.0",
"info": {
"description": "The Application",
"version": "1.0.0",
"title": "Sample REST Application",
"contact": {
"name": "us...@cxf.apache.org"
},
"license": {
"name": "Apache 2.0 License",
"url": "http://www.apache.org/licenses/LICENSE-2.0.html";
}
},
"basePath": "/services",
"tags": Array[2][
{
"name": "internal"
},
{
"name": "test"
}
],
"paths": {
"/Internal/internal": {
"get": {
"tags": Array[1][
"internal"
],
"operationId": "getInternal_1",
"parameters": Array[0][
],
"responses": {
"200": {
"description": "successful operation",
"schema": {
"type": "string"
},
"headers": {
}
}
}
}
},
"/test/test": {
"get": {
"tags": Array[1][
"test"
],
"operationId": "getTest_1",
"parameters": Array[0][
],
"responses": {
"200": {
"description": "successful operation",
"schema": {
"type": "string"
},
"headers": {
}
}
}
}
}
}
}
{code}
was:
We are using SpringBoot + JAX-RS server and define two service beans that lie
under *2 separate packages*. The jaxrs server is configured with
Swagger2Feature to generate the swagger.json, but the operationIds and thus the
URIs for these services get appended with '_1'.
Sample (Gradle + IDEA) project:
https://github.com/yeralin/ReproduceBug-CXF-7563-
Structure:
!https://i.imgur.com/Q0hh4O3.png!
Sample Java class:
{code:java}
@SpringBootApplication
public class DemoApplication {
@Autowired
private SampleService sampleService;
@Autowired
private SampleServiceInternal sampleServiceInternal;
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
@Bean(destroyMethod = "shutdown")
public SpringBus cxf() {
return new SpringBus();
}
@Bean(destroyMethod = "destroy")
@DependsOn("cxf")
public Server jaxRsServer() {
final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
factory.setServiceBeans(Arrays.asList(sampleService,
sampleServiceInternal));
factory.setBus(cxf());
factory.setAddress("/");
factory.setFeatures(Arrays.asList(configureSwagger()));
return factory.create();
}
private Swagger2Feature configureSwagger() {
Swagger2Feature feature = new Swagger2Feature();
feature.setBasePath("/");
return feature;
}
}
{code}
Swagger.json:
{code:json}
// 20171114155626
// http://localhost:17070/services/swagger.json
{
"swagger": "2.0",
"info": {
"description": "The Application",
"version": "1.0.0",
"title": "Sample REST Application",
"contact": {
"name": "us...@cxf.apache.org"
},
"license": {
"name": "Apache 2.0 License",
"url": "http://www.apache.org/licenses/LICENSE-2.0.html";
}
},
"basePath": "/serv
[jira] [Comment Edited] (CXF-7563) Non-unique operationIds in swagger.json result in '_1' appended
[
https://issues.apache.org/jira/browse/CXF-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16252179#comment-16252179
]
Daniyar Yeralin edited comment on CXF-7563 at 11/14/17 9:24 PM:
Interesting observation: when beans' classes are placed under one package (i.e.
put both SampleService and SampleServiceInternal under
`reproduce.bug.demo.service` package), URI/OperationId will be rendered
normally (without '_1').
was (Author: daniyar94):
Interesting observation: when beans' classes are placed under one package (i.e.
put both SampleService and SampleServiceInternal under
`reproduce.bug.demo.service` package), URI will be rendered fine (without '_1').
> Non-unique operationIds in swagger.json result in '_1' appended
> ---
>
> Key: CXF-7563
> URL: https://issues.apache.org/jira/browse/CXF-7563
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.11
> Environment: Tested on two systems:
> 1) Darwin 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017;
> root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64
> 2) Linux 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64
> x86_64 x86_64 GNU/Linux
>Reporter: Daniyar Yeralin
>Priority: Minor
>
> We are using SpringBoot + JAX-RS server and define two service beans that lie
> under *2 separate packages*. The jaxrs server is configured with
> Swagger2Feature to generate the swagger.json, but the operationIds and thus
> the URIs for these services get appended with '_1'.
> Sample (Gradle + IDEA) project:
> https://github.com/yeralin/ReproduceBug-CXF-7563-
> Structure:
> !https://i.imgur.com/Q0hh4O3.png!
> Sample Java class:
> {code:java}
> @SpringBootApplication
> public class DemoApplication {
> @Autowired
> private SampleService sampleService;
> @Autowired
> private SampleServiceInternal sampleServiceInternal;
> public static void main(String[] args) {
> SpringApplication.run(DemoApplication.class, args);
> }
> @Bean(destroyMethod = "shutdown")
> public SpringBus cxf() {
> return new SpringBus();
> }
> @Bean(destroyMethod = "destroy")
> @DependsOn("cxf")
> public Server jaxRsServer() {
> final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
> factory.setServiceBeans(Arrays.asList(sampleService,
> sampleServiceInternal));
> factory.setBus(cxf());
> factory.setAddress("/");
> factory.setFeatures(Arrays.asList(configureSwagger()));
> return factory.create();
> }
> private Swagger2Feature configureSwagger() {
> Swagger2Feature feature = new Swagger2Feature();
> feature.setBasePath("/");
> return feature;
> }
> }
> {code}
> Swagger.json:
> {code:javascript}
> // 20171114155626
> // http://localhost:17070/services/swagger.json
> {
> "swagger": "2.0",
> "info": {
> "description": "The Application",
> "version": "1.0.0",
> "title": "Sample REST Application",
> "contact": {
> "name": "us...@cxf.apache.org"
> },
> "license": {
> "name": "Apache 2.0 License",
> "url": "http://www.apache.org/licenses/LICENSE-2.0.html";
> }
> },
> "basePath": "/services",
> "tags": Array[2][
> {
> "name": "internal"
> },
> {
> "name": "test"
> }
> ],
> "paths": {
> "/Internal/internal": {
> "get": {
> "tags": Array[1][
> "internal"
> ],
> "operationId": "getInternal_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> },
> "/test/test": {
> "get": {
> "tags": Array[1][
> "test"
> ],
> "operationId": "getTest_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7563) Non-unique operationIds in swagger.json result in '_1' appended
[
https://issues.apache.org/jira/browse/CXF-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniyar Yeralin updated CXF-7563:
-
Description:
We are using SpringBoot + JAX-RS server and define two service beans that lie
under *2 separate packages*. The jaxrs server is configured with
Swagger2Feature to generate the swagger.json, but the operationIds and thus the
URIs for these services get appended with '_1'.
Sample (Gradle + IDEA) project:
https://github.com/yeralin/ReproduceBug-CXF-7563-
Structure:
!https://i.imgur.com/Q0hh4O3.png!
Sample Java class:
{code:java}
@SpringBootApplication
public class DemoApplication {
@Autowired
private SampleService sampleService;
@Autowired
private SampleServiceInternal sampleServiceInternal;
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
@Bean(destroyMethod = "shutdown")
public SpringBus cxf() {
return new SpringBus();
}
@Bean(destroyMethod = "destroy")
@DependsOn("cxf")
public Server jaxRsServer() {
final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
factory.setServiceBeans(Arrays.asList(sampleService,
sampleServiceInternal));
factory.setBus(cxf());
factory.setAddress("/");
factory.setFeatures(Arrays.asList(configureSwagger()));
return factory.create();
}
private Swagger2Feature configureSwagger() {
Swagger2Feature feature = new Swagger2Feature();
feature.setBasePath("/");
return feature;
}
}
{code}
Swagger.json:
{code:javascript}
// 20171114155626
// http://localhost:17070/services/swagger.json
{
"swagger": "2.0",
"info": {
"description": "The Application",
"version": "1.0.0",
"title": "Sample REST Application",
"contact": {
"name": "us...@cxf.apache.org"
},
"license": {
"name": "Apache 2.0 License",
"url": "http://www.apache.org/licenses/LICENSE-2.0.html";
}
},
"basePath": "/services",
"tags": Array[2][
{
"name": "internal"
},
{
"name": "test"
}
],
"paths": {
"/Internal/internal": {
"get": {
"tags": Array[1][
"internal"
],
"operationId": "getInternal_1",
"parameters": Array[0][
],
"responses": {
"200": {
"description": "successful operation",
"schema": {
"type": "string"
},
"headers": {
}
}
}
}
},
"/test/test": {
"get": {
"tags": Array[1][
"test"
],
"operationId": "getTest_1",
"parameters": Array[0][
],
"responses": {
"200": {
"description": "successful operation",
"schema": {
"type": "string"
},
"headers": {
}
}
}
}
}
}
}
{code}
Logs at startup:
{code:java}
. ___ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' || .__|_| |_|_| |_\__, | / / / /
=|_|==|___/=/_/_/_/
:: Spring Boot ::(v1.5.8.RELEASE)
2017-11-14 16:25:11.655 INFO 69492 --- [ main]
reproduce.bug.demo.DemoApplication : Starting DemoApplication on
daniyars-mbp.usny.ibm.com with PID 69492
(/Users/Daniyar.Yeralin/Repositories/demo/out/production/classes started by
Daniyar.Yeralin in /Users/Daniyar.Yeralin/Repositories/demo)
2017-11-14 16:25:11.657 INFO 69492 --- [ main]
reproduce.bug.demo.DemoApplication : The following profiles are active:
reactive
2017-11-14 16:25:11.714 INFO 69492 --- [ main]
ationConfigEmbeddedWebApplicationContext : Refreshing
org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext@6af93788:
startup date [Tue Nov 14 16:25:11 EST 2017]; root of context hierarchy
2017-11-14 16:25:12.893 INFO 69492 --- [ main]
s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat initialized with port(s):
17070 (http)
2017-11-14 16:25:12.906 INFO 69492 --- [ main]
o.apache.catalina.core.StandardService : Starting service [Tomcat]
2017-11-14 16:25:12.907 INFO 69492 --- [ main]
org.apache.catalina.core.StandardEngine : Starting Servlet Engine: Apache
Tomcat/8.5.23
2017-11-14 16:25:13.001 INFO 69492 --- [ost-startStop-1]
o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded
WebApplicationContext
2017-11-14 16:25:13.002 INFO 69492 --- [ost-startStop-1]
o.s.web.context.ContextLoader: Root WebApplicationContext:
initialization completed in 1292 ms
2017-11-14 16:25:13.286 INFO 69492 --- [ost-startStop-1]
o.s.b.w.servlet.Se
[jira] [Resolved] (CXF-7563) Non-unique operationIds in swagger.json result in '_1' appended
[
https://issues.apache.org/jira/browse/CXF-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniyar Yeralin resolved CXF-7563.
--
Resolution: Fixed
Fix Version/s: 3.2.1
The issue, apparently, is no longer present under 3.2.1 Apache-CXF version.
> Non-unique operationIds in swagger.json result in '_1' appended
> ---
>
> Key: CXF-7563
> URL: https://issues.apache.org/jira/browse/CXF-7563
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.11
> Environment: Tested on two systems:
> 1) Darwin 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017;
> root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64
> 2) Linux 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64
> x86_64 x86_64 GNU/Linux
>Reporter: Daniyar Yeralin
>Priority: Minor
> Fix For: 3.2.1
>
>
> We are using SpringBoot + JAX-RS server and define two service beans that lie
> under *2 separate packages*. The jaxrs server is configured with
> Swagger2Feature to generate the swagger.json, but the operationIds and thus
> the URIs for these services get appended with '_1'.
> Sample (Gradle + IDEA) project:
> https://github.com/yeralin/ReproduceBug-CXF-7563-
> Structure:
> !https://i.imgur.com/Q0hh4O3.png!
> Sample Java class:
> {code:java}
> @SpringBootApplication
> public class DemoApplication {
> @Autowired
> private SampleService sampleService;
> @Autowired
> private SampleServiceInternal sampleServiceInternal;
> public static void main(String[] args) {
> SpringApplication.run(DemoApplication.class, args);
> }
> @Bean(destroyMethod = "shutdown")
> public SpringBus cxf() {
> return new SpringBus();
> }
> @Bean(destroyMethod = "destroy")
> @DependsOn("cxf")
> public Server jaxRsServer() {
> final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
> factory.setServiceBeans(Arrays.asList(sampleService,
> sampleServiceInternal));
> factory.setBus(cxf());
> factory.setAddress("/");
> factory.setFeatures(Arrays.asList(configureSwagger()));
> return factory.create();
> }
> private Swagger2Feature configureSwagger() {
> Swagger2Feature feature = new Swagger2Feature();
> feature.setBasePath("/");
> return feature;
> }
> }
> {code}
> Swagger.json:
> {code:javascript}
> // 20171114155626
> // http://localhost:17070/services/swagger.json
> {
> "swagger": "2.0",
> "info": {
> "description": "The Application",
> "version": "1.0.0",
> "title": "Sample REST Application",
> "contact": {
> "name": "us...@cxf.apache.org"
> },
> "license": {
> "name": "Apache 2.0 License",
> "url": "http://www.apache.org/licenses/LICENSE-2.0.html";
> }
> },
> "basePath": "/services",
> "tags": Array[2][
> {
> "name": "internal"
> },
> {
> "name": "test"
> }
> ],
> "paths": {
> "/Internal/internal": {
> "get": {
> "tags": Array[1][
> "internal"
> ],
> "operationId": "getInternal_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> },
> "/test/test": {
> "get": {
> "tags": Array[1][
> "test"
> ],
> "operationId": "getTest_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> }
> }
> }
> {code}
> Logs at startup:
> {code:java}
> . ___ _ _
> /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
> ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
> \\/ ___)| |_)| | | | | || (_| | ) ) ) )
> ' || .__|_| |_|_| |_\__, | / / / /
> =|_|==|___/=/_/_/_/
> :: Spring Boot ::(v1.5.8.RELEASE)
> 2017-11-14 16:25:11.655 INFO 69492 --- [ main]
> reproduce.bug.demo.DemoApplication : Starting DemoApplication on
> daniyars-mbp.usny.ibm.com with PID 69492
> (/Users/Daniyar.Yeralin/Repositories/demo/out/production/classes started by
> Daniyar.Yeralin in /Users/Daniyar.Yeralin/Repositories/demo)
> 2017-11-14 16:25:11.657 INFO 69492 --- [ main]
> reproduce.bug.demo.DemoApplication : The following profiles are active:
> reactive
> 2017-11-14 1
[jira] [Commented] (CXF-7563) Non-unique operationIds in swagger.json result in '_1' appended
[
https://issues.apache.org/jira/browse/CXF-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16252226#comment-16252226
]
Sergey Beryozkin commented on CXF-7563:
---
Np, perhaps a newer Swagger version which has made a difference...
> Non-unique operationIds in swagger.json result in '_1' appended
> ---
>
> Key: CXF-7563
> URL: https://issues.apache.org/jira/browse/CXF-7563
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.11
> Environment: Tested on two systems:
> 1) Darwin 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017;
> root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64
> 2) Linux 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64
> x86_64 x86_64 GNU/Linux
>Reporter: Daniyar Yeralin
>Priority: Minor
> Fix For: 3.2.1
>
>
> We are using SpringBoot + JAX-RS server and define two service beans that lie
> under *2 separate packages*. The jaxrs server is configured with
> Swagger2Feature to generate the swagger.json, but the operationIds and thus
> the URIs for these services get appended with '_1'.
> Sample (Gradle + IDEA) project:
> https://github.com/yeralin/ReproduceBug-CXF-7563-
> Structure:
> !https://i.imgur.com/Q0hh4O3.png!
> Sample Java class:
> {code:java}
> @SpringBootApplication
> public class DemoApplication {
> @Autowired
> private SampleService sampleService;
> @Autowired
> private SampleServiceInternal sampleServiceInternal;
> public static void main(String[] args) {
> SpringApplication.run(DemoApplication.class, args);
> }
> @Bean(destroyMethod = "shutdown")
> public SpringBus cxf() {
> return new SpringBus();
> }
> @Bean(destroyMethod = "destroy")
> @DependsOn("cxf")
> public Server jaxRsServer() {
> final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
> factory.setServiceBeans(Arrays.asList(sampleService,
> sampleServiceInternal));
> factory.setBus(cxf());
> factory.setAddress("/");
> factory.setFeatures(Arrays.asList(configureSwagger()));
> return factory.create();
> }
> private Swagger2Feature configureSwagger() {
> Swagger2Feature feature = new Swagger2Feature();
> feature.setBasePath("/");
> return feature;
> }
> }
> {code}
> Swagger.json:
> {code:javascript}
> // 20171114155626
> // http://localhost:17070/services/swagger.json
> {
> "swagger": "2.0",
> "info": {
> "description": "The Application",
> "version": "1.0.0",
> "title": "Sample REST Application",
> "contact": {
> "name": "us...@cxf.apache.org"
> },
> "license": {
> "name": "Apache 2.0 License",
> "url": "http://www.apache.org/licenses/LICENSE-2.0.html";
> }
> },
> "basePath": "/services",
> "tags": Array[2][
> {
> "name": "internal"
> },
> {
> "name": "test"
> }
> ],
> "paths": {
> "/Internal/internal": {
> "get": {
> "tags": Array[1][
> "internal"
> ],
> "operationId": "getInternal_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> },
> "/test/test": {
> "get": {
> "tags": Array[1][
> "test"
> ],
> "operationId": "getTest_1",
> "parameters": Array[0][
>
> ],
> "responses": {
> "200": {
> "description": "successful operation",
> "schema": {
> "type": "string"
> },
> "headers": {
>
> }
> }
> }
> }
> }
> }
> }
> {code}
> Logs at startup:
> {code:java}
> . ___ _ _
> /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
> ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
> \\/ ___)| |_)| | | | | || (_| | ) ) ) )
> ' || .__|_| |_|_| |_\__, | / / / /
> =|_|==|___/=/_/_/_/
> :: Spring Boot ::(v1.5.8.RELEASE)
> 2017-11-14 16:25:11.655 INFO 69492 --- [ main]
> reproduce.bug.demo.DemoApplication : Starting DemoApplication on
> daniyars-mbp.usny.ibm.com with PID 69492
> (/Users/Daniyar.Yeralin/Repositories/demo/out/production/classes started by
> Daniyar.Yeralin in /Users/Daniyar.Yeralin/Repositories/demo)
> 2017-11-14 16:25:11.657 INFO 69492 --- [ main]
> reproduce.bug.demo.DemoApplication : The following profiles are active:
> reactive
> 2017-11-14 16:
[jira] [Assigned] (CXF-7564) codegen-plugin fails on wsdl2java goal
[
https://issues.apache.org/jira/browse/CXF-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-7564:
-
Assignee: Freeman Fang
> codegen-plugin fails on wsdl2java goal
> --
>
> Key: CXF-7564
> URL: https://issues.apache.org/jira/browse/CXF-7564
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 3.2.1
> Environment: {code}
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T09:58:13+02:00)
> Maven home: /opt/apache/apache-maven
> Java version: 1.8.0_151, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_151/jre
> Default locale: sk_SK, platform encoding: UTF-8
> OS name: "linux", version: "4.13.11-1-default", arch: "amd64", family: "unix"
> {code}
>Reporter: Michal Hlavac
>Assignee: Freeman Fang
> Attachments: wsdl-example.zip
>
>
> cxf-codegen-plugin fails everytime when running `wsdl2java` goal with error:
> {code}
> Execution generate-wsdl of goal
> org.apache.cxf:cxf-codegen-plugin:3.2.1:wsdl2java failed: Could not find
> jaxws frontend within classpath
> {code}
> Sample project to reproduce issue in attachment. It works if you change
> plugin version to 3.2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7564) codegen-plugin fails on wsdl2java goal
[
https://issues.apache.org/jira/browse/CXF-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16252857#comment-16252857
]
Freeman Fang commented on CXF-7564:
---
Hi Michal,
I can't reproduce this anyway. Always works for me.
Could you please run "mvn clean install -X" and append the output here?
Freeman
> codegen-plugin fails on wsdl2java goal
> --
>
> Key: CXF-7564
> URL: https://issues.apache.org/jira/browse/CXF-7564
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 3.2.1
> Environment: {code}
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T09:58:13+02:00)
> Maven home: /opt/apache/apache-maven
> Java version: 1.8.0_151, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_151/jre
> Default locale: sk_SK, platform encoding: UTF-8
> OS name: "linux", version: "4.13.11-1-default", arch: "amd64", family: "unix"
> {code}
>Reporter: Michal Hlavac
>Assignee: Freeman Fang
> Attachments: wsdl-example.zip
>
>
> cxf-codegen-plugin fails everytime when running `wsdl2java` goal with error:
> {code}
> Execution generate-wsdl of goal
> org.apache.cxf:cxf-codegen-plugin:3.2.1:wsdl2java failed: Could not find
> jaxws frontend within classpath
> {code}
> Sample project to reproduce issue in attachment. It works if you change
> plugin version to 3.2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7564) codegen-plugin fails on wsdl2java goal
[
https://issues.apache.org/jira/browse/CXF-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang updated CXF-7564:
--
Attachment: logging.properties
> codegen-plugin fails on wsdl2java goal
> --
>
> Key: CXF-7564
> URL: https://issues.apache.org/jira/browse/CXF-7564
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 3.2.1
> Environment: {code}
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T09:58:13+02:00)
> Maven home: /opt/apache/apache-maven
> Java version: 1.8.0_151, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_151/jre
> Default locale: sk_SK, platform encoding: UTF-8
> OS name: "linux", version: "4.13.11-1-default", arch: "amd64", family: "unix"
> {code}
>Reporter: Michal Hlavac
>Assignee: Freeman Fang
> Attachments: logging.properties, wsdl-example.zip
>
>
> cxf-codegen-plugin fails everytime when running `wsdl2java` goal with error:
> {code}
> Execution generate-wsdl of goal
> org.apache.cxf:cxf-codegen-plugin:3.2.1:wsdl2java failed: Could not find
> jaxws frontend within classpath
> {code}
> Sample project to reproduce issue in attachment. It works if you change
> plugin version to 3.2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CXF-7564) codegen-plugin fails on wsdl2java goal
[
https://issues.apache.org/jira/browse/CXF-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16252857#comment-16252857
]
Freeman Fang edited comment on CXF-7564 at 11/15/17 2:52 AM:
-
Hi Michal,
I can't reproduce this anyway. Always works for me.
I just appended a logging.properties. Could you please use
mvn clean install -Djava.util.logging.config.file=pathto/logging.properties
to run and append the log here?
You can find java0(or other number).log file in your user home folder.
Freeman
was (Author: ffang):
Hi Michal,
I can't reproduce this anyway. Always works for me.
Could you please run "mvn clean install -X" and append the output here?
Freeman
> codegen-plugin fails on wsdl2java goal
> --
>
> Key: CXF-7564
> URL: https://issues.apache.org/jira/browse/CXF-7564
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 3.2.1
> Environment: {code}
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T09:58:13+02:00)
> Maven home: /opt/apache/apache-maven
> Java version: 1.8.0_151, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_151/jre
> Default locale: sk_SK, platform encoding: UTF-8
> OS name: "linux", version: "4.13.11-1-default", arch: "amd64", family: "unix"
> {code}
>Reporter: Michal Hlavac
>Assignee: Freeman Fang
> Attachments: logging.properties, wsdl-example.zip
>
>
> cxf-codegen-plugin fails everytime when running `wsdl2java` goal with error:
> {code}
> Execution generate-wsdl of goal
> org.apache.cxf:cxf-codegen-plugin:3.2.1:wsdl2java failed: Could not find
> jaxws frontend within classpath
> {code}
> Sample project to reproduce issue in attachment. It works if you change
> plugin version to 3.2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CXF-7565) Verification of feature cxf-ws-security failure
Freeman Fang created CXF-7565: - Summary: Verification of feature cxf-ws-security failure Key: CXF-7565 URL: https://issues.apache.org/jira/browse/CXF-7565 Project: CXF Issue Type: Bug Reporter: Freeman Fang [ERROR] Feature resolution failed for [cxf-ws-security/3.2.2.SNAPSHOT] [ERROR] Message: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=cxf-ws-security; type=karaf.feature; version=3.2.2.SNAPSHOT; filter:="(&(osgi.identity=cxf-ws-security)(type=karaf.feature)(version>=3.2.2.SNAPSHOT))" [caused by: Unable to resolve cxf-ws-security/3.2.2.SNAPSHOT: missing requirement [cxf-ws-security/3.2.2.SNAPSHOT] osgi.identity; osgi.identity=org.apache.cxf.cxf-rt-ws-security; type=osgi.bundle; version="[3.2.2.SNAPSHOT,3.2.2.SNAPSHOT]"; resolution:=mandatory [caused by: Unable to resolve org.apache.cxf.cxf-rt-ws-security/3.2.2.SNAPSHOT: missing requirement [org.apache.cxf.cxf-rt-ws-security/3.2.2.SNAPSHOT] osgi.wiring.package; filter:="(&(osgi.wiring.package=com.ctc.wstx.api)(version>=4.4.0)(!(version>=5.0.0)))"]] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (CXF-7565) Verification of feature cxf-ws-security failure
[ https://issues.apache.org/jira/browse/CXF-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-7565: - Assignee: Freeman Fang > Verification of feature cxf-ws-security failure > --- > > Key: CXF-7565 > URL: https://issues.apache.org/jira/browse/CXF-7565 > Project: CXF > Issue Type: Bug > Components: OSGi >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 3.2.2 > > > [ERROR] Feature resolution failed for [cxf-ws-security/3.2.2.SNAPSHOT] > [ERROR] Message: Unable to resolve root: missing requirement [root] > osgi.identity; osgi.identity=cxf-ws-security; type=karaf.feature; > version=3.2.2.SNAPSHOT; > filter:="(&(osgi.identity=cxf-ws-security)(type=karaf.feature)(version>=3.2.2.SNAPSHOT))" > [caused by: Unable to resolve cxf-ws-security/3.2.2.SNAPSHOT: missing > requirement [cxf-ws-security/3.2.2.SNAPSHOT] osgi.identity; > osgi.identity=org.apache.cxf.cxf-rt-ws-security; type=osgi.bundle; > version="[3.2.2.SNAPSHOT,3.2.2.SNAPSHOT]"; resolution:=mandatory [caused by: > Unable to resolve org.apache.cxf.cxf-rt-ws-security/3.2.2.SNAPSHOT: missing > requirement [org.apache.cxf.cxf-rt-ws-security/3.2.2.SNAPSHOT] > osgi.wiring.package; > filter:="(&(osgi.wiring.package=com.ctc.wstx.api)(version>=4.4.0)(!(version>=5.0.0)))"]] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CXF-7565) Verification of feature cxf-ws-security failure
[ https://issues.apache.org/jira/browse/CXF-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated CXF-7565: -- Fix Version/s: 3.2.2 Component/s: OSGi > Verification of feature cxf-ws-security failure > --- > > Key: CXF-7565 > URL: https://issues.apache.org/jira/browse/CXF-7565 > Project: CXF > Issue Type: Bug > Components: OSGi >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 3.2.2 > > > [ERROR] Feature resolution failed for [cxf-ws-security/3.2.2.SNAPSHOT] > [ERROR] Message: Unable to resolve root: missing requirement [root] > osgi.identity; osgi.identity=cxf-ws-security; type=karaf.feature; > version=3.2.2.SNAPSHOT; > filter:="(&(osgi.identity=cxf-ws-security)(type=karaf.feature)(version>=3.2.2.SNAPSHOT))" > [caused by: Unable to resolve cxf-ws-security/3.2.2.SNAPSHOT: missing > requirement [cxf-ws-security/3.2.2.SNAPSHOT] osgi.identity; > osgi.identity=org.apache.cxf.cxf-rt-ws-security; type=osgi.bundle; > version="[3.2.2.SNAPSHOT,3.2.2.SNAPSHOT]"; resolution:=mandatory [caused by: > Unable to resolve org.apache.cxf.cxf-rt-ws-security/3.2.2.SNAPSHOT: missing > requirement [org.apache.cxf.cxf-rt-ws-security/3.2.2.SNAPSHOT] > osgi.wiring.package; > filter:="(&(osgi.wiring.package=com.ctc.wstx.api)(version>=4.4.0)(!(version>=5.0.0)))"]] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7565) Verification of feature cxf-ws-security failure
[
https://issues.apache.org/jira/browse/CXF-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16253017#comment-16253017
]
Freeman Fang commented on CXF-7565:
---
need exclude
{code}
org.codehaus.woodstox
woodstox-core-asl
{code}
from dependency chain to ensure the
{code}
com.fasterxml.woodstox
woodstox-core
{code}
is used and hence generate Import-Package com.ctc.wstx with expected version
range
> Verification of feature cxf-ws-security failure
> ---
>
> Key: CXF-7565
> URL: https://issues.apache.org/jira/browse/CXF-7565
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 3.2.2
>
>
> [ERROR] Feature resolution failed for [cxf-ws-security/3.2.2.SNAPSHOT]
> [ERROR] Message: Unable to resolve root: missing requirement [root]
> osgi.identity; osgi.identity=cxf-ws-security; type=karaf.feature;
> version=3.2.2.SNAPSHOT;
> filter:="(&(osgi.identity=cxf-ws-security)(type=karaf.feature)(version>=3.2.2.SNAPSHOT))"
> [caused by: Unable to resolve cxf-ws-security/3.2.2.SNAPSHOT: missing
> requirement [cxf-ws-security/3.2.2.SNAPSHOT] osgi.identity;
> osgi.identity=org.apache.cxf.cxf-rt-ws-security; type=osgi.bundle;
> version="[3.2.2.SNAPSHOT,3.2.2.SNAPSHOT]"; resolution:=mandatory [caused by:
> Unable to resolve org.apache.cxf.cxf-rt-ws-security/3.2.2.SNAPSHOT: missing
> requirement [org.apache.cxf.cxf-rt-ws-security/3.2.2.SNAPSHOT]
> osgi.wiring.package;
> filter:="(&(osgi.wiring.package=com.ctc.wstx.api)(version>=4.4.0)(!(version>=5.0.0)))"]]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CXF-7565) Verification of feature cxf-ws-security failure
[ https://issues.apache.org/jira/browse/CXF-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-7565. --- Resolution: Fixed > Verification of feature cxf-ws-security failure > --- > > Key: CXF-7565 > URL: https://issues.apache.org/jira/browse/CXF-7565 > Project: CXF > Issue Type: Bug > Components: OSGi >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 3.2.2 > > > [ERROR] Feature resolution failed for [cxf-ws-security/3.2.2.SNAPSHOT] > [ERROR] Message: Unable to resolve root: missing requirement [root] > osgi.identity; osgi.identity=cxf-ws-security; type=karaf.feature; > version=3.2.2.SNAPSHOT; > filter:="(&(osgi.identity=cxf-ws-security)(type=karaf.feature)(version>=3.2.2.SNAPSHOT))" > [caused by: Unable to resolve cxf-ws-security/3.2.2.SNAPSHOT: missing > requirement [cxf-ws-security/3.2.2.SNAPSHOT] osgi.identity; > osgi.identity=org.apache.cxf.cxf-rt-ws-security; type=osgi.bundle; > version="[3.2.2.SNAPSHOT,3.2.2.SNAPSHOT]"; resolution:=mandatory [caused by: > Unable to resolve org.apache.cxf.cxf-rt-ws-security/3.2.2.SNAPSHOT: missing > requirement [org.apache.cxf.cxf-rt-ws-security/3.2.2.SNAPSHOT] > osgi.wiring.package; > filter:="(&(osgi.wiring.package=com.ctc.wstx.api)(version>=4.4.0)(!(version>=5.0.0)))"]] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7562) ext.logging: truncated flag not set
[ https://issues.apache.org/jira/browse/CXF-7562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16253068#comment-16253068 ] ASF GitHub Bot commented on CXF-7562: - forsthofer opened a new pull request #340: [CXF-7562] correction for truncated flag URL: https://github.com/apache/cxf/pull/340 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 > ext.logging: truncated flag not set > > > Key: CXF-7562 > URL: https://issues.apache.org/jira/browse/CXF-7562 > Project: CXF > Issue Type: Bug > Components: logging >Affects Versions: 3.1.14, 3.2.1 >Reporter: Franz Forsthofer > Fix For: 3.1.15, 3.2.2 > > > In the ext.logging feature the log event (LogEvent) has the attribute > truncated which indicates whether the logged payloud was trancated or not. > This attribute is not set correctly by the interceptors > - org.apache.cxf.ext.logging.LoggingInInterceptor > - org.apache.cxf.ext.logging.LoggingOutInterceptor > I will add a patch via github. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
