[jira] [Created] (CXF-9001) CDI extension not comptible with IBM Semuru
Romain Manni-Bucau created CXF-9001: --- Summary: CDI extension not comptible with IBM Semuru Key: CXF-9001 URL: https://issues.apache.org/jira/browse/CXF-9001 Project: CXF Issue Type: Task Reporter: Romain Manni-Bucau Long story short CXF tries to handle "singleton" by using a set on bean instances which means hashCode will be triggered but semuru not having a native hashcode it is delegated to the instance for normal scoped proxies and at startup the instance does not always exists - context is not always up like for request scoped. Technically this is also an error since deduplication should have happent on the bean to respect the application and not the instance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8732) [regression] activation DataSource requires to run JAXRS
Romain Manni-Bucau created CXF-8732: --- Summary: [regression] activation DataSource requires to run JAXRS Key: CXF-8732 URL: https://issues.apache.org/jira/browse/CXF-8732 Project: CXF Issue Type: Bug Affects Versions: 3.5.3 Reporter: Romain Manni-Bucau Hi, The change in JAXRSUTils makes javax.activation.DataSource loaded whereas we id the work to make activation+jaxb optional in previous releases. Change must be done at [https://github.com/apache/cxf/blob/f48dc57d5bb4a8848f3b4f9ef5cedcfd9d8ab1b7/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L245] likely using this kind of trick https://github.com/apache/cxf/blob/f48dc57d5bb4a8848f3b4f9ef5cedcfd9d8ab1b7/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/ProviderFactory.java#L99 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8732) [regression] activation DataSource requires to run JAXRS
[ https://issues.apache.org/jira/browse/CXF-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated CXF-8732: Description: Hi, The change in JAXRSUTils makes javax.activation.DataSource loaded whereas we did the work to make activation+jaxb optional in previous releases. Change must be done at [https://github.com/apache/cxf/blob/f48dc57d5bb4a8848f3b4f9ef5cedcfd9d8ab1b7/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L245] likely using this kind of trick [https://github.com/apache/cxf/blob/f48dc57d5bb4a8848f3b4f9ef5cedcfd9d8ab1b7/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/ProviderFactory.java#L99] was: Hi, The change in JAXRSUTils makes javax.activation.DataSource loaded whereas we id the work to make activation+jaxb optional in previous releases. Change must be done at [https://github.com/apache/cxf/blob/f48dc57d5bb4a8848f3b4f9ef5cedcfd9d8ab1b7/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L245] likely using this kind of trick https://github.com/apache/cxf/blob/f48dc57d5bb4a8848f3b4f9ef5cedcfd9d8ab1b7/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/ProviderFactory.java#L99 > [regression] activation DataSource requires to run JAXRS > > > Key: CXF-8732 > URL: https://issues.apache.org/jira/browse/CXF-8732 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.3 >Reporter: Romain Manni-Bucau >Priority: Blocker > > Hi, > > The change in JAXRSUTils makes javax.activation.DataSource loaded whereas we > did the work to make activation+jaxb optional in previous releases. > Change must be done at > [https://github.com/apache/cxf/blob/f48dc57d5bb4a8848f3b4f9ef5cedcfd9d8ab1b7/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L245] > likely using this kind of trick > [https://github.com/apache/cxf/blob/f48dc57d5bb4a8848f3b4f9ef5cedcfd9d8ab1b7/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/ProviderFactory.java#L99] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8654) Ensure InputStreamDataSource is optional in JAXRSUtils to be able to run without activation dependency
Romain Manni-Bucau created CXF-8654: --- Summary: Ensure InputStreamDataSource is optional in JAXRSUtils to be able to run without activation dependency Key: CXF-8654 URL: https://issues.apache.org/jira/browse/CXF-8654 Project: CXF Issue Type: Bug Affects Versions: 3.5.0 Reporter: Romain Manni-Bucau -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CXF-8344) org.apache.cxf.jaxrs.utils.AnnotationUtils#getNameBindings does not use ClassUnwrapper
[ https://issues.apache.org/jira/browse/CXF-8344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17255717#comment-17255717 ] Romain Manni-Bucau commented on CXF-8344: - I don't have the case handy anymore but I think OSGi JAXRS whiteboard does not unwrap the class. Typically, setResourceClassesFromBeans is not always called , it is just one potential path where proxies can be seen, so I guess the assumption it is unwrapped can be wrong. I see resource providers and setResourceClasses at least as alternate cases needing some unproxying. I see PerRequestResourceProvider does not handle it for example - but since providers are pluggable I guess it should be handled outside providers actually. > org.apache.cxf.jaxrs.utils.AnnotationUtils#getNameBindings does not use > ClassUnwrapper > -- > > Key: CXF-8344 > URL: https://issues.apache.org/jira/browse/CXF-8344 > Project: CXF > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko >Priority: Major > > ... which leads to miss the whole annotated model with some proxies -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CXF-8344) org.apache.cxf.jaxrs.utils.AnnotationUtils#getNameBindings does not use ClassUnwrapper
[ https://issues.apache.org/jira/browse/CXF-8344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17255690#comment-17255690 ] Romain Manni-Bucau commented on CXF-8344: - Hmm, not sure, OperationResourceInfo does not use the unwrapped method for example, also not sure we can assume ClassResourceInfo uses unwrapped data so think filters can be fine but the other side not. > org.apache.cxf.jaxrs.utils.AnnotationUtils#getNameBindings does not use > ClassUnwrapper > -- > > Key: CXF-8344 > URL: https://issues.apache.org/jira/browse/CXF-8344 > Project: CXF > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko >Priority: Major > > ... which leads to miss the whole annotated model with some proxies -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CXF-8370) org.apache.cxf.rs.security.oauth2.services.RedirectionBasedGrantService#startAuthorization(javax.ws.rs.core.MultivaluedMap) shouldn't req
Romain Manni-Bucau created CXF-8370: --- Summary: org.apache.cxf.rs.security.oauth2.services.RedirectionBasedGrantService#startAuthorization(javax.ws.rs.core.MultivaluedMap) shouldn't require an user Key: CXF-8370 URL: https://issues.apache.org/jira/browse/CXF-8370 Project: CXF Issue Type: Bug Affects Versions: 3.4.1 Reporter: Romain Manni-Bucau Currently starting an authorization_code flow requires an UserContext because of org.apache.cxf.rs.security.oauth2.services.RedirectionBasedGrantService#getAndValidateSecurityContext but if it is required then you can never login (until you use 2 auth methods). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CXF-8369) [oauth2] code_challenge_method not forwarded
Romain Manni-Bucau created CXF-8369: --- Summary: [oauth2] code_challenge_method not forwarded Key: CXF-8369 URL: https://issues.apache.org/jira/browse/CXF-8369 Project: CXF Issue Type: Bug Affects Versions: 3.4.1 Reporter: Romain Manni-Bucau code_challenge_method should be forwarded in state > AuthorizationCodeRegistration > ServerAuthorizationCodeGrant to enable to automatically find the CodeVerifierTransformer to use instead of hardcoding it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CXF-8368) org.apache.cxf.rs.security.oauth2.services.AuthorizationCodeGrantService#createAuthorizationData wrongly sets code_challenge
Romain Manni-Bucau created CXF-8368: --- Summary: org.apache.cxf.rs.security.oauth2.services.AuthorizationCodeGrantService#createAuthorizationData wrongly sets code_challenge Key: CXF-8368 URL: https://issues.apache.org/jira/browse/CXF-8368 Project: CXF Issue Type: Bug Affects Versions: 3.4.1 Reporter: Romain Manni-Bucau org.apache.cxf.rs.security.oauth2.services.AuthorizationCodeGrantService#createAuthorizationData sets code challenge after parent createAuthorizationData which calls org.apache.cxf.rs.security.oauth2.services.RedirectionBasedGrantService#createAuthorizationData which calls org.apache.cxf.rs.security.oauth2.provider.JoseSessionTokenProvider#createSessionToken (when used) so the state will be created before the challenge is set which breaks the flow. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CXF-8344) org.apache.cxf.jaxrs.utils.AnnotationUtils#getNameBindings does not use ClassUnwrapper
Romain Manni-Bucau created CXF-8344: --- Summary: org.apache.cxf.jaxrs.utils.AnnotationUtils#getNameBindings does not use ClassUnwrapper Key: CXF-8344 URL: https://issues.apache.org/jira/browse/CXF-8344 Project: CXF Issue Type: Bug Reporter: Romain Manni-Bucau ... which leads to miss the whole annotated model with some proxies -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CXF-7856) AbstractFeature must not extend WebServiceFeature
[ https://issues.apache.org/jira/browse/CXF-7856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17143813#comment-17143813 ] Romain Manni-Bucau commented on CXF-7856: - Didn't https://issues.apache.org/jira/browse/CXF-8053 solved most of it? Know logging feature does not need jaxws anymore for ex (while you use its portable flavor). > AbstractFeature must not extend WebServiceFeature > - > > Key: CXF-7856 > URL: https://issues.apache.org/jira/browse/CXF-7856 > Project: CXF > Issue Type: Bug >Reporter: Romain Manni-Bucau >Priority: Minor > Fix For: 3.5.0 > > > rational being that a cxf feature is not bound to jaxws (it works with jaxrs) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CXF-8290) Don't lock by default in org.apache.cxf.jaxrs.model.AbstractResourceInfo#getProxyMap
Romain Manni-Bucau created CXF-8290: --- Summary: Don't lock by default in org.apache.cxf.jaxrs.model.AbstractResourceInfo#getProxyMap Key: CXF-8290 URL: https://issues.apache.org/jira/browse/CXF-8290 Project: CXF Issue Type: Task Reporter: Romain Manni-Bucau Would be good to synchronize only if the map should be created otherwise it creates a bottleneck on resources for no real reasons. A trivial option can be to test if properties are a concurrent hashmap and if so use concurrent map API (computeIfAbsent for example). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CXF-8163) javax.ws.rs.core.Response#getCookies() fails when cookie has no value
[ https://issues.apache.org/jira/browse/CXF-8163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981307#comment-16981307 ] Romain Manni-Bucau commented on CXF-8163: - Hi Andriy, think not returning it makes the most sense. > javax.ws.rs.core.Response#getCookies() fails when cookie has no value > - > > Key: CXF-8163 > URL: https://issues.apache.org/jira/browse/CXF-8163 > Project: CXF > Issue Type: Bug >Affects Versions: 3.3.4 >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko >Priority: Major > > It is common for a server to bypass the cookie value to reset the cookie, > there the jax-rs client fails to parse it with an exception whereas I think > it should ignore the cookie entry. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CXF-8163) javax.ws.rs.core.Response#getCookies() fails when cookie has no value
Romain Manni-Bucau created CXF-8163: --- Summary: javax.ws.rs.core.Response#getCookies() fails when cookie has no value Key: CXF-8163 URL: https://issues.apache.org/jira/browse/CXF-8163 Project: CXF Issue Type: Bug Affects Versions: 3.3.4 Reporter: Romain Manni-Bucau It is common for a server to bypass the cookie value to reset the cookie, there the jax-rs client fails to parse it with an exception whereas I think it should ignore the cookie entry. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CXF-8144) OpenAPI v3 Feature: duplicated "getOpenApi" methods
[
https://issues.apache.org/jira/browse/CXF-8144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16969849#comment-16969849
]
Romain Manni-Bucau commented on CXF-8144:
-
This sounds reasonable to me even if portable intended to to not bound the impl
to jaxws (it is no more in the jvm) more than avoiding cxf api. Now for openapi
case jaxrs one makes more sense but for logging feature it wouldnt. Hope it
clarifies it.
> OpenAPI v3 Feature: duplicated "getOpenApi" methods
> ---
>
> Key: CXF-8144
> URL: https://issues.apache.org/jira/browse/CXF-8144
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.3.3, 3.3.4
>Reporter: Mike Kelly
>Assignee: Andriy Redko
>Priority: Minor
>
> Any calls to the OpenAPI documentation, as provided by the
> {{cxf-rt-rs-service-description-openapi-v3}} artifact, cause this warning to
> be logged:
> {noformat}
> 2019-11-05 16:48:43,551 [http-nio-8080-exec-9] WARN
> org.apache.cxf.jaxrs.utils.JAXRSUtils - Both
> org.apache.cxf.jaxrs.swagger.ui.SwaggerUiService#getResource and
> org.apache.cxf.jaxrs.swagger.ui.SwaggerUiService#getResource are equal
> candidates for handling the current request which can lead to unpredictable
> results
> {noformat}
> If you're loading or refreshing the API documentation, you'll see a whole lot
> of these warnings get logged.
> This seems like something that is likely a spurious message, or a design flaw
> in the Apache CXF modules?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CXF-8144) OpenAPI v3 Feature: duplicated "getOpenApi" methods
[
https://issues.apache.org/jira/browse/CXF-8144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968924#comment-16968924
]
Romain Manni-Bucau commented on CXF-8144:
-
Hi [~reta], I'd say that portable features should be @Provider and not others
since it should be the default way now. Hope it makes sense.
> OpenAPI v3 Feature: duplicated "getOpenApi" methods
> ---
>
> Key: CXF-8144
> URL: https://issues.apache.org/jira/browse/CXF-8144
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.3.3, 3.3.4
>Reporter: Mike Kelly
>Assignee: Andriy Redko
>Priority: Minor
>
> Any calls to the OpenAPI documentation, as provided by the
> {{cxf-rt-rs-service-description-openapi-v3}} artifact, cause this warning to
> be logged:
> {noformat}
> 2019-11-05 16:48:43,551 [http-nio-8080-exec-9] WARN
> org.apache.cxf.jaxrs.utils.JAXRSUtils - Both
> org.apache.cxf.jaxrs.swagger.ui.SwaggerUiService#getResource and
> org.apache.cxf.jaxrs.swagger.ui.SwaggerUiService#getResource are equal
> candidates for handling the current request which can lead to unpredictable
> results
> {noformat}
> If you're loading or refreshing the API documentation, you'll see a whole lot
> of these warnings get logged.
> This seems like something that is likely a spurious message, or a design flaw
> in the Apache CXF modules?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CXF-8053) Ensure JAX-RS usable features don't depend on jaxws
Romain Manni-Bucau created CXF-8053: --- Summary: Ensure JAX-RS usable features don't depend on jaxws Key: CXF-8053 URL: https://issues.apache.org/jira/browse/CXF-8053 Project: CXF Issue Type: Improvement Reporter: Romain Manni-Bucau Follow up of https://lists.apache.org/thread.html/c68c4c73b4af274d2f0e162e8b5df62942d8cad41d829a9e2fa7a2f5@%3Cdev.cxf.apache.org%3E discussion. Idea is to not force JAXRS users to depend on jaxws in terms of dependency. Whereas it was acceptable for java <= 8, it is now impacting in java >= 9 since jaxws is no more part of the JRE. Proposal is to: drop the WebServiceFeature dependency in the AbstractFeature hierarchy by introducing a CxfBaseFeature keeping backward compatibility, provide native implementations of all feature and replace current implementations by plain delegation to the new one - to ensure existing users still have a functional setup. JAXRS users would use the new class and JAXWS ones can use the new one (probably preferred by javadoc) or the old one for compatibility. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7601) Add support for Microprofile OpenAPI implementation (as an alternative to Swagger Core 2.0)
[ https://issues.apache.org/jira/browse/CXF-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16828997#comment-16828997 ] Romain Manni-Bucau commented on CXF-7601: - [~reta] vote sent > Add support for Microprofile OpenAPI implementation (as an alternative to > Swagger Core 2.0) > --- > > Key: CXF-7601 > URL: https://issues.apache.org/jira/browse/CXF-7601 > Project: CXF > Issue Type: Improvement >Reporter: Dennis Kieselhorst >Assignee: Dennis Kieselhorst >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7989) org.apache.cxf.jaxrs.JAXRSInvoker#checkFutureResponse should probably handle CompletionException
[ https://issues.apache.org/jira/browse/CXF-7989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16794537#comment-16794537 ] Romain Manni-Bucau commented on CXF-7989: - Tracked that to rx() impl wich uses supplyAsync which throws a completion exception in case or error. Trivial fix is to either not use that and just use a completionfuture complete/completeExceptionally wrapping the sync call in the pool or adding a handle to the stage to unwrap the completionexception. Hope it helps > org.apache.cxf.jaxrs.JAXRSInvoker#checkFutureResponse should probably handle > CompletionException > > > Key: CXF-7989 > URL: https://issues.apache.org/jira/browse/CXF-7989 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.3.0 >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko >Priority: Major > > The check should probably unwrap CompletionException otherwise it can require > some more custom ExceptionMappers to achieve a correct behavior. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7989) org.apache.cxf.jaxrs.JAXRSInvoker#checkFutureResponse should probably handle CompletionException
[ https://issues.apache.org/jira/browse/CXF-7989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792694#comment-16792694 ] Romain Manni-Bucau commented on CXF-7989: - This is what my memories says yes. A missing exceptionally on this kind of code yes. > org.apache.cxf.jaxrs.JAXRSInvoker#checkFutureResponse should probably handle > CompletionException > > > Key: CXF-7989 > URL: https://issues.apache.org/jira/browse/CXF-7989 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.3.0 >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko >Priority: Major > > The check should probably unwrap CompletionException otherwise it can require > some more custom ExceptionMappers to achieve a correct behavior. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7988) SSE sink warning on tomcat
[
https://issues.apache.org/jira/browse/CXF-7988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792386#comment-16792386
]
Romain Manni-Bucau commented on CXF-7988:
-
Tomcat 9.0.16, no other error or warn log before.
> SSE sink warning on tomcat
> --
>
> Key: CXF-7988
> URL: https://issues.apache.org/jira/browse/CXF-7988
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 3.3.0
>Reporter: Romain Manni-Bucau
>Assignee: Andriy Redko
>Priority: Major
>
> Hi guys,
> I get regularly these warning using SSE on tomcat:
> {code}
> [cxf.jaxrs.sse.SseEventSinkImpl] Failed to close the AsyncContext cleanly:
> Calling [asyncComplete()] is not valid for a request with Async state
> [MUST_COMPLETE]
> {code}
> If it helps: I use a custom thread to send sse data
> (CompletableFuture.supplyAsync(() -> {...}, executor))
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7989) org.apache.cxf.jaxrs.JAXRSInvoker#checkFutureResponse should probably handle CompletionException
[ https://issues.apache.org/jira/browse/CXF-7989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792385#comment-16792385 ] Romain Manni-Bucau commented on CXF-7989: - I dont have a simple example but i suspect when a rx client or async operator in a service returning a completionstage throws an exception then the handle on completion stage gets the wrapper and not the real exception making exception handling not working as expected - from user code point of view > org.apache.cxf.jaxrs.JAXRSInvoker#checkFutureResponse should probably handle > CompletionException > > > Key: CXF-7989 > URL: https://issues.apache.org/jira/browse/CXF-7989 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.3.0 >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko >Priority: Major > > The check should probably unwrap CompletionException otherwise it can require > some more custom ExceptionMappers to achieve a correct behavior. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7987) SSE buffer size should be configurable
[ https://issues.apache.org/jira/browse/CXF-7987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16789520#comment-16789520 ] Romain Manni-Bucau commented on CXF-7987: - [~reta] didn't find how to set it except using @org.apache.cxf.annotations.EndpointProperty (or plural flavor) which can't be set on a method. Maybe a new BusFactoryBeanListener could be added to do that - fine to be another ticket, just trying to see how to fulfill the original need to configure globally the size? > SSE buffer size should be configurable > -- > > Key: CXF-7987 > URL: https://issues.apache.org/jira/browse/CXF-7987 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.2.8, 3.3.1 >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko >Priority: Major > Fix For: 3.2.9, 3.3.2 > > > See org.apache.cxf.jaxrs.sse.SseEventSinkImpl#BUFFER_SIZE -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7987) SSE buffer size should be configurable
[ https://issues.apache.org/jira/browse/CXF-7987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16789174#comment-16789174 ] Romain Manni-Bucau commented on CXF-7987: - Hmm, do you have a pointer on where global properties are contextualized per endpoint please? Maybe mentionning it in the doc is worth it too. > SSE buffer size should be configurable > -- > > Key: CXF-7987 > URL: https://issues.apache.org/jira/browse/CXF-7987 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.2.8, 3.3.1 >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko >Priority: Major > Fix For: 3.2.9, 3.3.2 > > > See org.apache.cxf.jaxrs.sse.SseEventSinkImpl#BUFFER_SIZE -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7987) SSE buffer size should be configurable
[ https://issues.apache.org/jira/browse/CXF-7987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16788899#comment-16788899 ] Romain Manni-Bucau commented on CXF-7987: - [~reta] can it be set on the bus or somewhere else than in contextual props which require some per request specific config instead of a global deployment config? Some org.apache.cxf.sse_fqn.method.sink_buffer.size or so bus property can help - equivalent config are fine for me, just want to just configure it globally on the bus and not per endpoint in term of "set" place. > SSE buffer size should be configurable > -- > > Key: CXF-7987 > URL: https://issues.apache.org/jira/browse/CXF-7987 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.2.8, 3.3.1 >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko >Priority: Major > Fix For: 3.2.9, 3.3.2 > > > See org.apache.cxf.jaxrs.sse.SseEventSinkImpl#BUFFER_SIZE -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7989) org.apache.cxf.jaxrs.JAXRSInvoker#checkFutureResponse should probably handle CompletionException
Romain Manni-Bucau created CXF-7989: --- Summary: org.apache.cxf.jaxrs.JAXRSInvoker#checkFutureResponse should probably handle CompletionException Key: CXF-7989 URL: https://issues.apache.org/jira/browse/CXF-7989 Project: CXF Issue Type: Improvement Components: JAX-RS Affects Versions: 3.3.0 Reporter: Romain Manni-Bucau The check should probably unwrap CompletionException otherwise it can require some more custom ExceptionMappers to achieve a correct behavior. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7988) SSE sink warning on tomcat
Romain Manni-Bucau created CXF-7988:
---
Summary: SSE sink warning on tomcat
Key: CXF-7988
URL: https://issues.apache.org/jira/browse/CXF-7988
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Affects Versions: 3.3.0
Reporter: Romain Manni-Bucau
Hi guys,
I get regularly these warning using SSE on tomcat:
{code}
[cxf.jaxrs.sse.SseEventSinkImpl] Failed to close the AsyncContext cleanly:
Calling [asyncComplete()] is not valid for a request with Async state
[MUST_COMPLETE]
{code}
If it helps: I use a custom thread to send sse data
(CompletableFuture.supplyAsync(() -> {...}, executor))
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7987) SSE buffer size should be configurable
[ https://issues.apache.org/jira/browse/CXF-7987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16782868#comment-16782868 ] Romain Manni-Bucau commented on CXF-7987: - Hello [~reta], yes, i have a case i can get millions of messages and can need to bufferize 10 items for perf reasons and another server where i know i will not get more than 100 items so i would like to limit to 100 for these connections the capacity. It reads files but i know the upper bound in one case and not the other (kind of special log files). > SSE buffer size should be configurable > -- > > Key: CXF-7987 > URL: https://issues.apache.org/jira/browse/CXF-7987 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko >Priority: Major > > See org.apache.cxf.jaxrs.sse.SseEventSinkImpl#BUFFER_SIZE -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7987) SSE buffer size should be configurable
Romain Manni-Bucau created CXF-7987: --- Summary: SSE buffer size should be configurable Key: CXF-7987 URL: https://issues.apache.org/jira/browse/CXF-7987 Project: CXF Issue Type: Improvement Components: JAX-RS Reporter: Romain Manni-Bucau See org.apache.cxf.jaxrs.sse.SseEventSinkImpl#BUFFER_SIZE -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7980) RestClientExtension leaks
Romain Manni-Bucau created CXF-7980: --- Summary: RestClientExtension leaks Key: CXF-7980 URL: https://issues.apache.org/jira/browse/CXF-7980 Project: CXF Issue Type: Bug Components: JAX-RS Reporter: Romain Manni-Bucau RestClientExtension uses static variables and never clear it off, moving to instance variable would be way saner and very worse case cleaning the variable sin BeforeShutdown event would be better. If deployed in a container (like tomcat/lib folder) then it will be shared by apps so if app1 fails, app2 will fail whatever it does which is also another nasty side effect. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7976) [oauth2] token service does not serialize the issuer
[ https://issues.apache.org/jira/browse/CXF-7976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16773052#comment-16773052 ] Romain Manni-Bucau commented on CXF-7976: - [~coheigea] this is what I did but it is quite verbose for what it does: https://github.com/apache/meecrowave/commit/0bfd43e37a4a3c181593a0b2091e18dc04be79e9#diff-b15a9a157228804ef29ba9ea261a793aR121 > [oauth2] token service does not serialize the issuer > > > Key: CXF-7976 > URL: https://issues.apache.org/jira/browse/CXF-7976 > Project: CXF > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Romain Manni-Bucau >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7976) [oauth2] token service does not serialize the issuer
Romain Manni-Bucau created CXF-7976: --- Summary: [oauth2] token service does not serialize the issuer Key: CXF-7976 URL: https://issues.apache.org/jira/browse/CXF-7976 Project: CXF Issue Type: Bug Affects Versions: 3.3.0 Reporter: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7964) Ensure CXF JAXRS stack (client/server) can be used for roundtrips
[
https://issues.apache.org/jira/browse/CXF-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated CXF-7964:
Description:
Today (3.3.0), if you use a Client to get a response and copy it to return in
an endpoint (http proxy pattern) like that:
{code}
private Response passthrough(final Response source) {
final Response.ResponseBuilder builder =
Response.status(source.getStatus());
source.getStringHeaders().entrySet().stream()
.forEach(e -> builder.header(e.getKey(), String.join(",",
e.getValue(;
final InputStream forwardedData = source.readEntity(InputStream.class);
return builder.entity(forwardedData).build();
}
{code}
A client calling that endpoint will freeze cause of the forwarded input stream.
Edit: the server endpoint returns a CompletionStage (tomcat 9.0.14 and cxf
3.3.0), I didn't take time yet to investigate if it is coming from the
completion stage or not, I just know in some older 3.2 it was the stream which
was not properly closed.
Edit 2: the issue was the header "transfer-encoding" not filtered, could cxf
ignore it by default maybe?
was:
Today (3.3.0), if you use a Client to get a response and copy it to return in
an endpoint (http proxy pattern) like that:
{code}
private Response passthrough(final Response source) {
final Response.ResponseBuilder builder =
Response.status(source.getStatus());
source.getStringHeaders().entrySet().stream()
.forEach(e -> builder.header(e.getKey(), String.join(",",
e.getValue(;
final InputStream forwardedData = source.readEntity(InputStream.class);
return builder.entity(forwardedData).build();
}
{code}
A client calling that endpoint will freeze cause of the forwarded input stream.
Edit: the server endpoint returns a CompletionStage (tomcat 9.0.14 and cxf
3.3.0), I didn't take time yet to investigate if it is coming from the
completion stage or not, I just know in some older 3.2 it was the stream which
was not properly closed.
> Ensure CXF JAXRS stack (client/server) can be used for roundtrips
> -
>
> Key: CXF-7964
> URL: https://issues.apache.org/jira/browse/CXF-7964
> Project: CXF
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>Priority: Major
>
> Today (3.3.0), if you use a Client to get a response and copy it to return in
> an endpoint (http proxy pattern) like that:
> {code}
> private Response passthrough(final Response source) {
> final Response.ResponseBuilder builder =
> Response.status(source.getStatus());
> source.getStringHeaders().entrySet().stream()
> .forEach(e -> builder.header(e.getKey(), String.join(",",
> e.getValue(;
> final InputStream forwardedData =
> source.readEntity(InputStream.class);
> return builder.entity(forwardedData).build();
> }
> {code}
> A client calling that endpoint will freeze cause of the forwarded input
> stream.
> Edit: the server endpoint returns a CompletionStage (tomcat 9.0.14 and cxf
> 3.3.0), I didn't take time yet to investigate if it is coming from the
> completion stage or not, I just know in some older 3.2 it was the stream
> which was not properly closed.
> Edit 2: the issue was the header "transfer-encoding" not filtered, could cxf
> ignore it by default maybe?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CXF-7964) Ensure CXF JAXRS stack (client/server) can be used for roundtrips
[
https://issues.apache.org/jira/browse/CXF-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated CXF-7964:
Description:
Today (3.3.0), if you use a Client to get a response and copy it to return in
an endpoint (http proxy pattern) like that:
{code}
private Response passthrough(final Response source) {
final Response.ResponseBuilder builder =
Response.status(source.getStatus());
source.getStringHeaders().entrySet().stream()
.forEach(e -> builder.header(e.getKey(), String.join(",",
e.getValue(;
final InputStream forwardedData = source.readEntity(InputStream.class);
return builder.entity(forwardedData).build();
}
{code}
A client calling that endpoint will freeze cause of the forwarded input stream.
Edit: the server endpoint returns a CompletionStage (tomcat 9.0.14 and cxf
3.3.0), I didn't take time yet to investigate if it is coming from the
completion stage or not, I just know in some older 3.2 it was the stream which
was not properly closed.
was:
Today (3.3.0), if you use a Client to get a response and copy it to return in
an endpoint (http proxy pattern) like that:
{code}
private Response passthrough(final Response source) {
final Response.ResponseBuilder builder =
Response.status(source.getStatus());
source.getStringHeaders().entrySet().stream()
.forEach(e -> builder.header(e.getKey(), String.join(",",
e.getValue(;
final InputStream forwardedData = source.readEntity(InputStream.class);
return builder.entity(forwardedData).build();
}
{code}
A client calling that endpoint will freeze cause of the forwarded input stream.
> Ensure CXF JAXRS stack (client/server) can be used for roundtrips
> -
>
> Key: CXF-7964
> URL: https://issues.apache.org/jira/browse/CXF-7964
> Project: CXF
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>Priority: Major
>
> Today (3.3.0), if you use a Client to get a response and copy it to return in
> an endpoint (http proxy pattern) like that:
> {code}
> private Response passthrough(final Response source) {
> final Response.ResponseBuilder builder =
> Response.status(source.getStatus());
> source.getStringHeaders().entrySet().stream()
> .forEach(e -> builder.header(e.getKey(), String.join(",",
> e.getValue(;
> final InputStream forwardedData =
> source.readEntity(InputStream.class);
> return builder.entity(forwardedData).build();
> }
> {code}
> A client calling that endpoint will freeze cause of the forwarded input
> stream.
> Edit: the server endpoint returns a CompletionStage (tomcat 9.0.14 and cxf
> 3.3.0), I didn't take time yet to investigate if it is coming from the
> completion stage or not, I just know in some older 3.2 it was the stream
> which was not properly closed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7964) Ensure CXF JAXRS stack (client/server) can be used for roundtrips
Romain Manni-Bucau created CXF-7964:
---
Summary: Ensure CXF JAXRS stack (client/server) can be used for
roundtrips
Key: CXF-7964
URL: https://issues.apache.org/jira/browse/CXF-7964
Project: CXF
Issue Type: Bug
Reporter: Romain Manni-Bucau
Today (3.3.0), if you use a Client to get a response and copy it to return in
an endpoint (http proxy pattern) like that:
{code}
private Response passthrough(final Response source) {
final Response.ResponseBuilder builder =
Response.status(source.getStatus());
source.getStringHeaders().entrySet().stream()
.forEach(e -> builder.header(e.getKey(), String.join(",",
e.getValue(;
final InputStream forwardedData = source.readEntity(InputStream.class);
return builder.entity(forwardedData).build();
}
{code}
A client calling that endpoint will freeze cause of the forwarded input stream.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7963) org.apache.cxf.jaxrs.utils.InjectionUtils#handleParameter shouldn't depend hardly on jaxb
Romain Manni-Bucau created CXF-7963: --- Summary: org.apache.cxf.jaxrs.utils.InjectionUtils#handleParameter shouldn't depend hardly on jaxb Key: CXF-7963 URL: https://issues.apache.org/jira/browse/CXF-7963 Project: CXF Issue Type: Improvement Reporter: Romain Manni-Bucau Still in the goal to run jaxrs cxf stack without jaxb requirement, InjectionUtils should be adapted for the case there are parameters. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7921) JAXRS CDI extension ignores interfaces annotations
[
https://issues.apache.org/jira/browse/CXF-7921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated CXF-7921:
Description:
https://github.com/apache/cxf/blob/master/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java#L194
should also consider interfaces of the annotated type cause they can host
@Path in a contract driven approach
Here is a version for collect method:
{code}
if (!event.getAnnotated().isAnnotationPresent(Path.class) &&
AnnotatedType.class.isInstance(event.getAnnotated())) {
final AnnotatedType type =
AnnotatedType.class.cast(event.getAnnotated());
// note: should we use Annotated for interfaces as well?
if (type.getTypeClosure().stream()
.filter(it -> Class.class.isInstance(it) &&
Class.class.cast(it).isInterface())
.map(Class.class::cast)
.map((Function)
beanManager::createAnnotatedType) // todo: add beanManager as param of the
collect method
.anyMatch(c -> c.isAnnotationPresent(Path.class))) {
try {
List.class.cast(serviceBeans.get(this)).add(event.getBean());
return;
} catch (final IllegalAccessException e) {
new
org.apache.meecrowave.logging.tomcat.LogFacade(Cxfs.class.getName())
.error(e.getMessage(), e);
}
}
}
// else current code
{code}
was:
https://github.com/apache/cxf/blob/master/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java#L194
should also consider interfaces of the annotated type cause they can host
@Path in a contract driven approach
Here is a version for collect method:
{code}
if (!event.getAnnotated().isAnnotationPresent(Path.class) &&
AnnotatedType.class.isInstance(event.getAnnotated())) {
final AnnotatedType type =
AnnotatedType.class.cast(event.getAnnotated());
// note: should we use Annotated for interfaces as well?
if (type.getTypeClosure().stream()
.filter(it -> Class.class.isInstance(it) &&
Class.class.cast(it).isInterface())
.map(Class.class::cast)
.anyMatch(c -> c.isAnnotationPresent(Path.class))) {
try {
List.class.cast(serviceBeans.get(this)).add(event.getBean());
return;
} catch (final IllegalAccessException e) {
new
org.apache.meecrowave.logging.tomcat.LogFacade(Cxfs.class.getName())
.error(e.getMessage(), e);
}
}
}
// else current code
{code}
> JAXRS CDI extension ignores interfaces annotations
> --
>
> Key: CXF-7921
> URL: https://issues.apache.org/jira/browse/CXF-7921
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.7
>Reporter: Romain Manni-Bucau
>Priority: Major
>
> https://github.com/apache/cxf/blob/master/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java#L194
> should also consider interfaces of the annotated type cause they can host
> @Path in a contract driven approach
> Here is a version for collect method:
> {code}
> if (!event.getAnnotated().isAnnotationPresent(Path.class) &&
> AnnotatedType.class.isInstance(event.getAnnotated())) {
> final AnnotatedType type =
> AnnotatedType.class.cast(event.getAnnotated());
> // note: should we use Annotated for interfaces as well?
> if (type.getTypeClosure().stream()
> .filter(it -> Class.class.isInstance(it) &&
> Class.class.cast(it).isInterface())
> .map(Class.class::cast)
> .map((Function)
> beanManager::createAnnotatedType) // todo: add beanManager as param of the
> collect method
> .anyMatch(c -> c.isAnnotationPresent(Path.class))) {
> try {
>
> List.class.cast(serviceBeans.get(this)).add(event.getBean());
> return;
> } catch (final IllegalAccessException e) {
> new
> org.apache.meecrowave.logging.tomcat.LogFacade(Cxfs.class.getName())
> .error(e.getMessage(), e);
> }
> }
> }
> // else current code
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CXF-7921) JAXRS CDI extension ignores interfaces annotations
[
https://issues.apache.org/jira/browse/CXF-7921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated CXF-7921:
Description:
https://github.com/apache/cxf/blob/master/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java#L194
should also consider interfaces of the annotated type cause they can host
@Path in a contract driven approach
Here is a version for collect method:
{code}
if (!event.getAnnotated().isAnnotationPresent(Path.class) &&
AnnotatedType.class.isInstance(event.getAnnotated())) {
final AnnotatedType type =
AnnotatedType.class.cast(event.getAnnotated());
// note: should we use Annotated for interfaces as well?
if (type.getTypeClosure().stream()
.filter(it -> Class.class.isInstance(it) &&
Class.class.cast(it).isInterface())
.map(Class.class::cast)
.anyMatch(c -> c.isAnnotationPresent(Path.class))) {
try {
List.class.cast(serviceBeans.get(this)).add(event.getBean());
return;
} catch (final IllegalAccessException e) {
new
org.apache.meecrowave.logging.tomcat.LogFacade(Cxfs.class.getName())
.error(e.getMessage(), e);
}
}
}
// else current code
{code}
was:https://github.com/apache/cxf/blob/master/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java#L194
should also consider interfaces of the annotated type cause they can host
@Path in a contract driven approach
> JAXRS CDI extension ignores interfaces annotations
> --
>
> Key: CXF-7921
> URL: https://issues.apache.org/jira/browse/CXF-7921
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.7
>Reporter: Romain Manni-Bucau
>Priority: Major
>
> https://github.com/apache/cxf/blob/master/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java#L194
> should also consider interfaces of the annotated type cause they can host
> @Path in a contract driven approach
> Here is a version for collect method:
> {code}
> if (!event.getAnnotated().isAnnotationPresent(Path.class) &&
> AnnotatedType.class.isInstance(event.getAnnotated())) {
> final AnnotatedType type =
> AnnotatedType.class.cast(event.getAnnotated());
> // note: should we use Annotated for interfaces as well?
> if (type.getTypeClosure().stream()
> .filter(it -> Class.class.isInstance(it) &&
> Class.class.cast(it).isInterface())
> .map(Class.class::cast)
> .anyMatch(c -> c.isAnnotationPresent(Path.class))) {
> try {
>
> List.class.cast(serviceBeans.get(this)).add(event.getBean());
> return;
> } catch (final IllegalAccessException e) {
> new
> org.apache.meecrowave.logging.tomcat.LogFacade(Cxfs.class.getName())
> .error(e.getMessage(), e);
> }
> }
> }
> // else current code
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7921) JAXRS CDI extension ignores interfaces annotations
Romain Manni-Bucau created CXF-7921: --- Summary: JAXRS CDI extension ignores interfaces annotations Key: CXF-7921 URL: https://issues.apache.org/jira/browse/CXF-7921 Project: CXF Issue Type: Bug Components: JAX-RS Reporter: Romain Manni-Bucau https://github.com/apache/cxf/blob/master/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java#L194 should also consider interfaces of the annotated type cause they can host @Path in a contract driven approach -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7921) JAXRS CDI extension ignores interfaces annotations
[ https://issues.apache.org/jira/browse/CXF-7921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated CXF-7921: Affects Version/s: 3.2.7 > JAXRS CDI extension ignores interfaces annotations > -- > > Key: CXF-7921 > URL: https://issues.apache.org/jira/browse/CXF-7921 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.2.7 >Reporter: Romain Manni-Bucau >Priority: Major > > https://github.com/apache/cxf/blob/master/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java#L194 > should also consider interfaces of the annotated type cause they can host > @Path in a contract driven approach -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7361) Java 9 support for CXFAuthenticator
[ https://issues.apache.org/jira/browse/CXF-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664837#comment-16664837 ] Romain Manni-Bucau commented on CXF-7361: - On Java 11 with last CXF version, CXFAuthenticator passes. Things changed quite a bit since java 9 so not 100% sure why but I guess while CXF is an unnamed module we are fine. > Java 9 support for CXFAuthenticator > --- > > Key: CXF-7361 > URL: https://issues.apache.org/jira/browse/CXF-7361 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.11 >Reporter: Romain Manni-Bucau >Assignee: Freeman Fang >Priority: Major > > with java 9, Authenticator getDefault() should be used instead of field.get() > (setAccessible fails) + unsafe should be used to define the class instead > of the failing ClassLoader.defineClass. > All that with reflection of course and in fallback mode probably since for > java 8 it is better to not do it (or it is not available - getDefault() > typically). > Workaround ATM is to call CXFAuthenticator.addAuthenticator(); manually and > ignore the exception, it initializes the instance then it doesn't fail but > the feature is lost until it gets fixed as mentionned before. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7361) Java 9 support for CXFAuthenticator
[ https://issues.apache.org/jira/browse/CXF-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664722#comment-16664722 ] Romain Manni-Bucau commented on CXF-7361: - Or classloader defineClass which is used in EE libs. Works well for not named modules. > Java 9 support for CXFAuthenticator > --- > > Key: CXF-7361 > URL: https://issues.apache.org/jira/browse/CXF-7361 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.11 >Reporter: Romain Manni-Bucau >Assignee: Freeman Fang >Priority: Major > > with java 9, Authenticator getDefault() should be used instead of field.get() > (setAccessible fails) + unsafe should be used to define the class instead > of the failing ClassLoader.defineClass. > All that with reflection of course and in fallback mode probably since for > java 8 it is better to not do it (or it is not available - getDefault() > typically). > Workaround ATM is to call CXFAuthenticator.addAuthenticator(); manually and > ignore the exception, it initializes the instance then it doesn't fail but > the feature is lost until it gets fixed as mentionned before. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7856) AbstractFeature must not extend WebServiceFeature
Romain Manni-Bucau created CXF-7856: --- Summary: AbstractFeature must not extend WebServiceFeature Key: CXF-7856 URL: https://issues.apache.org/jira/browse/CXF-7856 Project: CXF Issue Type: Bug Reporter: Romain Manni-Bucau rational being that a cxf feature is not bound to jaxws (it works with jaxrs) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7846) Support SPI for JAXRS Client Instantiator and ensure it has a release method
[ https://issues.apache.org/jira/browse/CXF-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated CXF-7846: Description: High level, the goal is to ensure the JAXRS client instantiator can be switched to use Spring, CDI or any other implementation. > Support SPI for JAXRS Client Instantiator and ensure it has a release method > > > Key: CXF-7846 > URL: https://issues.apache.org/jira/browse/CXF-7846 > Project: CXF > Issue Type: Task > Components: JAX-RS >Affects Versions: 3.2.6 >Reporter: Romain Manni-Bucau >Priority: Major > > High level, the goal is to ensure the JAXRS client instantiator can be > switched to use Spring, CDI or any other implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7846) Support SPI for JAXRS Client Instantiator and ensure it has a release method
Romain Manni-Bucau created CXF-7846: --- Summary: Support SPI for JAXRS Client Instantiator and ensure it has a release method Key: CXF-7846 URL: https://issues.apache.org/jira/browse/CXF-7846 Project: CXF Issue Type: Task Components: JAX-RS Affects Versions: 3.2.6 Reporter: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7808) Ensure org.apache.cxf.jaxrs.utils.InjectionUtils#injectThroughMethod logs an error
Romain Manni-Bucau created CXF-7808: --- Summary: Ensure org.apache.cxf.jaxrs.utils.InjectionUtils#injectThroughMethod logs an error Key: CXF-7808 URL: https://issues.apache.org/jira/browse/CXF-7808 Project: CXF Issue Type: Improvement Reporter: Romain Manni-Bucau Currently org.apache.cxf.jaxrs.utils.InjectionUtils#injectThroughMethod doesn't log an error message which means you have a 500 and a big stack trace but not the cause so it is very hard for end users to understand what happens without debugging the internals. Would be great to have a log error happening in such a case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7790) [CDI] CDI integration doesn't respect CDI metamodel
Romain Manni-Bucau created CXF-7790: --- Summary: [CDI] CDI integration doesn't respect CDI metamodel Key: CXF-7790 URL: https://issues.apache.org/jira/browse/CXF-7790 Project: CXF Issue Type: Bug Affects Versions: 3.2.5 Reporter: Romain Manni-Bucau CDI classes metamodel is based on Annotated hierarchy (AnnotatedType, AnnotatedMethod, AnnotatedParameter, etc), this means CXF should abstract all the reflection done to be compatible with that instead of relying on static utilities which breaks CDI features (extensions customization of the java model) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7789) [CDI] getClasses instances are not using CDI
Romain Manni-Bucau created CXF-7789: --- Summary: [CDI] getClasses instances are not using CDI Key: CXF-7789 URL: https://issues.apache.org/jira/browse/CXF-7789 Project: CXF Issue Type: Bug Affects Versions: 3.2.5 Reporter: Romain Manni-Bucau org.apache.cxf.jaxrs.utils.ResourceUtils#createApplication logic is not IoC/environment friendly so it is rarely (never?) what the user expected, this should probably be made a SPI instead of a static utilities set of methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7742) CdiResourceProvider is not thread safe
[ https://issues.apache.org/jira/browse/CXF-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved CXF-7742. - Resolution: Fixed > CdiResourceProvider is not thread safe > -- > > Key: CXF-7742 > URL: https://issues.apache.org/jira/browse/CXF-7742 > Project: CXF > Issue Type: Bug >Affects Versions: 3.2.4 >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: 3.2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7742) CdiResourceProvider is not thread safe
Romain Manni-Bucau created CXF-7742: --- Summary: CdiResourceProvider is not thread safe Key: CXF-7742 URL: https://issues.apache.org/jira/browse/CXF-7742 Project: CXF Issue Type: Bug Affects Versions: 3.2.4 Reporter: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7698) [jaxrs/cdi] org.apache.cxf.cdi.JAXRSCdiResourceExtension#loadExternalProviders is not configurable
Romain Manni-Bucau created CXF-7698: --- Summary: [jaxrs/cdi] org.apache.cxf.cdi.JAXRSCdiResourceExtension#loadExternalProviders is not configurable Key: CXF-7698 URL: https://issues.apache.org/jira/browse/CXF-7698 Project: CXF Issue Type: Improvement Reporter: Romain Manni-Bucau org.apache.cxf.cdi.JAXRSCdiResourceExtension#loadExternalProviders should be configurable to let the user control what it loads Typical example is a leaking jersey-core in the classpath which will lead to load a tons of message body readers/writers which can't be instantiated. ATM it fails the startup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7643) Ability to disable certain ContextResolved CDI Beans
[ https://issues.apache.org/jira/browse/CXF-7643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated CXF-7643: Issue Type: Bug (was: Improvement) > Ability to disable certain ContextResolved CDI Beans > > > Key: CXF-7643 > URL: https://issues.apache.org/jira/browse/CXF-7643 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.2.2 >Reporter: Romain Manni-Bucau >Priority: Trivial > > ContextProducerBeans are added for all @Context fields. > This is not in the spec so it must use a custom qualifier only and not leak > @Default support for all context types. > Currently it fails with servlet beans which are supported by any CDI@servlet > container and already provided as required by the spec which leads to 1. an > inconsistent bean being deployed 2. an ambiguous resolution. > Side note: this feature can stay as an activable thing but not as a default > for the mentionned reasons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7643) Ability to disable certain ContextResolved CDI Beans
[ https://issues.apache.org/jira/browse/CXF-7643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16368148#comment-16368148 ] Romain Manni-Bucau commented on CXF-7643: - John, there is no concurrent registration since servlet ones are standard and must not be part of cxf. For these beans use the servlet integration of your cdi container (weld or owb). For the name: getname and @named lead to the same do you added named qualifier without willing it. Cxf should probably remove all names - even on the bus - and use @cxf but it is another issue for the bus. More generally, never use default in a lib for a standard type which will conflict with user or container code - a user can produce all beans you added and you make him fail ;). Having all beans without default qualifier and names by default sounds fine as a fix. > Ability to disable certain ContextResolved CDI Beans > > > Key: CXF-7643 > URL: https://issues.apache.org/jira/browse/CXF-7643 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.2.2 >Reporter: Romain Manni-Bucau >Priority: Trivial > > ContextProducerBeans are added for all @Context fields. > This is not in the spec so it must use a custom qualifier only and not leak > @Default support for all context types. > Currently it fails with servlet beans which are supported by any CDI@servlet > container and already provided as required by the spec which leads to 1. an > inconsistent bean being deployed 2. an ambiguous resolution. > Side note: this feature can stay as an activable thing but not as a default > for the mentionned reasons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7643) [jaxrs][cdi] Remove ContextProducer beans
[ https://issues.apache.org/jira/browse/CXF-7643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16365503#comment-16365503 ] Romain Manni-Bucau commented on CXF-7643: - Hi John, even meant for the app server it is an issue and will lock users in the future. But agree for now servlet part is blocking and a workaround for partial CDI environments so should be an activable toggle not on by default at the minimum. Now it is not ProcessBean but ProcessSyntheticBean. Issue is also it is added in AfterBeanDiscovery and therefore is not that portably rewrittable. Also it should just not be rewritten since in the order of precedence CXF should check if they already exist and if so not add them (ie CXF can customize servlet or CDI but not the opposite in terms of dependencies). > [jaxrs][cdi] Remove ContextProducer beans > - > > Key: CXF-7643 > URL: https://issues.apache.org/jira/browse/CXF-7643 > Project: CXF > Issue Type: Task >Affects Versions: 3.2.1 >Reporter: Romain Manni-Bucau >Priority: Blocker > > ContextProducerBeans are added for all @Context fields. > This is not in the spec so it must use a custom qualifier only and not leak > @Default support for all context types. > Currently it fails with servlet beans which are supported by any CDI@servlet > container and already provided as required by the spec which leads to 1. an > inconsistent bean being deployed 2. an ambiguous resolution. > Side note: this feature can stay as an activable thing but not as a default > for the mentionned reasons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7643) [jaxrs][cdi] Remove ContextProducer beans
Romain Manni-Bucau created CXF-7643: --- Summary: [jaxrs][cdi] Remove ContextProducer beans Key: CXF-7643 URL: https://issues.apache.org/jira/browse/CXF-7643 Project: CXF Issue Type: Task Affects Versions: 3.2.1 Reporter: Romain Manni-Bucau ContextProducerBeans are added for all @Context fields. This is not in the spec so it must use a custom qualifier only and not leak @Default support for all context types. Currently it fails with servlet beans which are supported by any CDI@servlet container and already provided as required by the spec which leads to 1. an inconsistent bean being deployed 2. an ambiguous resolution. Side note: this feature can stay as an activable thing but not as a default for the mentionned reasons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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=16224157#comment-16224157
]
Romain Manni-Bucau commented on CXF-7544:
-
Yes cause issue is ot only the model but also the instance used. Can need an
AroundConstruct to be solved properly.
> 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]
--
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=16224118#comment-16224118
]
Romain Manni-Bucau commented on CXF-7544:
-
Think also have the case of a standard provider with @Context as constructor
param but @Inject fields (so the bean is not a cdi bean but uses cdi beans)
> 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]
--
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=16224118#comment-16224118
]
Romain Manni-Bucau edited comment on CXF-7544 at 10/29/17 6:09 PM:
---
Think we also have the case of a standard provider with @Context as constructor
param but @Inject fields (so the bean is not a cdi bean but uses cdi beans)
was (Author: romain.manni-bucau):
Think also have the case of a standard provider with @Context as constructor
param but @Inject fields (so the bean is not a cdi bean but uses cdi beans)
> 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]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7505) Oauth2 keystore loading inconsistent with jwt keys
[ https://issues.apache.org/jira/browse/CXF-7505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16168235#comment-16168235 ] Romain Manni-Bucau commented on CXF-7505: - Hello Sergey Was a misconfiguration migration from 3.1 to 3.2 I think but the error is far to be obvious so a check of the config before failing would probably help. > Oauth2 keystore loading inconsistent with jwt keys > -- > > Key: CXF-7505 > URL: https://issues.apache.org/jira/browse/CXF-7505 > Project: CXF > Issue Type: Bug >Affects Versions: 3.2.0 >Reporter: Romain Manni-Bucau > > org.apache.cxf.rs.security.jose.common.KeyManagementUtils#loadPersistKeyStore > set a keystore in the exchange and > org.apache.cxf.rs.security.jose.jwk.JwkUtils#loadJwkSet(org.apache.cxf.message.Message, > java.util.Properties, > org.apache.cxf.rs.security.jose.common.PrivateKeyPasswordProvider) loads > JsonWebKeys which can lead to classcastexception -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CXF-7505) Oauth2 keystore loading inconsistent with jwt keys
Romain Manni-Bucau created CXF-7505: --- Summary: Oauth2 keystore loading inconsistent with jwt keys Key: CXF-7505 URL: https://issues.apache.org/jira/browse/CXF-7505 Project: CXF Issue Type: Bug Affects Versions: 3.2.0 Reporter: Romain Manni-Bucau org.apache.cxf.rs.security.jose.common.KeyManagementUtils#loadPersistKeyStore set a keystore in the exchange and org.apache.cxf.rs.security.jose.jwk.JwkUtils#loadJwkSet(org.apache.cxf.message.Message, java.util.Properties, org.apache.cxf.rs.security.jose.common.PrivateKeyPasswordProvider) loads JsonWebKeys which can lead to classcastexception -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CXF-7504) NPE in oauth2 module for jose auth code tokens
Romain Manni-Bucau created CXF-7504: --- Summary: NPE in oauth2 module for jose auth code tokens Key: CXF-7504 URL: https://issues.apache.org/jira/browse/CXF-7504 Project: CXF Issue Type: Bug Affects Versions: 3.2.0 Reporter: Romain Manni-Bucau org.apache.cxf.rs.security.oauth2.provider.JoseSessionTokenProvider#protectStateString calls org.apache.cxf.rs.security.oauth2.provider.JoseSessionTokenProvider#getInitializedEncryptionProvider which calls org.apache.cxf.rs.security.jose.jwe.JweUtils#loadEncryptionProvider(org.apache.cxf.rs.security.jose.jwe.JweHeaders, boolean) with headers == null but in the stack org.apache.cxf.rs.security.jose.jwe.JweUtils#loadKeyEncryptionProvider assumes headers != null which leads to a NPE -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7501) Cannot inject field in ContainerRequestFilter
[
https://issues.apache.org/jira/browse/CXF-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16163513#comment-16163513
]
Romain Manni-Bucau commented on CXF-7501:
-
Hi
If the instantiation is done by tomee then if a cdi bean is available it is
used and contexts work but ot through cxf register(Class) since tomee doesnt
own them. Would cxf have a SPI for the factory?
> Cannot inject field in ContainerRequestFilter
> -
>
> Key: CXF-7501
> URL: https://issues.apache.org/jira/browse/CXF-7501
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10
> Environment: Linux Mint 64 bit, TomEE Plus 7.0.3, JavaEE 7
> application using MVC specification and reference implementation(Libs
> Attached)
>Reporter: Jeyvison Nascimento
>Priority: Critical
> Attachments: javax-mvc.jar, ozark.jar
>
>
> Hey folks.
> We found a weird behavior while running MVC specification(JSR 371) on TomEE
> witch CXF. We have a *ContainerRequestFilter* defined called
> *JaxRsContextFilter*
> {code:java}
> @PreMatching
> @Priority(0)
> public class JaxRsContextFilter implements ContainerRequestFilter {
> @Inject
> private JaxRsContextProducer jaxRsContextProducer;
> @Context
> private Configuration configuration;
> @Context
> private HttpServletRequest request;
> @Context
> private HttpServletResponse response;
> public JaxRsContextFilter() {
> }
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> this.jaxRsContextProducer.populate(this.configuration, this.request,
> this.response);
> }
> }
> {code}
> You can see that we have a JaxRsContextProducer annotated to be injected as a
> field in our object but when JAXRSUtils is called to run the the container
> filters it injects the fields annotated as *@Context* , not the fields
> annotated with *@Inject*.
> {code:java}
> for (ProviderInfo filter : containerFilters) {
> try {
> InjectionUtils.injectContexts(filter.getProvider(),
> filter, m);
> filter.getProvider().filter(context);
> } catch (IOException ex) {
> throw ExceptionUtils.toInternalServerErrorException(ex,
> null);
> }
> {code}
> It causes our filter(*JaxRsContextFilter*) to throw a NullPointerException
> when filtering the request because it uses the producer to perform some
> actions in this operation.
> I believe this field should be injected as well, not only the *@Context*
> fields.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7406) JAXWS CDI integration
[ https://issues.apache.org/jira/browse/CXF-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048132#comment-16048132 ] Romain Manni-Bucau commented on CXF-7406: - Hey Sergey, well for the split also keep in mind cdi is auto activated so using a bit of reflection (for the factory/server) can also work and enable a single module to just work (that's where I'm unsure, kind of user easiness vs code easiness) for 2. issue is really in cxf and not in cdi integration. Think to a tomcat with cxf-rs in common.lib and a webapp deployed to this tomcat adding just cxf-ws, then it wouldnt load until cxf-ws is moved to the container where expectation can be to have core reusable for both rs and ws. Can be another ticket though. > JAXWS CDI integration > - > > Key: CXF-7406 > URL: https://issues.apache.org/jira/browse/CXF-7406 > Project: CXF > Issue Type: New Feature >Reporter: Romain Manni-Bucau > > As the cdi module for jaxrs it would be neat to have one for jaxws, > meecrowave created one (assuming jaxrs one is there): > https://github.com/apache/meecrowave/commit/1350935b2eecaba8ffee9f0df1de0912960b1cee > Questions: > 1. can CXF integrate such a module (with probably more work for providers) > 2. how to ensure core doesnt have jaxws code to allow [jaxrs container > classloader] -> [webapp adding jaxws dependencies but reusing container cxf > part], here SchemaInfo is an issue since jaxrs will not bring xmlschema for > instance > 3. how to handle the shared area of cdi (the bus for instance): common-cdi > module? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CXF-7406) JAXWS CDI integration
Romain Manni-Bucau created CXF-7406: --- Summary: JAXWS CDI integration Key: CXF-7406 URL: https://issues.apache.org/jira/browse/CXF-7406 Project: CXF Issue Type: New Feature Reporter: Romain Manni-Bucau As the cdi module for jaxrs it would be neat to have one for jaxws, meecrowave created one (assuming jaxrs one is there): https://github.com/apache/meecrowave/commit/1350935b2eecaba8ffee9f0df1de0912960b1cee Questions: 1. can CXF integrate such a module (with probably more work for providers) 2. how to ensure core doesnt have jaxws code to allow [jaxrs container classloader] -> [webapp adding jaxws dependencies but reusing container cxf part], here SchemaInfo is an issue since jaxrs will not bring xmlschema for instance 3. how to handle the shared area of cdi (the bus for instance): common-cdi module? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7403) [CDI] support overriding of consumes/produces for producers
[
https://issues.apache.org/jira/browse/CXF-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16047732#comment-16047732
]
Romain Manni-Bucau commented on CXF-7403:
-
The idea was to add meta (annotations) not linked to the class but something
else (kind of loose coupling between the mimetype and impl). In CDI the
producers are natural and extensions allow to handle them smoothly (config
etc). That said the wrappers would work with spring too, was just a CDI user
facing integration of a core feature.
> [CDI] support overriding of consumes/produces for producers
> ---
>
> Key: CXF-7403
> URL: https://issues.apache.org/jira/browse/CXF-7403
> Project: CXF
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> Idea is to be able to produce a @Provider (MessageBody[Reader|Writer) and
> override on the fly the @Consumes/@Produces of the class using the ones on
> the producer method (field? - in the annotated type of the producer).
> A sample would be:
> {code}
> javax...Produces
> @Produces("application/json")
> @Consumes("application/json")
> public JacksonProvider jsonProvider() {
> return new JacksonProvider();
> }
> {code}
> This sample would allow to override in the application conflicting/broken
> media types (jackson uses wildcard by default leading to issues in JAX-RS 2
> sorting when another provider uses application/*+json or so).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7403) [CDI] support overriding of consumes/produces for producers
[
https://issues.apache.org/jira/browse/CXF-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16046138#comment-16046138
]
Romain Manni-Bucau commented on CXF-7403:
-
Well, have to admit i like the compatibility without anonymous class too but
can be sufficient for my need.
> [CDI] support overriding of consumes/produces for producers
> ---
>
> Key: CXF-7403
> URL: https://issues.apache.org/jira/browse/CXF-7403
> Project: CXF
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> Idea is to be able to produce a @Provider (MessageBody[Reader|Writer) and
> override on the fly the @Consumes/@Produces of the class using the ones on
> the producer method (field? - in the annotated type of the producer).
> A sample would be:
> {code}
> javax...Produces
> @Produces("application/json")
> @Consumes("application/json")
> public JacksonProvider jsonProvider() {
> return new JacksonProvider();
> }
> {code}
> This sample would allow to override in the application conflicting/broken
> media types (jackson uses wildcard by default leading to issues in JAX-RS 2
> sorting when another provider uses application/*+json or so).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CXF-7403) [CDI] support overriding of consumes/produces for producers
[
https://issues.apache.org/jira/browse/CXF-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16046084#comment-16046084
]
Romain Manni-Bucau commented on CXF-7403:
-
Well the providers/wrappers can be used with spring, the cdi integration is
just nice :)
> [CDI] support overriding of consumes/produces for producers
> ---
>
> Key: CXF-7403
> URL: https://issues.apache.org/jira/browse/CXF-7403
> Project: CXF
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> Idea is to be able to produce a @Provider (MessageBody[Reader|Writer) and
> override on the fly the @Consumes/@Produces of the class using the ones on
> the producer method (field? - in the annotated type of the producer).
> A sample would be:
> {code}
> javax...Produces
> @Produces("application/json")
> @Consumes("application/json")
> public JacksonProvider jsonProvider() {
> return new JacksonProvider();
> }
> {code}
> This sample would allow to override in the application conflicting/broken
> media types (jackson uses wildcard by default leading to issues in JAX-RS 2
> sorting when another provider uses application/*+json or so).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CXF-7403) [CDI] support overriding of consumes/produces for producers
[
https://issues.apache.org/jira/browse/CXF-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16045429#comment-16045429
]
Romain Manni-Bucau commented on CXF-7403:
-
For 2 reasons:
1. It is smoother this way in general (using producer is more natural) IMO
2. It opens the door to anonymous providers which is quite convenient
> [CDI] support overriding of consumes/produces for producers
> ---
>
> Key: CXF-7403
> URL: https://issues.apache.org/jira/browse/CXF-7403
> Project: CXF
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> Idea is to be able to produce a @Provider (MessageBody[Reader|Writer) and
> override on the fly the @Consumes/@Produces of the class using the ones on
> the producer method (field? - in the annotated type of the producer).
> A sample would be:
> {code}
> javax...Produces
> @Produces("application/json")
> @Consumes("application/json")
> public JacksonProvider jsonProvider() {
> return new JacksonProvider();
> }
> {code}
> This sample would allow to override in the application conflicting/broken
> media types (jackson uses wildcard by default leading to issues in JAX-RS 2
> sorting when another provider uses application/*+json or so).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CXF-7403) [CDI] support overriding of consumes/produces for producers
[
https://issues.apache.org/jira/browse/CXF-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated CXF-7403:
Description:
Idea is to be able to produce a @Provider (MessageBody[Reader|Writer) and
override on the fly the @Consumes/@Produces of the class using the ones on the
producer method (field? - in the annotated type of the producer).
A sample would be:
{code}
javax...Produces
@Produces("application/json")
@Consumes("application/json")
public JacksonProvider jsonProvider() {
return new JacksonProvider();
}
{code}
This sample would allow to override in the application conflicting/broken media
types (jackson uses wildcard by default leading to issues in JAX-RS 2 sorting
when another provider uses application/*+json or so).
was:
Idea is to be able to produce a @Provider (MessageBody[Reader|Writer) and
override on the fly the @Consumes/@Produces of the class using the ones on the
producer method (field? - in the annotated type of the producer).
A sample would be:
{code}
javax...Produces
@Produces("application/json")
@Consumes("application/json")
public JacksonProvider jsonProvider() {
return new JacksonProvider();
}
{code}
This sample would allow to override in the application conflicting/broken media
types (jackson uses */* by default leading to issues in JAX-RS 2 sorting).
> [CDI] support overriding of consumes/produces for producers
> ---
>
> Key: CXF-7403
> URL: https://issues.apache.org/jira/browse/CXF-7403
> Project: CXF
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> Idea is to be able to produce a @Provider (MessageBody[Reader|Writer) and
> override on the fly the @Consumes/@Produces of the class using the ones on
> the producer method (field? - in the annotated type of the producer).
> A sample would be:
> {code}
> javax...Produces
> @Produces("application/json")
> @Consumes("application/json")
> public JacksonProvider jsonProvider() {
> return new JacksonProvider();
> }
> {code}
> This sample would allow to override in the application conflicting/broken
> media types (jackson uses wildcard by default leading to issues in JAX-RS 2
> sorting when another provider uses application/*+json or so).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CXF-7403) [CDI] support overriding of consumes/produces for producers
Romain Manni-Bucau created CXF-7403:
---
Summary: [CDI] support overriding of consumes/produces for
producers
Key: CXF-7403
URL: https://issues.apache.org/jira/browse/CXF-7403
Project: CXF
Issue Type: New Feature
Reporter: Romain Manni-Bucau
Idea is to be able to produce a @Provider (MessageBody[Reader|Writer) and
override on the fly the @Consumes/@Produces of the class using the ones on the
producer method (field? - in the annotated type of the producer).
A sample would be:
{code}
javax...Produces
@Produces("application/json")
@Consumes("application/json")
public JacksonProvider jsonProvider() {
return new JacksonProvider();
}
{code}
This sample would allow to override in the application conflicting/broken media
types (jackson uses */* by default leading to issues in JAX-RS 2 sorting).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CXF-7363) Support saaj-impl 1.4
[
https://issues.apache.org/jira/browse/CXF-7363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15997315#comment-15997315
]
Romain Manni-Bucau commented on CXF-7363:
-
Well, it can be in cxf (as in previous patch, taking the responsability of part
of the dom), wss4j (wss4j-ws-security-dom) or saaj-impl (which surely could
make the Document behaving as before). Finaly goal is CXF WSS configuration
should work wherever it is fixed :).
> Support saaj-impl 1.4
> -
>
> Key: CXF-7363
> URL: https://issues.apache.org/jira/browse/CXF-7363
> Project: CXF
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>
> org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor (and actions like
> UsernameTokenAction) don't build the dom correctly and it fails with
> saaj(impl 1.4, here a way to build correctly the dom for the header appending:
> {code}
> new WSS4JOutInterceptor(outProps) {
> @Override
> protected void doSenderAction(final Document doc, final
> RequestData reqData,
> final List actions,
> final boolean isRequest) throws WSSecurityException {
> final String soapNamespace =
> WSSecurityUtil.getSOAPNamespace(doc.getDocumentElement());
> Element header =
> XMLUtils.getDirectChildElement(doc.getDocumentElement(),
> WSConstants.ELEM_HEADER, soapNamespace);
> final Element envelope = doc.getDocumentElement();
> if (header == null) {
> header =
> createElementInSameNamespace(envelope.getOwnerDocument(), envelope,
> WSConstants.ELEM_HEADER);
> final Node firstChild = envelope.getFirstChild();
> if (firstChild == null) {
> envelope.appendChild(header);
> } else {
> envelope.insertBefore(header, firstChild);
> }
> }
> Element securityHeader =
> WSSecurityUtil.getSecurityHeader(header, getString(WSHandlerConstants.ACTOR,
> reqData.getMsgContext()), WSConstants.URI_SOAP12_ENV.equals(soapNamespace));
> if (securityHeader == null) {
> securityHeader =
> header.getOwnerDocument().createElementNS(WSConstants.WSSE_NS,
> "wsse:Security");
> securityHeader.setAttributeNS(WSConstants.XMLNS_NS,
> "xmlns:wsse", WSConstants.WSSE_NS);
> final Node firstChild = header.getFirstChild();
> if (firstChild == null) {
> header.appendChild(securityHeader);
> } else {
> header.insertBefore(securityHeader, firstChild);
> }
> }
> super.doSenderAction(doc, reqData, actions, isRequest);
> }
> private Element createElementInSameNamespace(final Document doc,
> final Element parent, final String localName) {
> String qName = localName;
> String prefix = parent.getPrefix();
> if (prefix != null && prefix.length() > 0) {
> qName = prefix + ":" + localName;
> }
> String nsUri = parent.getNamespaceURI();
> return doc.createElementNS(nsUri, qName);
> }
> }
> {code}
> Same kind of document fix should be done on the actions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CXF-7363) Support saaj-impl 1.4
Romain Manni-Bucau created CXF-7363:
---
Summary: Support saaj-impl 1.4
Key: CXF-7363
URL: https://issues.apache.org/jira/browse/CXF-7363
Project: CXF
Issue Type: Bug
Reporter: Romain Manni-Bucau
org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor (and actions like
UsernameTokenAction) don't build the dom correctly and it fails with saaj(impl
1.4, here a way to build correctly the dom for the header appending:
{code}
new WSS4JOutInterceptor(outProps) {
@Override
protected void doSenderAction(final Document doc, final RequestData
reqData,
final List actions,
final boolean isRequest) throws WSSecurityException {
final String soapNamespace =
WSSecurityUtil.getSOAPNamespace(doc.getDocumentElement());
Element header =
XMLUtils.getDirectChildElement(doc.getDocumentElement(),
WSConstants.ELEM_HEADER, soapNamespace);
final Element envelope = doc.getDocumentElement();
if (header == null) {
header =
createElementInSameNamespace(envelope.getOwnerDocument(), envelope,
WSConstants.ELEM_HEADER);
final Node firstChild = envelope.getFirstChild();
if (firstChild == null) {
envelope.appendChild(header);
} else {
envelope.insertBefore(header, firstChild);
}
}
Element securityHeader =
WSSecurityUtil.getSecurityHeader(header, getString(WSHandlerConstants.ACTOR,
reqData.getMsgContext()), WSConstants.URI_SOAP12_ENV.equals(soapNamespace));
if (securityHeader == null) {
securityHeader =
header.getOwnerDocument().createElementNS(WSConstants.WSSE_NS, "wsse:Security");
securityHeader.setAttributeNS(WSConstants.XMLNS_NS,
"xmlns:wsse", WSConstants.WSSE_NS);
final Node firstChild = header.getFirstChild();
if (firstChild == null) {
header.appendChild(securityHeader);
} else {
header.insertBefore(securityHeader, firstChild);
}
}
super.doSenderAction(doc, reqData, actions, isRequest);
}
private Element createElementInSameNamespace(final Document doc,
final Element parent, final String localName) {
String qName = localName;
String prefix = parent.getPrefix();
if (prefix != null && prefix.length() > 0) {
qName = prefix + ":" + localName;
}
String nsUri = parent.getNamespaceURI();
return doc.createElementNS(nsUri, qName);
}
}
{code}
Same kind of document fix should be done on the actions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CXF-7361) Java 9 support for CXFAuthenticator
[ https://issues.apache.org/jira/browse/CXF-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated CXF-7361: Issue Type: Improvement (was: Bug) > Java 9 support for CXFAuthenticator > --- > > Key: CXF-7361 > URL: https://issues.apache.org/jira/browse/CXF-7361 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.11 >Reporter: Romain Manni-Bucau > > with java 9, Authenticator getDefault() should be used instead of field.get() > (setAccessible fails) + unsafe should be used to define the class instead > of the failing ClassLoader.defineClass. > All that with reflection of course and in fallback mode probably since for > java 8 it is better to not do it (or it is not available - getDefault() > typically). > Workaround ATM is to call CXFAuthenticator.addAuthenticator(); manually and > ignore the exception, it initializes the instance then it doesn't fail but > the feature is lost until it gets fixed as mentionned before. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CXF-7361) Java 9 support for CXFAuthenticator
Romain Manni-Bucau created CXF-7361: --- Summary: Java 9 support for CXFAuthenticator Key: CXF-7361 URL: https://issues.apache.org/jira/browse/CXF-7361 Project: CXF Issue Type: Bug Affects Versions: 3.1.11 Reporter: Romain Manni-Bucau with java 9, Authenticator getDefault() should be used instead of field.get() (setAccessible fails) + unsafe should be used to define the class instead of the failing ClassLoader.defineClass. All that with reflection of course and in fallback mode probably since for java 8 it is better to not do it (or it is not available - getDefault() typically). Workaround ATM is to call CXFAuthenticator.addAuthenticator(); manually and ignore the exception, it initializes the instance then it doesn't fail but the feature is lost until it gets fixed as mentionned before. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CXF-7332) JAXRS Client API doesnt support lambda
[
https://issues.apache.org/jira/browse/CXF-7332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972887#comment-15972887
]
Romain Manni-Bucau commented on CXF-7332:
-
sure, not working code (just lambdify previous one):
{code}
final Client client = ClientBuilder.newClient()
.register((ClientRequestFilter) ctx ->
ctx.getHeaders().put("Authorization", singletonList("")));
{code}
Is it a CXF or JAX-RS issue: can I propose, between answer A and B, the answer
C? ie Java itself? Anyway CXF can support it and I think it would be fancy even
if not portable, wdyt?
> JAXRS Client API doesnt support lambda
> --
>
> Key: CXF-7332
> URL: https://issues.apache.org/jira/browse/CXF-7332
> Project: CXF
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>
> {code}
> final Client client = ClientBuilder.newClient()
> .register(new ClientRequestFilter() {
> @Override
> public void filter(final ClientRequestContext
> requestContext) throws IOException {
> requestContext.getHeaders().put("Authorization",
> singletonList(""));
> }
> });
> {code}
> this code works but if you migrate as allowed by java 8 to filter to a lambda
> then cxf doesnt identify the type properly and bypass it
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CXF-7337) [cdi] allow to inject @Context
Romain Manni-Bucau created CXF-7337: --- Summary: [cdi] allow to inject @Context Key: CXF-7337 URL: https://issues.apache.org/jira/browse/CXF-7337 Project: CXF Issue Type: Task Components: JAX-RS Reporter: Romain Manni-Bucau It is nice to be able to get @Context through CDI (@Inject) to be able to use that in interceptors, this requires the JAXRS CDI extension to register them as beans with the qualifier @Context. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CXF-7336) [cdi] wrong org.apache.cxf.cdi.CdiResourceProvider#isSingleton implementation
Romain Manni-Bucau created CXF-7336: --- Summary: [cdi] wrong org.apache.cxf.cdi.CdiResourceProvider#isSingleton implementation Key: CXF-7336 URL: https://issues.apache.org/jira/browse/CXF-7336 Project: CXF Issue Type: Task Components: JAX-RS Reporter: Romain Manni-Bucau org.apache.cxf.cdi.CdiResourceProvider#isSingleton returns "is not request scoped" but cdi will issue a contextual proxy for @RequestScoped instances so a @RequestScoped instance *is* a singleton. The implementation should be !beanManager.isNormalScope(bean.getScope()). If a normal scope (@ApplicationScoped, @RequestScoped...) then the context is managed outside the proxy and the proxy is a singleton. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CXF-7332) JAXRS Client API doesnt support lambda
Romain Manni-Bucau created CXF-7332:
---
Summary: JAXRS Client API doesnt support lambda
Key: CXF-7332
URL: https://issues.apache.org/jira/browse/CXF-7332
Project: CXF
Issue Type: Bug
Reporter: Romain Manni-Bucau
{code}
final Client client = ClientBuilder.newClient()
.register(new ClientRequestFilter() {
@Override
public void filter(final ClientRequestContext
requestContext) throws IOException {
requestContext.getHeaders().put("Authorization",
singletonList(""));
}
});
{code}
this code works but if you migrate as allowed by java 8 to filter to a lambda
then cxf doesnt identify the type properly and bypass it
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CXF-7331) javax.ws.rs.container.ResourceInfo#getResourceClass doesnt unwrap the class
Romain Manni-Bucau created CXF-7331: --- Summary: javax.ws.rs.container.ResourceInfo#getResourceClass doesnt unwrap the class Key: CXF-7331 URL: https://issues.apache.org/jira/browse/CXF-7331 Project: CXF Issue Type: Bug Reporter: Romain Manni-Bucau javax.ws.rs.container.ResourceInfo#getResourceClass should call the Unwrapper otherwise you compare user classes with proxied classes which makes the matching not as easy as it should in several cases -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CXF-7324) [cdi] allow to define applications getClasses by declaration on resources
[
https://issues.apache.org/jira/browse/CXF-7324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated CXF-7324:
Priority: Minor (was: Major)
> [cdi] allow to define applications getClasses by declaration on resources
> -
>
> Key: CXF-7324
> URL: https://issues.apache.org/jira/browse/CXF-7324
> Project: CXF
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>Priority: Minor
>
> Idea is to reverse the Application pattern by having an "empty" application
> (ie scanning by spec) and mark a resource as belonging to the application:
> {code}
> @org.apache.cxf.rs.cdi.ApplicationType(MyApp.class)
> @Path("test")
> public class MyTestEndpointBelongsToMyAppApp {...}
> {code}
> Why is that useful? cause if you develop N applications (N > 1) using
> autoscanning but Application class to define the path (@ApplicationPath) and
> then merge them (packaging detail) then you will get 3 times the same
> deployment instead of 3 distincts applications.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CXF-7324) [cdi] allow to define applications getClasses by declaration on resources
Romain Manni-Bucau created CXF-7324:
---
Summary: [cdi] allow to define applications getClasses by
declaration on resources
Key: CXF-7324
URL: https://issues.apache.org/jira/browse/CXF-7324
Project: CXF
Issue Type: New Feature
Reporter: Romain Manni-Bucau
Idea is to reverse the Application pattern by having an "empty" application (ie
scanning by spec) and mark a resource as belonging to the application:
{code}
@org.apache.cxf.rs.cdi.ApplicationType(MyApp.class)
@Path("test")
public class MyTestEndpointBelongsToMyAppApp {...}
{code}
Why is that useful? cause if you develop N applications (N > 1) using
autoscanning but Application class to define the path (@ApplicationPath) and
then merge them (packaging detail) then you will get 3 times the same
deployment instead of 3 distincts applications.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CXF-7319) cdi extension uses wrong namespace for beans.xml
Romain Manni-Bucau created CXF-7319: --- Summary: cdi extension uses wrong namespace for beans.xml Key: CXF-7319 URL: https://issues.apache.org/jira/browse/CXF-7319 Project: CXF Issue Type: Bug Reporter: Romain Manni-Bucau the beans.xml in cdi module uses jboss namespace, it should be http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd and not jboss one i think -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CXF-7229) ClassHelper usages not replacable by ClassUnwrapper
[ https://issues.apache.org/jira/browse/CXF-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15843554#comment-15843554 ] Romain Manni-Bucau commented on CXF-7229: - Sure, in one word: ensure CXF exposes to users a single API (unwrapper today) and to core dev a single entry point as well consistent with user one. Enjoy your week end! > ClassHelper usages not replacable by ClassUnwrapper > --- > > Key: CXF-7229 > URL: https://issues.apache.org/jira/browse/CXF-7229 > Project: CXF > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko > Attachments: proxy-test-annotations.txt, proxy-test-case.txt > > > ClassUnwrapper and ClassHelper are pretty close and for an app setting a > single one should be enough (in particular cause ClassHelper overriding is > hacky) > Spotted org.apache.cxf.jaxrs.utils.InjectionUtils#getRawResponseClass for > instance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7229) ClassHelper usages not replacable by ClassUnwrapper
[ https://issues.apache.org/jira/browse/CXF-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15843191#comment-15843191 ] Romain Manni-Bucau commented on CXF-7229: - yep, only remaining part is probably to @Deprecate ClassHelper if possible to avoid to keep concurrent usages of this one and ClassWrapper but issues are solved :) > ClassHelper usages not replacable by ClassUnwrapper > --- > > Key: CXF-7229 > URL: https://issues.apache.org/jira/browse/CXF-7229 > Project: CXF > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko > Attachments: proxy-test-case.txt > > > ClassUnwrapper and ClassHelper are pretty close and for an app setting a > single one should be enough (in particular cause ClassHelper overriding is > hacky) > Spotted org.apache.cxf.jaxrs.utils.InjectionUtils#getRawResponseClass for > instance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7229) ClassHelper usages not replacable by ClassUnwrapper
[ https://issues.apache.org/jira/browse/CXF-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15843105#comment-15843105 ] Romain Manni-Bucau commented on CXF-7229: - clarification: *this* jira was just to slowly ensure CXF uses a single overridable by the user "unwrapper" (kind of merge ClassHelper and ClassUnwrapper). The other one (https://issues.apache.org/jira/browse/CXF-7228) was about ensuring providers are proxy friendly > ClassHelper usages not replacable by ClassUnwrapper > --- > > Key: CXF-7229 > URL: https://issues.apache.org/jira/browse/CXF-7229 > Project: CXF > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko > Attachments: proxy-test-case.txt > > > ClassUnwrapper and ClassHelper are pretty close and for an app setting a > single one should be enough (in particular cause ClassHelper overriding is > hacky) > Spotted org.apache.cxf.jaxrs.utils.InjectionUtils#getRawResponseClass for > instance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7229) ClassHelper usages not replacable by ClassUnwrapper
[
https://issues.apache.org/jira/browse/CXF-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15842913#comment-15842913
]
Romain Manni-Bucau commented on CXF-7229:
-
Seems the code changed since I checked,
org.apache.cxf.jaxrs.provider.ProviderFactory#handleMapper takes care of that.
Here is a test (passing) using cglib (which drops annotations from the proxy
class itself):
{code}
import net.sf.cglib.proxy.Dispatcher;
import net.sf.cglib.proxy.Enhancer;
import org.apache.cxf.endpoint.Server;
import org.apache.cxf.jaxrs.JAXRSServerFactoryBean;
import org.apache.cxf.jaxrs.client.WebClient;
import org.apache.cxf.transport.local.LocalConduit;
import org.junit.Test;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.WebApplicationException;
import javax.ws.rs.client.Client;
import javax.ws.rs.client.ClientBuilder;
import javax.ws.rs.client.Invocation;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.MultivaluedMap;
import javax.ws.rs.ext.MessageBodyWriter;
import javax.ws.rs.ext.Provider;
import java.io.IOException;
import java.io.OutputStream;
import java.lang.annotation.Annotation;
import java.lang.annotation.Retention;
import java.lang.annotation.Target;
import java.lang.reflect.Type;
import java.nio.charset.StandardCharsets;
import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.RetentionPolicy.RUNTIME;
import static javax.ws.rs.core.MediaType.APPLICATION_JSON_TYPE;
import static org.junit.Assert.assertEquals;
public class ViciousServiceTest {
@Test
public void run() {
final JAXRSServerFactoryBean serverFactoryBean = new
JAXRSServerFactoryBean();
serverFactoryBean.setProvider(new PlainSerializer());
serverFactoryBean.setResourceClasses(ViciousService.class);
serverFactoryBean.setAddress("local://road");
final Server server = serverFactoryBean.create();
try {
final Client client = ClientBuilder.newClient();
try {
final Invocation.Builder builder = client.target("local://road")
.request(APPLICATION_JSON_TYPE);
WebClient.getConfig(builder).getRequestContext().put(LocalConduit.DIRECT_DISPATCH,
Boolean.TRUE);
final String response = builder.get(String.class);
assertEquals("{\"worked\":true}", response);
} finally {
client.close();
}
} finally {
server.destroy();
}
}
@Target(TYPE)
@Retention(RUNTIME)
public @interface Plain {
}
@Provider
@Produces(MediaType.APPLICATION_JSON)
public static class PlainSerializer implements
MessageBodyWriter {
@Override
public boolean isWriteable(final Class aClass, final Type type,
final Annotation[] annotations, final MediaType mediaType) {
return aClass.isAnnotationPresent(Plain.class);
}
@Override
public long getSize(final PleaseDontProxyMe PleaseDontProxyMe, final
Class aClass, final Type type, final Annotation[] annotations, final
MediaType mediaType) {
return 0;
}
@Override
public void writeTo(final PleaseDontProxyMe PleaseDontProxyMe, final
Class aClass, final Type type, final Annotation[] annotations,
final MediaType mediaType, final
MultivaluedMap multivaluedMap, final OutputStream outputStream)
throws IOException, WebApplicationException {
outputStream.write("{\"worked\":true}".getBytes(StandardCharsets.UTF_8));
}
}
@Plain
public static class PleaseDontProxyMe {
}
@Path("/")
public static class ViciousService {
@GET
@Produces(MediaType.APPLICATION_JSON)
public PleaseDontProxyMe get() {
final PleaseDontProxyMe willBeProxied = new PleaseDontProxyMe(); //
in real code it is a service.findById(1) or whatever
// replace a big stack like JPA/spring/cdi/... creating a proxy.
Using cglib
final Enhancer enhancer = new Enhancer();
enhancer.setClassLoader(Thread.currentThread().getContextClassLoader());
enhancer.setSuperclass(PleaseDontProxyMe.class);
enhancer.setCallback(new Dispatcher() {
@Override
public Object loadObject() throws Exception {
return willBeProxied;
}
});
final Object o = enhancer.create();
return PleaseDontProxyMe.class.cast(o);
}
}
}
/* pom.xml dependencies
org.apache.geronimo.specs
geronimo-servlet_3.0_spec
1.0
org.apache.cxf
cxf-rt-frontend-jaxrs
3.1.9
org.apache.cxf
cxf-rt-rs-client
3.1.9
org.apache.cxf
cxf-rt-transports-l
[jira] [Commented] (CXF-7229) ClassHelper usages not replacable by ClassUnwrapper
[ https://issues.apache.org/jira/browse/CXF-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15842869#comment-15842869 ] Romain Manni-Bucau commented on CXF-7229: - The loss of custom annotations is expected by several frameworks so this is not something which will change I fear (or that CXF can control). Regarding your point, if you take my previous answer you will see it is ok since the MBW will keep current behavior by default until an unwrapper is register and in such a case the unwrapping belongs to the impl so it sounds perfectly valid to me. Most of the time the unwrapper will remove well know proxies the MBW will never handle like spring, weld, owb proxies. If you worry about this case (once again I think the risk it breaks anything is very very low) we can still enrich the ClassUnwrapper with a dedicated method probably. > ClassHelper usages not replacable by ClassUnwrapper > --- > > Key: CXF-7229 > URL: https://issues.apache.org/jira/browse/CXF-7229 > Project: CXF > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko > Attachments: proxy-test-case.txt > > > ClassUnwrapper and ClassHelper are pretty close and for an app setting a > single one should be enough (in particular cause ClassHelper overriding is > hacky) > Spotted org.apache.cxf.jaxrs.utils.InjectionUtils#getRawResponseClass for > instance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7229) ClassHelper usages not replacable by ClassUnwrapper
[ https://issues.apache.org/jira/browse/CXF-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15842851#comment-15842851 ] Romain Manni-Bucau commented on CXF-7229: - [~sergeyb] we do know since there is or not the unwrapper. If the unwrapper is there any object should go through it IMHO, if not there your proposal is more than valid as default. > ClassHelper usages not replacable by ClassUnwrapper > --- > > Key: CXF-7229 > URL: https://issues.apache.org/jira/browse/CXF-7229 > Project: CXF > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko > Attachments: proxy-test-case.txt > > > ClassUnwrapper and ClassHelper are pretty close and for an app setting a > single one should be enough (in particular cause ClassHelper overriding is > hacky) > Spotted org.apache.cxf.jaxrs.utils.InjectionUtils#getRawResponseClass for > instance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7229) ClassHelper usages not replacable by ClassUnwrapper
[
https://issues.apache.org/jira/browse/CXF-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15842836#comment-15842836
]
Romain Manni-Bucau commented on CXF-7229:
-
[~sergeyb] well the MBW impl could do it...means they ALL need to have the
support for ALL possible proxies. CXF introduces Class[Unwrapper|Helper]
concept to ensure you can set it and integrate with any 3rd party frameworks
transparently. I think it is an awesome CXF feature and would be very
beneficial there. Worse case the unwrapping is very cheap
(getClass().getName().contains("...") only) and doesn't affect perf but it
enables several cases so I still think it does worth it. Side note: this issue
is more about the consistency of the unwrapper usage (which is a SPI vs the
hardcoded helper), the other one is about the unwrapping need.
> ClassHelper usages not replacable by ClassUnwrapper
> ---
>
> Key: CXF-7229
> URL: https://issues.apache.org/jira/browse/CXF-7229
> Project: CXF
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>Assignee: Andriy Redko
> Attachments: proxy-test-case.txt
>
>
> ClassUnwrapper and ClassHelper are pretty close and for an app setting a
> single one should be enough (in particular cause ClassHelper overriding is
> hacky)
> Spotted org.apache.cxf.jaxrs.utils.InjectionUtils#getRawResponseClass for
> instance
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7229) ClassHelper usages not replacable by ClassUnwrapper
[ https://issues.apache.org/jira/browse/CXF-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15842502#comment-15842502 ] Romain Manni-Bucau commented on CXF-7229: - Yes that's the case, suppose you use jaxb and the serializer you use needs @XmlElement on getPrice() but you return through 7 stacks of frameworks (actually 2-3 in real life) a proxy which drops the annotations then CXF will be lost until it uses the unwrapped class. > ClassHelper usages not replacable by ClassUnwrapper > --- > > Key: CXF-7229 > URL: https://issues.apache.org/jira/browse/CXF-7229 > Project: CXF > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko > Attachments: proxy-test-case.txt > > > ClassUnwrapper and ClassHelper are pretty close and for an app setting a > single one should be enough (in particular cause ClassHelper overriding is > hacky) > Spotted org.apache.cxf.jaxrs.utils.InjectionUtils#getRawResponseClass for > instance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7229) ClassHelper usages not replacable by ClassUnwrapper
[
https://issues.apache.org/jira/browse/CXF-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837774#comment-15837774
]
Romain Manni-Bucau commented on CXF-7229:
-
[~sergeyb] this is not CDI specific, CDI is just where it comes from for me.
You get the same with spring or plain standalone apps.
{code}
@Inject // or whatever way to get a proxy
private ProxyWithoutAnnotation value;
@GET ProxyWithoutAnnotation get() { return value; }
{code}
if the writer needs an annotation on value it will be broken.
> ClassHelper usages not replacable by ClassUnwrapper
> ---
>
> Key: CXF-7229
> URL: https://issues.apache.org/jira/browse/CXF-7229
> Project: CXF
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>
> ClassUnwrapper and ClassHelper are pretty close and for an app setting a
> single one should be enough (in particular cause ClassHelper overriding is
> hacky)
> Spotted org.apache.cxf.jaxrs.utils.InjectionUtils#getRawResponseClass for
> instance
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7229) ClassHelper usages not replacable by ClassUnwrapper
[ https://issues.apache.org/jira/browse/CXF-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837727#comment-15837727 ] Romain Manni-Bucau commented on CXF-7229: - I have cases where it can fail, they are a bit boderline but easy to reproduce: just use a CDI applicationScoped bean representing a constant exposed to the client (done sometimes to return a server configuration which is constant for the app but dynamic by instance) and which depends on some writer annotations and you will get this issue. > ClassHelper usages not replacable by ClassUnwrapper > --- > > Key: CXF-7229 > URL: https://issues.apache.org/jira/browse/CXF-7229 > Project: CXF > Issue Type: Bug >Reporter: Romain Manni-Bucau > > ClassUnwrapper and ClassHelper are pretty close and for an app setting a > single one should be enough (in particular cause ClassHelper overriding is > hacky) > Spotted org.apache.cxf.jaxrs.utils.InjectionUtils#getRawResponseClass for > instance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7229) ClassHelper usages not replacable by ClassUnwrapper
[
https://issues.apache.org/jira/browse/CXF-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837694#comment-15837694
]
Romain Manni-Bucau commented on CXF-7229:
-
yep, assume you have MyEntity which is proxied and the proxy lib has the
awesome idea to remove annotation (or not propagate them to the proxy which is
50% of the impl for good and bad reasons). You will do:
{code}
return entities.find(1); // returns MyEntity proxy
{code}
then you hit the referenced method
(https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/InjectionUtils.java#L1400)
which calls getRealClassFromClass which calls getRealClassFromClassInternal
which bypasses any unwrapper logic
(https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/common/util/ClassHelper.java#L60)
since getRealClass(Bus bus, Object o) is not used. Also think it would be
better to pass the bus in that call just in case the thread local is not set
> ClassHelper usages not replacable by ClassUnwrapper
> ---
>
> Key: CXF-7229
> URL: https://issues.apache.org/jira/browse/CXF-7229
> Project: CXF
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>
> ClassUnwrapper and ClassHelper are pretty close and for an app setting a
> single one should be enough (in particular cause ClassHelper overriding is
> hacky)
> Spotted org.apache.cxf.jaxrs.utils.InjectionUtils#getRawResponseClass for
> instance
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7229) ClassHelper usages not replacable by ClassUnwrapper
[ https://issues.apache.org/jira/browse/CXF-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837611#comment-15837611 ] Romain Manni-Bucau commented on CXF-7229: - there still are some cases where classhelper is used but not the unwrapper. Since unwrapper is per bus it should always override the helper which is static (and not designed to be overriden). Idea of this task is to ensure ClassHelper can be deleted and replaced by a default unwrapper more or less to ensure applications setting an unwrapper doesnt need to hack the helper as well. It is typically the case for the response (if you return a proxied jpa entity for instance your unwrapper is bypassed) > ClassHelper usages not replacable by ClassUnwrapper > --- > > Key: CXF-7229 > URL: https://issues.apache.org/jira/browse/CXF-7229 > Project: CXF > Issue Type: Bug >Reporter: Romain Manni-Bucau > > ClassUnwrapper and ClassHelper are pretty close and for an app setting a > single one should be enough (in particular cause ClassHelper overriding is > hacky) > Spotted org.apache.cxf.jaxrs.utils.InjectionUtils#getRawResponseClass for > instance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7229) ClassHelper usages not replacable by ClassUnwrapper
Romain Manni-Bucau created CXF-7229: --- Summary: ClassHelper usages not replacable by ClassUnwrapper Key: CXF-7229 URL: https://issues.apache.org/jira/browse/CXF-7229 Project: CXF Issue Type: Bug Reporter: Romain Manni-Bucau ClassUnwrapper and ClassHelper are pretty close and for an app setting a single one should be enough (in particular cause ClassHelper overriding is hacky) Spotted org.apache.cxf.jaxrs.utils.InjectionUtils#getRawResponseClass for instance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7228) ProviderInfo rarely supports proxies
Romain Manni-Bucau created CXF-7228: --- Summary: ProviderInfo rarely supports proxies Key: CXF-7228 URL: https://issues.apache.org/jira/browse/CXF-7228 Project: CXF Issue Type: Bug Reporter: Romain Manni-Bucau CXF has a lot of pi.getProvider().getClass() usages but it breaks when using proxies not propagating annotations (@Priority - org.apache.cxf.jaxrs.provider.ServerProviderFactory.ServerConfigurationImpl#getPriority, name bindings org.apache.cxf.jaxrs.provider.ProviderFactory#getFilterNameBindings, etc) Using at least org.apache.cxf.common.util.ClassHelper would solve this (and this API is designed for it isnt it?). Also using ClassUnwrapper would be consistent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7207) JCacheOAuthDataProvider can leak jcache component(s)
Romain Manni-Bucau created CXF-7207: --- Summary: JCacheOAuthDataProvider can leak jcache component(s) Key: CXF-7207 URL: https://issues.apache.org/jira/browse/CXF-7207 Project: CXF Issue Type: Bug Reporter: Romain Manni-Bucau provider should be closed and not only the manager -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7098) Logging feature broken in async usage
Romain Manni-Bucau created CXF-7098: --- Summary: Logging feature broken in async usage Key: CXF-7098 URL: https://issues.apache.org/jira/browse/CXF-7098 Project: CXF Issue Type: Bug Reporter: Romain Manni-Bucau Hi, fear the issue is wider than logging but coming from that part of CXF. Please see http://tomee-openejb.979440.n4.nabble.com/cxf-interceptors-in-2-0-api-td4680333.html#a4680396 In short using async() on client side the request uses 2 async threads and leads to an inconsistent logging (through the feature). I didn't dig enough to know if it is cause the message is not thread safe or not but this is quite embarassing ;) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7097) [CDI] application leaks a creational context
Romain Manni-Bucau created CXF-7097: --- Summary: [CDI] application leaks a creational context Key: CXF-7097 URL: https://issues.apache.org/jira/browse/CXF-7097 Project: CXF Issue Type: Bug Reporter: Romain Manni-Bucau JAXRS application are not CDI beans but that's the way CXF CDI integration gets the application - this is a nice feature. It implies the application will rarely be normal-scope so it needs to release its creational context created at org.apache.cxf.cdi.JAXRSCdiResourceExtension#load This should be done in BeforeShutdown container event I think. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7095) CDI integration doesn't use the right bus to create the server factory
Romain Manni-Bucau created CXF-7095: --- Summary: CDI integration doesn't use the right bus to create the server factory Key: CXF-7095 URL: https://issues.apache.org/jira/browse/CXF-7095 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 3.1.7 Reporter: Romain Manni-Bucau See http://cxf.547215.n5.nabble.com/cxi-integration-multiple-buses-during-deployment-td5773977.html In short when creating the server in the cdi extension, the bus should be propagated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
