Issues with Attachments: week of 2017-11-27
CXF - Monday, November 27, 2017 4 Issues with Attachments (sorted oldest to newest) [CXF-2712] wsdl2java + jaxb episodes fails to generate service artifacts - Created: 2010-03-12 - Updated: 2017-11-12 - Type: Bug - Fix Versions: [] - Reporter: Marcel Casado - Assigned: Unassigned - Attachments: [cxfWsdl2javaWithEpisodes.jar] - https://issues.apache.org/jira/browse/CXF-2712 [CXF-7388] Problem with MTOM in Camel-CXF - Created: 2017-05-30 - Updated: 2017-11-02 - Type: Bug - Fix Versions: [] - Reporter: Joerg Kessler - Assigned: Unassigned - Attachments: [cxf.client.test.sync.junit.ext.zip] - https://issues.apache.org/jira/browse/CXF-7388 [CXF-7527] JAXRS UriInfo.getMatchedUris does return matched URIs twice for sub resources - Created: 2017-10-10 - Updated: 2017-11-14 - Type: Bug - Fix Versions: [] - Reporter: Lenoire - Assigned: Unassigned - Attachments: [uriinfo-issues.jar] - https://issues.apache.org/jira/browse/CXF-7527 [CXF-7552] wsdl2java fails on SwA WSDL using SOAP 1.2 Bindings - Created: 2017-11-07 - Updated: 2017-11-21 - Type: Bug - Fix Versions: [] - Reporter: Russell Orf - Assigned: Unassigned - Attachments: [xml_attachments.wsdl] - https://issues.apache.org/jira/browse/CXF-7552
[jira] [Commented] (CXF-7525) Add support for Swagger 2.0 (OpenApi Spec 3.0)
[ https://issues.apache.org/jira/browse/CXF-7525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266625#comment-16266625 ] Sergey Beryozkin commented on CXF-7525: --- +1 to adding cxf-rt-rs-service-description-openapi and OpenApiFeature. My only reservation here that it will probably be a complete re-write of Swagger2Feature. FYI, I started experimenting last week with transforming JSON produced by Swagger2Feature into OpenApi JSON. I might add a filter option to the existing Swagger2Feature... > Add support for Swagger 2.0 (OpenApi Spec 3.0) > -- > > Key: CXF-7525 > URL: https://issues.apache.org/jira/browse/CXF-7525 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko > > The OpenApi spec 3.0 has been released recently. Swagger 2.0 (currently in > rc-2) should released in a few months (Dec/Jan). It would be great to have > the integration available in CXF as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[ https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266644#comment-16266644 ] Sergey Beryozkin commented on CXF-7571: --- Indeed, if we keep patching to support CDI-specific cases where @Context does not work then it will only keep us further away from achieving "@Inject UriInfo ui", etc. IMHO all the existing injection code has to be moved to a default strategy first, without worrying about CDI/etc. Once it's done and the confidence is there it does work, then a CDI specific strategy will cleanly replace the default strategy when needed. > Revamp of the CXF injection implementation > --- > > Key: CXF-7571 > URL: https://issues.apache.org/jira/browse/CXF-7571 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko > > As more deep integration with CDI revealed, there are complexities in > bringing together `@Context`- and `@Inject`-based injections. Encapsulating > CXF injection implementation and than delegating the hard work to appropriate > strategy (CDI, Spring, ...) would be the right solution to address the > problem at its roots. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7525) Add support for Swagger 2.0 (OpenApi Spec 3.0)
[ https://issues.apache.org/jira/browse/CXF-7525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266682#comment-16266682 ] Andriy Redko commented on CXF-7525: --- Yeah, cxf-rt-rs-service-description-openapi sounds good. Indeed, the OpenAPI 3.0 is very different from Swagger 2.x spec, we would need to rewrite most of what we have for Swagger (I believe). I think Swagger 2.0 is very close to official release, in months or two it should be out :) > Add support for Swagger 2.0 (OpenApi Spec 3.0) > -- > > Key: CXF-7525 > URL: https://issues.apache.org/jira/browse/CXF-7525 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko > > The OpenApi spec 3.0 has been released recently. Swagger 2.0 (currently in > rc-2) should released in a few months (Dec/Jan). It would be great to have > the integration available in CXF as well. -- 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=16266686#comment-16266686
]
ASF GitHub Bot commented on CXF-7544:
-
reta closed pull request #346: CXF-7544: Support @Context-based injection into
proxied CDI beans
URL: https://github.com/apache/cxf/pull/346
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/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiClassUnwrapper.java
b/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiClassUnwrapper.java
index c32e6690981..ac54da90535 100644
--- a/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiClassUnwrapper.java
+++ b/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*");
CdiClassUnwrapper() {
diff --git
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/FilterProviderInfo.java
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/FilterProviderInfo.java
index f57401e635b..0f04b5e94c8 100644
---
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/FilterProviderInfo.java
+++
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/FilterProviderInfo.java
@@ -32,18 +32,23 @@
private Map, Integer> supportedContracts;
private boolean dynamic;
-public FilterProviderInfo(T provider,
+public FilterProviderInfo(Class resourceClass,
+ Class serviceClass,
+ T provider,
Bus bus,
Map, Integer> supportedContracts) {
-this(provider, bus, ProviderFactory.DEFAULT_FILTER_NAME_BINDING,
false, supportedContracts);
+this(resourceClass, serviceClass, provider, bus,
ProviderFactory.DEFAULT_FILTER_NAME_BINDING,
+false, supportedContracts);
}
-public FilterProviderInfo(T provider,
+public FilterProviderInfo(Class resourceClass,
+ Class serviceClass,
+ T provider,
Bus bus,
String nameBinding,
boolean dynamic,
Map, Integer> supportedContracts) {
-super(provider, bus, true);
+super(resourceClass, serviceClass, provider, bus, true);
this.nameBinding = Collections.singleton(nameBinding);
this.supportedContracts = supportedContracts;
this.dynamic = dynamic;
diff --git
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/ProviderInfo.java
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/ProviderInfo.java
index 234a76091e9..73e7147b482 100644
---
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/ProviderInfo.java
+++
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/ProviderInfo.java
@@ -35,7 +35,16 @@ public ProviderInfo(T provider, Bus bus, boolean custom) {
}
public ProviderInfo(T provider, Bus bus, boolean checkContexts, boolean
custom) {
-this(provider, null, bus, checkContexts, custom);
+this(provider.getClass(), provider.getClass(), provider, bus, true,
custom);
+}
+
+public ProviderInfo(Class resourceClass, Class serviceClass, T
provider, Bus bus, boolean custom) {
+this(resourceClass, serviceClass, provider, bus, true, custom);
+}
+
+public ProviderInfo(Class resourceClass, Class serviceClass, T
provider, Bus bus,
+boolean checkContexts, boolean custom) {
+this(resourceClass, serviceClass, provider, null, bus, checkContexts,
custom);
}
public ProviderInfo(T provider,
@@ -45,14 +54,24 @@ public ProviderInfo(T provider,
this(provider, constructorProxies, bus, true, custom);
}
+public ProviderInfo(Class resourceClass,
+Class serviceClass,
+T provider,
+Map, ThreadLocalProxy> constructorProxies,
+Bus bus,
+boolean checkContexts,
+boolean custom) {
+super(resourceClass, serviceClass, true, checkContexts,
constructorProxies, bus, provider);
+this.provider = provider;
+this.custom = cus
[jira] [Resolved] (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:all-tabpanel
]
Andriy Redko resolved CXF-7544.
---
Resolution: Won't 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.
> h3. Update
> Addressing the issue requires a significant revamp of the CXF injection
> mechanism, it is turned out to be hard to solve even with @AroundConstruct
> or, previously, providing custom @Context injectors. The good news is that
> the field-based injection could be easily workarounded using setter-based
> injection.
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> private ResourceInfo resourceInfo;
>
> @Context
> public void setResourceInfo(ResourceInfo resourceInfo) {
> this.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}
> The work related to CXF injection refactoring is tracked under CXF-7571
--
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=16266732#comment-16266732
]
ASF GitHub Bot commented on CXF-7544:
-
sberyozkin commented on issue #346: CXF-7544: Support @Context-based injection
into proxied CDI beans
URL: https://github.com/apache/cxf/pull/346#issuecomment-347167548
Hi Andriy
Why this has been merged ?
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.
> h3. Update
> Addressing the issue requires a significant revamp of the CXF injection
> mechanism, it is turned out to be hard to solve even with @AroundConstruct
> or, previously, providing custom @Context injectors. The good news is that
> the field-based injection could be easily workarounded using setter-based
> injection.
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> private ResourceInfo resourceInfo;
>
> @Context
> public void setResourceInfo(ResourceInfo resourceInfo) {
> this.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}
> The work related to CXF injection refactoring is tracked under CXF-7571
--
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=16266738#comment-16266738
]
ASF GitHub Bot commented on CXF-7544:
-
sberyozkin commented on issue #346: CXF-7544: Support @Context-based injection
into proxied CDI beans
URL: https://github.com/apache/cxf/pull/346#issuecomment-347170207
Sorry, just got confused given that the JIRA issue itself was closed as
Won't fix
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.
> h3. Update
> Addressing the issue requires a significant revamp of the CXF injection
> mechanism, it is turned out to be hard to solve even with @AroundConstruct
> or, previously, providing custom @Context injectors. The good news is that
> the field-based injection could be easily workarounded using setter-based
> injection.
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> private ResourceInfo resourceInfo;
>
> @Context
> public void setResourceInfo(ResourceInfo resourceInfo) {
> this.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}
> The work related to CXF injection refactoring is tracked under CXF-7571
--
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=16266761#comment-16266761
]
ASF GitHub Bot commented on CXF-7544:
-
sberyozkin commented on issue #346: CXF-7544: Support @Context-based injection
into proxied CDI beans
URL: https://github.com/apache/cxf/pull/346#issuecomment-347175586
Andriy, will it make sense to merge to 3.1.x as well ?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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.
> h3. Update
> Addressing the issue requires a significant revamp of the CXF injection
> mechanism, it is turned out to be hard to solve even with @AroundConstruct
> or, previously, providing custom @Context injectors. The good news is that
> the field-based injection could be easily workarounded using setter-based
> injection.
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> private ResourceInfo resourceInfo;
>
> @Context
> public void setResourceInfo(ResourceInfo resourceInfo) {
> this.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}
> The work related to CXF injection refactoring is tracked under CXF-7571
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7525) Add support for Swagger 2.0 (OpenApi Spec 3.0)
[ https://issues.apache.org/jira/browse/CXF-7525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266792#comment-16266792 ] Sergey Beryozkin commented on CXF-7525: --- Hey Andriy, Indeed, and it might take awhile to ensure the expectations of CXF Swagger2Feature users are also met :-), it took us awhile, a couple of years I'd say, to ensure various CXF deployment scenarios are covered. But hope the transition will be quite smooth and much faster. Dennis, if you have some spare time, please experiment with the latest RCs :-) In meantime, I'm going to continue with working the filter converter which can be used as an intermediate solution and which will also might appeal to the cases where Swagger2Feature is already in production, and I can think of at least one such case... > Add support for Swagger 2.0 (OpenApi Spec 3.0) > -- > > Key: CXF-7525 > URL: https://issues.apache.org/jira/browse/CXF-7525 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko > > The OpenApi spec 3.0 has been released recently. Swagger 2.0 (currently in > rc-2) should released in a few months (Dec/Jan). It would be great to have > the integration available in CXF as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CXF-7525) Add support for Swagger 2.0 (OpenApi Spec 3.0)
[ https://issues.apache.org/jira/browse/CXF-7525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266792#comment-16266792 ] Sergey Beryozkin edited comment on CXF-7525 at 11/27/17 1:21 PM: - Hey Andriy, Indeed, and it might take awhile to ensure the expectations of CXF Swagger2Feature users are also met :-), it took us awhile, a couple of years I'd say, to ensure various CXF deployment scenarios are covered. But hope the transition will be quite smooth and much faster. Dennis, if you have some spare time, please experiment with the latest RCs :-) In meantime, I'm going to continue with working on the filter converter which can be used as an intermediate solution and which will also might appeal to the cases where Swagger2Feature is already in production, and I can think of at least one such case... was (Author: sergey_beryozkin): Hey Andriy, Indeed, and it might take awhile to ensure the expectations of CXF Swagger2Feature users are also met :-), it took us awhile, a couple of years I'd say, to ensure various CXF deployment scenarios are covered. But hope the transition will be quite smooth and much faster. Dennis, if you have some spare time, please experiment with the latest RCs :-) In meantime, I'm going to continue with working the filter converter which can be used as an intermediate solution and which will also might appeal to the cases where Swagger2Feature is already in production, and I can think of at least one such case... > Add support for Swagger 2.0 (OpenApi Spec 3.0) > -- > > Key: CXF-7525 > URL: https://issues.apache.org/jira/browse/CXF-7525 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko > > The OpenApi spec 3.0 has been released recently. Swagger 2.0 (currently in > rc-2) should released in a few months (Dec/Jan). It would be great to have > the integration available in CXF as well. -- 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=16266796#comment-16266796
]
ASF GitHub Bot commented on CXF-7544:
-
reta commented on issue #346: CXF-7544: Support @Context-based injection into
proxied CDI beans
URL: https://github.com/apache/cxf/pull/346#issuecomment-347180145
Yeah, sure, I will cherry-pick it to 3.1.x. Did you want to add / comment
before merge? Or confusion is resolved? :-)
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.
> h3. Update
> Addressing the issue requires a significant revamp of the CXF injection
> mechanism, it is turned out to be hard to solve even with @AroundConstruct
> or, previously, providing custom @Context injectors. The good news is that
> the field-based injection could be easily workarounded using setter-based
> injection.
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> private ResourceInfo resourceInfo;
>
> @Context
> public void setResourceInfo(ResourceInfo resourceInfo) {
> this.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}
> The work related to CXF injection refactoring is tracked under CXF-7571
--
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=16266807#comment-16266807
]
ASF GitHub Bot commented on CXF-7544:
-
sberyozkin commented on issue #346: CXF-7544: Support @Context-based injection
into proxied CDI beans
URL: https://github.com/apache/cxf/pull/346#issuecomment-347182060
Hi Andriy, indeed, the fix looks good, it's really about the filter
providers also providing the real and service classes :-), thanks
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.
> h3. Update
> Addressing the issue requires a significant revamp of the CXF injection
> mechanism, it is turned out to be hard to solve even with @AroundConstruct
> or, previously, providing custom @Context injectors. The good news is that
> the field-based injection could be easily workarounded using setter-based
> injection.
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> private ResourceInfo resourceInfo;
>
> @Context
> public void setResourceInfo(ResourceInfo resourceInfo) {
> this.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}
> The work related to CXF injection refactoring is tracked under CXF-7571
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266816#comment-16266816
]
John D. Ament commented on CXF-7571:
yeah, but you have to weigh what the spec is asking for vs what may make sense
to do in a future JAX-RS impl. Its pretty simple IMHO to loop through the
annotated fields and add {{@Inject}} to each {{@Context}} field.
Personally, I think having support for {{@Inject}} for the built in
{{@Context}} objects makes sense. But to solve that, I think it makes the most
sense to just register them as beans and then satisfy what I just described.
You get the added benefit that any CDI bean could inject a {{UriInfo}} for
instance.
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together `@Context`- and `@Inject`-based injections. Encapsulating
> CXF injection implementation and than delegating the hard work to appropriate
> strategy (CDI, Spring, ...) would be the right solution to address the
> problem at its roots.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[ https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266837#comment-16266837 ] Sergey Beryozkin commented on CXF-7571: --- John, are you suggesting to update the code which checks '@Context' to also check '@Inject' ? That may work in the short term I guess, there used to be the code checking @Conext and @Resource... > Revamp of the CXF injection implementation > --- > > Key: CXF-7571 > URL: https://issues.apache.org/jira/browse/CXF-7571 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko > > As more deep integration with CDI revealed, there are complexities in > bringing together `@Context`- and `@Inject`-based injections. Encapsulating > CXF injection implementation and than delegating the hard work to appropriate > strategy (CDI, Spring, ...) would be the right solution to address the > problem at its roots. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[ https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266842#comment-16266842 ] Andriy Redko commented on CXF-7571: --- I think this is what we aim to as well, so the CXF won't be doing the work framework should be doing (and we get rid of any issues caused f.e. by bean proxies, etc). But there are also cases when DI framework is not in place, so the injection still has to work as expected. > Revamp of the CXF injection implementation > --- > > Key: CXF-7571 > URL: https://issues.apache.org/jira/browse/CXF-7571 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko > > As more deep integration with CDI revealed, there are complexities in > bringing together `@Context`- and `@Inject`-based injections. Encapsulating > CXF injection implementation and than delegating the hard work to appropriate > strategy (CDI, Spring, ...) would be the right solution to address the > problem at its roots. -- 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=16266843#comment-16266843
]
ASF GitHub Bot commented on CXF-7544:
-
reta commented on issue #346: CXF-7544: Support @Context-based injection into
proxied CDI beans
URL: https://github.com/apache/cxf/pull/346#issuecomment-347189823
Thanks! Yeah, that's right, also fixing CdiClassUwrapper proxy pattern for
OWB, but aside from that, it is mostly about test cases.
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.
> h3. Update
> Addressing the issue requires a significant revamp of the CXF injection
> mechanism, it is turned out to be hard to solve even with @AroundConstruct
> or, previously, providing custom @Context injectors. The good news is that
> the field-based injection could be easily workarounded using setter-based
> injection.
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> private ResourceInfo resourceInfo;
>
> @Context
> public void setResourceInfo(ResourceInfo resourceInfo) {
> this.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}
> The work related to CXF injection refactoring is tracked under CXF-7571
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266850#comment-16266850
]
John D. Ament commented on CXF-7571:
Sergey, no, that's not what I am suggesting.
In the CDI extension, find any managed bean that declares a {{@Context}}, and
update the underlying {{Annotated}} object to add {{@Inject}} to the
annotations. CDI exposes {{AnnotatedField}}, {{AnnotatedMethod}},
{{AnnotatedParameter}} for these use cases. For instance, if a method param is
annotated {{@Context}} you'll need to add {{@Inject}} to the method. What will
be curious is how to handle {{@Context}} in a service method. I did something
like that recently for a custom event model I was implementing. This would
allow CDI to take over the injection of the field, since it'll have the JSR-330
annotation.
I think Andriy has my point. It makes it so that CXF doesn't have to do
anything (other than register additional beans).
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together `@Context`- and `@Inject`-based injections. Encapsulating
> CXF injection implementation and than delegating the hard work to appropriate
> strategy (CDI, Spring, ...) would be the right solution to address the
> problem at its roots.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[ https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266857#comment-16266857 ] Sergey Beryozkin commented on CXF-7571: --- That sounds good, if a fix like that at the CXF CDI level would enable the support of @Inject for the JAX-RS contexts (which works for Jersey, RestEasy) then it would be massive. Lets start from this enhancement first :-) > Revamp of the CXF injection implementation > --- > > Key: CXF-7571 > URL: https://issues.apache.org/jira/browse/CXF-7571 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko > > As more deep integration with CDI revealed, there are complexities in > bringing together `@Context`- and `@Inject`-based injections. Encapsulating > CXF injection implementation and than delegating the hard work to appropriate > strategy (CDI, Spring, ...) would be the right solution to address the > problem at its roots. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7143) Option for logging SOAP, but without XOP attachments
[ https://issues.apache.org/jira/browse/CXF-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266938#comment-16266938 ] Mohamed Moez MANSOURI commented on CXF-7143: Hello Daniel, can redirect me to a documentation about this please ? Thanks > Option for logging SOAP, but without XOP attachments > > > Key: CXF-7143 > URL: https://issues.apache.org/jira/browse/CXF-7143 > Project: CXF > Issue Type: Wish >Reporter: Marcin GorgoĊ > Fix For: 3.1.11, 3.2.0 > > > As wrote in https://issues.apache.org/jira/browse/CXF-7138 > AbstractLoggingInterceptor may be configured for skipping logging binary > content in multipart message, but when set, it will not log SOAP. > It would be nice to have an option to disable logging binary attachment, but > preserve logging SOAP message. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7016) Update New Logging interceptors to control the logging of binary & multipart payloads
[
https://issues.apache.org/jira/browse/CXF-7016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266944#comment-16266944
]
Mohamed Moez MANSOURI commented on CXF-7016:
Iam using
{code:java}
org.apache.cxf
cxf-rt-features-logging
3.2.1
{code}
And i still have logs of binary parts of a multipart message (image/png) even
if the flag "logBinary" of AbstractLoggingInterceptor is false by default.
Can you help me ? I would like that if that flag is false , it applies also to
the inner parts of a multipart message.
> Update New Logging interceptors to control the logging of binary & multipart
> payloads
> -
>
> Key: CXF-7016
> URL: https://issues.apache.org/jira/browse/CXF-7016
> Project: CXF
> Issue Type: Sub-task
> Components: logging
>Reporter: Sergey Beryozkin
>Assignee: Christian Schneider
>Priority: Minor
> Fix For: 3.1.10, 3.2.0
>
>
> Hi Christian, here is the one:
> The core interceptors turn off the logging of binary data by default (if
> enabled this comes up as a sequence of unreadable characters)
> Proposal: at the very least the new interceptors should disable it by default
> too. The possible improvement would be, in case the binary logging is on, to
> correctly show the byte representations, ex, format then to hex, etc
> Also, the core interceptors do log Multiparts by default - in many cases
> (JAXWS, JAXRS) they can be readable but if a multipart is used to pass a
> binary blob then it also makes sense to let users disable it
> If you'd like I can do an initial sync and then you can improve further as
> you wish
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[ https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16267068#comment-16267068 ] Andriy Redko commented on CXF-7571: --- Yep, sounds like a great plan to move it forward, thanks [~johndament], [~sergey_beryozkin] > Revamp of the CXF injection implementation > --- > > Key: CXF-7571 > URL: https://issues.apache.org/jira/browse/CXF-7571 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko > > As more deep integration with CDI revealed, there are complexities in > bringing together `@Context`- and `@Inject`-based injections. Encapsulating > CXF injection implementation and than delegating the hard work to appropriate > strategy (CDI, Spring, ...) would be the right solution to address the > problem at its roots. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (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:all-tabpanel
]
Andy McCright resolved CXF-7527.
Resolution: Fixed
Assignee: Andy McCright
Fix Version/s: 3.2.2
3.1.15
> 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
>Assignee: Andy McCright
> Fix For: 3.1.15, 3.2.2
>
> 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] [Created] (CXF-7572) OAuth/OIDC endpoints in discovery document contains default ports
gonzalad created CXF-7572:
-
Summary: OAuth/OIDC endpoints in discovery document contains
default ports
Key: CXF-7572
URL: https://issues.apache.org/jira/browse/CXF-7572
Project: CXF
Issue Type: Bug
Affects Versions: 3.1.14
Reporter: gonzalad
OIDC / OAuth documents generated by OidcConfigurationService (or
AuthorizationMetadataService) contains default port information in issuer.
For instance:
{code}
"issuer":"https://authorization-server:443";,
{code}
Also, in previous versions of CXF we could set issuer as an absolute URL.
This is not the case anymore in 3.1.14.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
