[jira] [Created] (CXF-6986) Don't require an application class if using CDI
John D. Ament created CXF-6986: -- Summary: Don't require an application class if using CDI Key: CXF-6986 URL: https://issues.apache.org/jira/browse/CXF-6986 Project: CXF Issue Type: Improvement Reporter: John D. Ament The current CXF-CDI integration assumes there will be an application class. It would be great if CXF did not require an application class, to simplify developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6987) Consider both CDI managed and not CDI managed beans in CXFCdiServlet
John D. Ament created CXF-6987:
--
Summary: Consider both CDI managed and not CDI managed beans in
CXFCdiServlet
Key: CXF-6987
URL: https://issues.apache.org/jira/browse/CXF-6987
Project: CXF
Issue Type: Improvement
Reporter: John D. Ament
CXF's CDI integration integration assumes that all of the components included
will be CDI beans.
- It ignores classes defined.
- It doesn't handle {{@Vetoed}} beans.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider both CDI managed and not CDI managed beans in CXFCdiServlet
[
https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15403759#comment-15403759
]
John D. Ament commented on CXF-6987:
BTW, I'll need a few days, but I plan to provide a patch.
> Consider both CDI managed and not CDI managed beans in CXFCdiServlet
>
>
> Key: CXF-6987
> URL: https://issues.apache.org/jira/browse/CXF-6987
> Project: CXF
> Issue Type: Improvement
>Reporter: John D. Ament
>
> CXF's CDI integration integration assumes that all of the components included
> will be CDI beans.
> - It ignores classes defined.
> - It doesn't handle {{@Vetoed}} beans.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15403757#comment-15403757 ] John D. Ament commented on CXF-6986: BTW, I plan to provide a patch for this within a day or two. > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6987) Consider classes attribute of application when using CDI
[
https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament updated CXF-6987:
---
Summary: Consider classes attribute of application when using CDI (was:
Consider both CDI managed and not CDI managed beans in CXFCdiServlet)
> Consider classes attribute of application when using CDI
>
>
> Key: CXF-6987
> URL: https://issues.apache.org/jira/browse/CXF-6987
> Project: CXF
> Issue Type: Improvement
>Reporter: John D. Ament
>
> CXF's CDI integration integration assumes that all of the components included
> will be CDI beans.
> - It ignores classes defined.
> - It doesn't handle {{@Vetoed}} beans.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6987) Consider classes attribute of application when using CDI
[
https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament updated CXF-6987:
---
Description:
CXF's CDI integration integration assumes that all of the components included
will be CDI beans. They either need to be defined as singletons, or picked up
via scanning. If singleton is specified, the classes are ignored.
- It ignores classes defined.
was:
CXF's CDI integration integration assumes that all of the components included
will be CDI beans.
- It ignores classes defined.
- It doesn't handle {{@Vetoed}} beans.
> Consider classes attribute of application when using CDI
>
>
> Key: CXF-6987
> URL: https://issues.apache.org/jira/browse/CXF-6987
> Project: CXF
> Issue Type: Improvement
>Reporter: John D. Ament
>
> CXF's CDI integration integration assumes that all of the components included
> will be CDI beans. They either need to be defined as singletons, or picked
> up via scanning. If singleton is specified, the classes are ignored.
> - It ignores classes defined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6987) Consider classes attribute of application when using CDI
[ https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament updated CXF-6987: --- Affects Version/s: 3.1.6 > Consider classes attribute of application when using CDI > > > Key: CXF-6987 > URL: https://issues.apache.org/jira/browse/CXF-6987 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > CXF's CDI integration integration assumes that all of the components included > will be CDI beans. They either need to be defined as singletons, or picked > up via scanning. If singleton is specified, the classes are ignored. > - It ignores classes defined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament updated CXF-6986: --- Affects Version/s: 3.1.6 > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6988) Improved test suite for CDI systests
John D. Ament created CXF-6988: -- Summary: Improved test suite for CDI systests Key: CXF-6988 URL: https://issues.apache.org/jira/browse/CXF-6988 Project: CXF Issue Type: Improvement Reporter: John D. Ament The CDI systests assume certain behaviors within tests. They should be a bit more flexible in their supported environments, and not always need to deploy the entire classpath. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6998) Manual resolve ApplicationPath from parent classes as well.
John D. Ament created CXF-6998: -- Summary: Manual resolve ApplicationPath from parent classes as well. Key: CXF-6998 URL: https://issues.apache.org/jira/browse/CXF-6998 Project: CXF Issue Type: Improvement Components: JAX-RS Reporter: John D. Ament The ApplicationPath annotation is not inherited. As a result, when proxies are used (for things like CDI integration), those proxies do not have the application path defined. As a result, the base URI is ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7101) SpringBoot JAX-WS example fails
John D. Ament created CXF-7101:
--
Summary: SpringBoot JAX-WS example fails
Key: CXF-7101
URL: https://issues.apache.org/jira/browse/CXF-7101
Project: CXF
Issue Type: Bug
Components: Samples
Affects Versions: 3.1.7
Reporter: John D. Ament
The JAX-WS example fails with the following:
{code}
[WARNING] Warning: killAfter is now deprecated. Do you need it ? Please comment
on MEXEC-6.
[WARNING]
java.lang.ClassNotFoundException: sample.ws.service.client.HelloClient
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:281)
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7102) Add CDI Demos
John D. Ament created CXF-7102: -- Summary: Add CDI Demos Key: CXF-7102 URL: https://issues.apache.org/jira/browse/CXF-7102 Project: CXF Issue Type: Improvement Reporter: John D. Ament Fix For: 3.1.9 Add new CDI based demos to the samples distribution. Ideally they should demonstrate the same features as available in the Spring Boot demos: - Service discovery via Eureka - Deploying client and server -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7103) CDI Client Proxy injection
John D. Ament created CXF-7103: -- Summary: CDI Client Proxy injection Key: CXF-7103 URL: https://issues.apache.org/jira/browse/CXF-7103 Project: CXF Issue Type: Improvement Reporter: John D. Ament Fix For: 3.1.9 Add support for injecting client proxies via CDI, without additional producer methods etc being required. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6998) Manual resolve ApplicationPath from parent classes as well.
[ https://issues.apache.org/jira/browse/CXF-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament updated CXF-6998: --- Fix Version/s: 3.1.8 > Manual resolve ApplicationPath from parent classes as well. > --- > > Key: CXF-6998 > URL: https://issues.apache.org/jira/browse/CXF-6998 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: John D. Ament >Assignee: Andriy Redko > Fix For: 3.1.8 > > > The ApplicationPath annotation is not inherited. As a result, when proxies > are used (for things like CDI integration), those proxies do not have the > application path defined. As a result, the base URI is ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6987) Consider classes attribute of application when using CDI
[ https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament updated CXF-6987: --- Fix Version/s: 3.1.8 > Consider classes attribute of application when using CDI > > > Key: CXF-6987 > URL: https://issues.apache.org/jira/browse/CXF-6987 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament >Assignee: Andriy Redko > Fix For: 3.1.8 > > > CXF's CDI integration integration assumes that all of the components included > will be CDI beans. They either need to be defined as singletons, or picked > up via scanning. If singleton is specified, the classes are ignored. > - It ignores classes defined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6988) Improved test suite for CDI systests
[ https://issues.apache.org/jira/browse/CXF-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament updated CXF-6988: --- Fix Version/s: 3.1.9 Component/s: Integration Build system > Improved test suite for CDI systests > > > Key: CXF-6988 > URL: https://issues.apache.org/jira/browse/CXF-6988 > Project: CXF > Issue Type: Improvement > Components: Build system, Integration >Reporter: John D. Ament > Fix For: 3.1.9 > > > The CDI systests assume certain behaviors within tests. They should be a bit > more flexible in their supported environments, and not always need to deploy > the entire classpath. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7105) Don't register default application if no services discovered
John D. Ament created CXF-7105: -- Summary: Don't register default application if no services discovered Key: CXF-7105 URL: https://issues.apache.org/jira/browse/CXF-7105 Project: CXF Issue Type: Bug Components: Integration Affects Versions: 3.1.9 Reporter: John D. Ament Fix For: 3.1.9 In certain cases, the CXF CDI integration may be included blindly in a framework. In these cases, if the user does not provide any JAX-RS resources the integration will fail to deploy a server. This scenario should be handled gracefully by not registering the application. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7101) SpringBoot JAX-WS example fails
[
https://issues.apache.org/jira/browse/CXF-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15601613#comment-15601613
]
John D. Ament commented on CXF-7101:
Hi Sergey, yep, see that here. Is the file intended to be called
{{SampleWsApplicationTests}} e.g. {{Tests}} instead of {{Test}}? The spring
boot parent pom includes this, not sure if its intended or not on the CXF side.
{code}
org.apache.maven.plugins
maven-surefire-plugin
**/*Tests.java
**/*Test.java
**/Abstract*.java
{code}
So either we can rename the class, or add this mapping to the pom. Did any of
the other examples have tests?
> SpringBoot JAX-WS example fails
> ---
>
> Key: CXF-7101
> URL: https://issues.apache.org/jira/browse/CXF-7101
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Affects Versions: 3.1.7
>Reporter: John D. Ament
>
> The JAX-WS example fails with the following:
> {code}
> [WARNING] Warning: killAfter is now deprecated. Do you need it ? Please
> comment on MEXEC-6.
> [WARNING]
> java.lang.ClassNotFoundException: sample.ws.service.client.HelloClient
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:281)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7108) NOTICE file in Distribution is too broad
John D. Ament created CXF-7108:
--
Summary: NOTICE file in Distribution is too broad
Key: CXF-7108
URL: https://issues.apache.org/jira/browse/CXF-7108
Project: CXF
Issue Type: Bug
Components: Build system
Reporter: John D. Ament
The NOTICE file that gets included in the distribution is too broad, or at
least doesn't make it clear that this is only for the full distribution:
https://github.com/apache/cxf/blob/master/distribution/src/main/appended-resources/META-INF/NOTICE
In my case, using CXF I bring in a subset of your JARs
{code}
-rw-r--r-- 1 spartan staff 172863 Oct 17 15:24 cxf-rt-wsdl-3.1.7.jar
-rw-r--r-- 1 spartan staff 680540 Oct 17 15:24 cxf-rt-ws-security-3.1.7.jar
-rw-r--r-- 1 spartan staff 213517 Oct 17 15:24 cxf-rt-ws-policy-3.1.7.jar
-rw-r--r-- 1 spartan staff75855 Oct 17 15:24 cxf-rt-ws-addr-3.1.7.jar
-rw-r--r-- 1 spartan staff40917 Oct 17 15:24
cxf-rt-security-saml-3.1.7.jar
-rw-r--r-- 1 spartan staff32110 Oct 17 15:24 cxf-rt-security-3.1.7.jar
-rw-r--r-- 1 spartan staff 101548 Oct 17 15:24
cxf-rt-frontend-simple-3.1.7.jar
-rw-r--r-- 1 spartan staff 341830 Oct 17 15:24
cxf-rt-frontend-jaxws-3.1.7.jar
-rw-r--r-- 1 spartan staff 103823 Oct 17 15:24
cxf-rt-databinding-jaxb-3.1.7.jar
-rw-r--r-- 1 spartan staff37934 Oct 17 15:24 cxf-rt-bindings-xml-3.1.7.jar
-rw-r--r-- 1 spartan staff 178021 Oct 17 15:24
cxf-rt-bindings-soap-3.1.7.jar
-rw-r--r-- 1 spartan staff 1354879 Oct 17 15:24 cxf-core-3.1.7.jar
-rw-r--r-- 1 spartan staff 344190 Oct 17 15:24
cxf-rt-transports-http-3.1.7.jar
{code}
However, external interpretation is that your NOTICE file requires all of this
extra content - when not all of it applies in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7101) SpringBoot JAX-WS example fails
[
https://issues.apache.org/jira/browse/CXF-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15601866#comment-15601866
]
John D. Ament commented on CXF-7101:
Well getting it to run is the easy part, even the test runs fine when you do
{{-Dtest= SampleWsApplicationTests}}. The question is really how to get that
client class that is referenced. Any thoughts there?
> SpringBoot JAX-WS example fails
> ---
>
> Key: CXF-7101
> URL: https://issues.apache.org/jira/browse/CXF-7101
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Affects Versions: 3.1.7
>Reporter: John D. Ament
>
> The JAX-WS example fails with the following:
> {code}
> [WARNING] Warning: killAfter is now deprecated. Do you need it ? Please
> comment on MEXEC-6.
> [WARNING]
> java.lang.ClassNotFoundException: sample.ws.service.client.HelloClient
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:281)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7101) SpringBoot JAX-WS example fails
[
https://issues.apache.org/jira/browse/CXF-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15603008#comment-15603008
]
John D. Ament commented on CXF-7101:
This is probably the nicer approach. Is there any way to get that proxy now?
> SpringBoot JAX-WS example fails
> ---
>
> Key: CXF-7101
> URL: https://issues.apache.org/jira/browse/CXF-7101
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Affects Versions: 3.1.7
>Reporter: John D. Ament
>
> The JAX-WS example fails with the following:
> {code}
> [WARNING] Warning: killAfter is now deprecated. Do you need it ? Please
> comment on MEXEC-6.
> [WARNING]
> java.lang.ClassNotFoundException: sample.ws.service.client.HelloClient
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:281)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7132) CDI Multi-app tests fail when classes have scope
John D. Ament created CXF-7132: -- Summary: CDI Multi-app tests fail when classes have scope Key: CXF-7132 URL: https://issues.apache.org/jira/browse/CXF-7132 Project: CXF Issue Type: Bug Affects Versions: 3.1.9 Reporter: John D. Ament Fix For: 3.1.9 The multi-app tests fail due how to instances are managed in proxyable environments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-7132) CDI Multi-app tests fail when classes have scope
[ https://issues.apache.org/jira/browse/CXF-7132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament updated CXF-7132: --- Description: The multi-app tests fail due how to instances are managed in proxyable environments. When a normal scoped CDI Bean is used, the class is wrong. CXF is referencing the real class and getting a per-request instance of a CdiResourceProvider based instance. This causes fields to not be injected. (was: The multi-app tests fail due how to instances are managed in proxyable environments.) > CDI Multi-app tests fail when classes have scope > > > Key: CXF-7132 > URL: https://issues.apache.org/jira/browse/CXF-7132 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.9 >Reporter: John D. Ament > Fix For: 3.1.9 > > > The multi-app tests fail due how to instances are managed in proxyable > environments. When a normal scoped CDI Bean is used, the class is wrong. > CXF is referencing the real class and getting a per-request instance of a > CdiResourceProvider based instance. This causes fields to not be injected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7133) Don't rely on disabled scanning in CDI
John D. Ament created CXF-7133: -- Summary: Don't rely on disabled scanning in CDI Key: CXF-7133 URL: https://issues.apache.org/jira/browse/CXF-7133 Project: CXF Issue Type: Bug Components: Integration Affects Versions: 3.1.9 Reporter: John D. Ament Fix For: 3.1.9 In CXF-7097, a scan tag was added to turn off default application scanning. This approach doesn't work for all packaging types, and creates a bit of an issue informing consumers. Would be better if the class were just written correctly to not be discovered. I have a patch, will raise after the other one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7134) Fix how non-normal scoped beans are used in CDI extension
John D. Ament created CXF-7134: -- Summary: Fix how non-normal scoped beans are used in CDI extension Key: CXF-7134 URL: https://issues.apache.org/jira/browse/CXF-7134 Project: CXF Issue Type: Bug Components: Integration Affects Versions: 3.1.8 Reporter: John D. Ament Fix For: 3.1.9 When bean instances are looked up, they are never closed. We need to hold on to all creational contexts and destroy them afterwards. In addition, need to look at how dependent scoped beans are used. They're currently behaving like singletons which doesn't sound right. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7175) Wrong class specified for CdiBusBean
John D. Ament created CXF-7175:
--
Summary: Wrong class specified for CdiBusBean
Key: CXF-7175
URL: https://issues.apache.org/jira/browse/CXF-7175
Project: CXF
Issue Type: Bug
Components: Integration
Reporter: John D. Ament
https://github.com/apache/cxf/blob/3.1.x-fixes/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiBusBean.java#L43
This specifies the wrong class. Since the Bean created is specifically a
{{ExtensionManagerBus}} this should return {{ExtensionManagerBus.class}} not
{{Bus.class}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7175) Wrong class specified for CdiBusBean
[
https://issues.apache.org/jira/browse/CXF-7175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15739846#comment-15739846
]
John D. Ament commented on CXF-7175:
The funny thing, its probably a bug in the arquillian adapter more than
anything. However, section 5.1.4 of CDI 1.2 states:
bq. For a custom implementation of the Bean interface defined in The Bean
interface, the container calls getBeanClass() to determine the bean class of
the bean and InjectionPoint.getMember() and then Member.getDeclaringClass() to
determine the class that declares an injection point.
CXF is saying the bean class - and as a result the proxy - is `Bus` but it
should be a concrete implementation.
> Wrong class specified for CdiBusBean
>
>
> Key: CXF-7175
> URL: https://issues.apache.org/jira/browse/CXF-7175
> Project: CXF
> Issue Type: Bug
> Components: Integration
>Reporter: John D. Ament
>
> https://github.com/apache/cxf/blob/3.1.x-fixes/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiBusBean.java#L43
> This specifies the wrong class. Since the Bean created is specifically a
> {{ExtensionManagerBus}} this should return {{ExtensionManagerBus.class}} not
> {{Bus.class}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-7175) Wrong class specified for CdiBusBean
[
https://issues.apache.org/jira/browse/CXF-7175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15739846#comment-15739846
]
John D. Ament edited comment on CXF-7175 at 12/11/16 2:46 PM:
--
The funny thing, its probably a bug in the arquillian adapter more than
anything. However, section 5.1.4 of CDI 1.2 states:
bq. For a custom implementation of the Bean interface defined in The Bean
interface, the container calls getBeanClass() to determine the bean class of
the bean and InjectionPoint.getMember() and then Member.getDeclaringClass() to
determine the class that declares an injection point.
CXF is saying the bean class - and as a result the proxy - is {{Bus}} but it
should be a concrete implementation.
Event 11.1 agrees
bq. getBeanClass() returns the bean class of the managed bean or session bean
or of the bean that declares the producer method or field.
was (Author: johndament):
The funny thing, its probably a bug in the arquillian adapter more than
anything. However, section 5.1.4 of CDI 1.2 states:
bq. For a custom implementation of the Bean interface defined in The Bean
interface, the container calls getBeanClass() to determine the bean class of
the bean and InjectionPoint.getMember() and then Member.getDeclaringClass() to
determine the class that declares an injection point.
CXF is saying the bean class - and as a result the proxy - is `Bus` but it
should be a concrete implementation.
> Wrong class specified for CdiBusBean
>
>
> Key: CXF-7175
> URL: https://issues.apache.org/jira/browse/CXF-7175
> Project: CXF
> Issue Type: Bug
> Components: Integration
>Reporter: John D. Ament
>
> https://github.com/apache/cxf/blob/3.1.x-fixes/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiBusBean.java#L43
> This specifies the wrong class. Since the Bean created is specifically a
> {{ExtensionManagerBus}} this should return {{ExtensionManagerBus.class}} not
> {{Bus.class}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-7175) Wrong class specified for CdiBusBean
[
https://issues.apache.org/jira/browse/CXF-7175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15739846#comment-15739846
]
John D. Ament edited comment on CXF-7175 at 12/11/16 2:46 PM:
--
The funny thing, its probably a bug in the arquillian adapter more than
anything. However, section 5.1.4 of CDI 1.2 states:
bq. For a custom implementation of the Bean interface defined in The Bean
interface, the container calls getBeanClass() to determine the bean class of
the bean and InjectionPoint.getMember() and then Member.getDeclaringClass() to
determine the class that declares an injection point.
CXF is saying the bean class - and as a result the proxy - is {{Bus}} but it
should be a concrete implementation.
Even 11.1 agrees
bq. getBeanClass() returns the bean class of the managed bean or session bean
or of the bean that declares the producer method or field.
was (Author: johndament):
The funny thing, its probably a bug in the arquillian adapter more than
anything. However, section 5.1.4 of CDI 1.2 states:
bq. For a custom implementation of the Bean interface defined in The Bean
interface, the container calls getBeanClass() to determine the bean class of
the bean and InjectionPoint.getMember() and then Member.getDeclaringClass() to
determine the class that declares an injection point.
CXF is saying the bean class - and as a result the proxy - is {{Bus}} but it
should be a concrete implementation.
Event 11.1 agrees
bq. getBeanClass() returns the bean class of the managed bean or session bean
or of the bean that declares the producer method or field.
> Wrong class specified for CdiBusBean
>
>
> Key: CXF-7175
> URL: https://issues.apache.org/jira/browse/CXF-7175
> Project: CXF
> Issue Type: Bug
> Components: Integration
>Reporter: John D. Ament
>
> https://github.com/apache/cxf/blob/3.1.x-fixes/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiBusBean.java#L43
> This specifies the wrong class. Since the Bean created is specifically a
> {{ExtensionManagerBus}} this should return {{ExtensionManagerBus.class}} not
> {{Bus.class}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7175) Wrong class specified for CdiBusBean
[
https://issues.apache.org/jira/browse/CXF-7175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15739882#comment-15739882
]
John D. Ament commented on CXF-7175:
Here's the stacktrace from test execution
{code}
Caused by: java.lang.AbstractMethodError:
org.apache.cxf.Bus$1366014918$Proxy$_$$_WeldClientProxy.getProperty(Ljava/lang/String;)Ljava/lang/Object;
at
org.apache.cxf.common.util.ClassHelper.getRealClass(ClassHelper.java:81)
at
org.apache.cxf.jaxrs.JAXRSServiceFactoryBean.setResourceClassesFromBeans(JAXRSServiceFactoryBean.java:223)
at
org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setServiceBeans(JAXRSServerFactoryBean.java:342)
at
org.apache.cxf.cdi.JAXRSCdiResourceExtension.createFactoryInstance(JAXRSCdiResourceExtension.java:186)
at
org.apache.cxf.cdi.JAXRSCdiResourceExtension.load(JAXRSCdiResourceExtension.java:136)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
... 109 more
at
org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:37)
at
org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28)
at
org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:458)
at
org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
at
org.jboss.arquillian.container.weld.embedded.mock.TestContainer.startContainer(TestContainer.java:240)
at
org.jboss.arquillian.container.weld.embedded.WeldMockContainer.deploy(WeldMockContainer.java:115)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
{code}
> Wrong class specified for CdiBusBean
>
>
> Key: CXF-7175
> URL: https://issues.apache.org/jira/browse/CXF-7175
> Project: CXF
> Issue Type: Bug
> Components: Integration
>Reporter: John D. Ament
>
> https://github.com/apache/cxf/blob/3.1.x-fixes/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiBusBean.java#L43
> This specifies the wrong class. Since the Bean created is specifically a
> {{ExtensionManagerBus}} this should return {{ExtensionManagerBus.class}} not
> {{Bus.class}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7346) CDI Extension ignores producer methods and fields
John D. Ament created CXF-7346: -- Summary: CDI Extension ignores producer methods and fields Key: CXF-7346 URL: https://issues.apache.org/jira/browse/CXF-7346 Project: CXF Issue Type: New Feature Reporter: John D. Ament If I have a producer method or field that has a Feature, Provider in it, that CDI bean is ignored during discovery. Instead, those producers should be considered just like any other CDI managed bean. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CXF-6461) Smarter deactivation of SpringAopClassHelper
John D. Ament created CXF-6461: -- Summary: Smarter deactivation of SpringAopClassHelper Key: CXF-6461 URL: https://issues.apache.org/jira/browse/CXF-6461 Project: CXF Issue Type: Improvement Components: Tooling Affects Versions: 3.0.5 Reporter: John D. Ament Improve how ClassHelper activates Spring or default implementation. https://github.com/apache/cxf/blob/3.0.x-fixes/core/src/main/java/org/apache/cxf/common/util/ClassHelper.java#L40 Instead of relying solely on the JVM flag, also check for spring on the classpath. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6461) Smarter deactivation of SpringAopClassHelper
[ https://issues.apache.org/jira/browse/CXF-6461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14585303#comment-14585303 ] John D. Ament commented on CXF-6461: Actually, I spent a lot of time trying to figure out why this wasn't working for me. Then it dawned on me to check spring versions. So, yes, what I put in the ticket is incorrect. Spring is properly checked on the classpath, however there are some compatibility issues. My app does package spring, but not by my own choice (it comes from one of our internal libraries that brings in all of spring, even though most of its not used). For deployment reasons, the whole thing ends up there. In CXF 2.7, you're depending on Spring 3.0.7 which happens to be what I'm pointing to. CXF 3 is using Spring 3.2, which is not compatible. The check on load is checking for classes, however there are method differences between the two. It looks like in my app currently, I am using Spring's AOP support. So, would it be worth extending the spring check to also check for method existence? > Smarter deactivation of SpringAopClassHelper > > > Key: CXF-6461 > URL: https://issues.apache.org/jira/browse/CXF-6461 > Project: CXF > Issue Type: Improvement > Components: Tooling >Affects Versions: 3.0.5 >Reporter: John D. Ament > > Improve how ClassHelper activates Spring or default implementation. > https://github.com/apache/cxf/blob/3.0.x-fixes/core/src/main/java/org/apache/cxf/common/util/ClassHelper.java#L40 > Instead of relying solely on the JVM flag, also check for spring on the > classpath. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7493) Cannot define a List or List as a query param
John D. Ament created CXF-7493:
--
Summary: Cannot define a List or List as a query
param
Key: CXF-7493
URL: https://issues.apache.org/jira/browse/CXF-7493
Project: CXF
Issue Type: Bug
Affects Versions: 3.1.12
Reporter: John D. Ament
When defining a resource method like:
{code}
public JsonObject verifyInjectedCustomIntegerArray(@QueryParam("value")
List array)
public JsonObject verifyInjectedCustomDoubleArray(@QueryParam("value")
List array)
{code}
The following stacktrace is shown when parsing the body:
{code}
java.lang.NullPointerException
at
org.apache.cxf.jaxrs.utils.InjectionUtils.injectIntoCollectionOrArray(InjectionUtils.java:904)
at
org.apache.cxf.jaxrs.utils.InjectionUtils.createParameterObject(InjectionUtils.java:1003)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.readQueryString(JAXRSUtils.java:1196)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.createHttpParameterValue(JAXRSUtils.java:872)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(JAXRSUtils.java:842)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(JAXRSUtils.java:793)
at
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:212)
at
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:263)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
at
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:189)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:223)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:274)
at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7493) Cannot define a List or List as a query param
[
https://issues.apache.org/jira/browse/CXF-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16155129#comment-16155129
]
John D. Ament commented on CXF-7493:
Its hard to tell, since your test looks like its operating at a much lower
level. It could also be that its happening client side not server side.
{code}
WebTarget echoEndpointTarget = ClientBuilder.newClient()
.target(uri)
.queryParam("value", 0, 1, 2, 3)
{code}
I'll try to get a sample project together.
> Cannot define a List or List as a query param
> ---
>
> Key: CXF-7493
> URL: https://issues.apache.org/jira/browse/CXF-7493
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.12
>Reporter: John D. Ament
>
> When defining a resource method like:
> {code}
> public JsonObject verifyInjectedCustomIntegerArray(@QueryParam("value")
> List array)
> public JsonObject verifyInjectedCustomDoubleArray(@QueryParam("value")
> List array)
> {code}
> The following stacktrace is shown when parsing the body:
> {code}
> java.lang.NullPointerException
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.injectIntoCollectionOrArray(InjectionUtils.java:904)
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.createParameterObject(InjectionUtils.java:1003)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readQueryString(JAXRSUtils.java:1196)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.createHttpParameterValue(JAXRSUtils.java:872)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(JAXRSUtils.java:842)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(JAXRSUtils.java:793)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:212)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:263)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:189)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:223)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:274)
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7493) Cannot define a List or List as a query param
[
https://issues.apache.org/jira/browse/CXF-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16155185#comment-16155185
]
John D. Ament commented on CXF-7493:
I just debugged my way through it. {{genericType}} in
{{injectIntoCollectionOrArray}} is {{List.class}} which is not a
{{ParamterizedType}}. As best as I can tell from this code path, you're never
actually getting a reference to the actual parameterized type. However, when I
run your test the {{genericType}} is correctly identified as
{{ParameterizedTypeImpl}} for {{List}}. When my test executes, in CXF
3.1.12 line 781 of {{JAXRSUtils}} the check goes into the {{if}} block, but in
your test it's going into the {{else}} block.
> Cannot define a List or List as a query param
> ---
>
> Key: CXF-7493
> URL: https://issues.apache.org/jira/browse/CXF-7493
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.12
>Reporter: John D. Ament
>
> When defining a resource method like:
> {code}
> public JsonObject verifyInjectedCustomIntegerArray(@QueryParam("value")
> List array)
> public JsonObject verifyInjectedCustomDoubleArray(@QueryParam("value")
> List array)
> {code}
> The following stacktrace is shown when parsing the body:
> {code}
> java.lang.NullPointerException
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.injectIntoCollectionOrArray(InjectionUtils.java:904)
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.createParameterObject(InjectionUtils.java:1003)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readQueryString(JAXRSUtils.java:1196)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.createHttpParameterValue(JAXRSUtils.java:872)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(JAXRSUtils.java:842)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(JAXRSUtils.java:793)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:212)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:263)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:189)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:223)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:274)
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7493) Cannot define a List or List as a query param
[
https://issues.apache.org/jira/browse/CXF-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16155237#comment-16155237
]
John D. Ament commented on CXF-7493:
I'm not sure if you mean that replicates it or that doesn't replicate it. I
can't even compile the systests on 3.1.x
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.6.2:testCompile
(default-testCompile) on project cxf-systests-jaxrs: Compilation failure:
Compilation failure:
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/SdoFactory.java:[21,26]
package commonj.sdo.helper does not exist
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/SdoFactory.java:[28,19]
cannot find symbol
[ERROR] symbol: class HelperContext
[ERROR] location: interface org.apache.cxf.systest.jaxrs.sdo.SdoFactory
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/impl/StructureImpl.java:[28,19]
package commonj.sdo does not exist
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/impl/StructureImpl.java:[31,8]
cannot access commonj.sdo.DataObject
[ERROR] class file for commonj.sdo.DataObject not found
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/impl/StructureImpl.java:[216,12]
cannot find symbol
[ERROR] symbol: class Type
[ERROR] location: class org.apache.cxf.systest.jaxrs.sdo.impl.StructureImpl
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/impl/SdoFactoryImpl.java:[30,19]
package commonj.sdo does not exist
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/impl/SdoFactoryImpl.java:[35,8]
cannot access org.eclipse.emf.ecore.impl.EPackageImpl
[ERROR] class file for org.eclipse.emf.ecore.impl.EPackageImpl not found
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/impl/SdoFactoryImpl.java:[41,15]
cannot find symbol
[ERROR] symbol: class Type
[ERROR] location: class org.apache.cxf.systest.jaxrs.sdo.impl.SdoFactoryImpl
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/impl/SdoFactoryImpl.java:[49,26]
cannot find symbol
[ERROR] symbol: class HelperContext
[ERROR] location: class org.apache.cxf.systest.jaxrs.sdo.impl.SdoFactoryImpl
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/impl/SdoFactoryImpl.java:[64,16]
cannot find symbol
[ERROR] symbol: class DataObject
[ERROR] location: class org.apache.cxf.systest.jaxrs.sdo.impl.SdoFactoryImpl
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/impl/SdoFactoryImpl.java:[77,16]
cannot find symbol
[ERROR] symbol: class Type
[ERROR] location: class org.apache.cxf.systest.jaxrs.sdo.impl.SdoFactoryImpl
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/SdoFactory.java:[25,84]
incompatible types: org.apache.cxf.systest.jaxrs.sdo.impl.SdoFactoryImpl
cannot be converted to org.apache.cxf.systest.jaxrs.sdo.SdoFactory
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/impl/StructureImpl.java:[208,16]
cannot find symbol
[ERROR] symbol: variable super
[ERROR] location: class org.apache.cxf.systest.jaxrs.sdo.impl.StructureImpl
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/impl/StructureImpl.java:[248,13]
cannot find symbol
[ERROR] symbol: method isNotifying()
[ERROR] location: class org.apache.cxf.systest.jaxrs.sdo.impl.StructureImpl
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/impl/StructureImpl.java:[249,20]
cannot find symbol
[ERROR] symbol: variable ChangeKind
[ERROR] location: class org.apache.cxf.systest.jaxrs.sdo.impl.StructureImpl
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/impl/StructureImpl.java:[263,13]
cannot find symbol
[ERROR] symbol: method isNotifying()
[ERROR] location: class org.apache.cxf.systest.jaxrs.sdo.impl.StructureImpl
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/impl/StructureImpl.java:[264,20]
cannot find symbol
[ERROR] symbol: variable ChangeKind
[ERROR] location: class org.apache.cxf.systest.jaxrs.sdo.impl.StructureImpl
[ERROR]
/Users/johnament/src/cxf/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/sdo/impl/StructureImpl.java:[296,13]
cannot find symbol
[ERROR] symbol: method isNotifying()
[ERROR] location: class org.apache.cxf.systest.jaxrs.sdo.impl.StructureImpl
[ERROR]
/Users/johnament/src/c
[jira] [Commented] (CXF-7493) Cannot define a List or List as a query param
[
https://issues.apache.org/jira/browse/CXF-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16155251#comment-16155251
]
John D. Ament commented on CXF-7493:
Ok, I'll see what's different between my class and this class. Its also
possible that this is already fixed on 3.1.13-SNAPSHOT
This seems to be part of the issue:
{code}
Downloading:
https://repository.apache.org/snapshots/org/apache/cxf/cxf-rt-databinding-sdo/3.1.13-SNAPSHOT/maven-metadata.xml
Downloaded:
https://repository.apache.org/snapshots/org/apache/cxf/cxf-rt-databinding-sdo/3.1.13-SNAPSHOT/maven-metadata.xml
(1.2 kB at 2.4 kB/s)
Downloading:
https://repository.apache.org/snapshots/org/apache/cxf/cxf-rt-databinding-sdo/3.1.13-SNAPSHOT/cxf-rt-databinding-sdo-3.1.13-20170906.115142-80.pom
Downloaded:
https://repository.apache.org/snapshots/org/apache/cxf/cxf-rt-databinding-sdo/3.1.13-SNAPSHOT/cxf-rt-databinding-sdo-3.1.13-20170906.115142-80.pom
(9.5 kB at 56 kB/s)
[WARNING] The POM for org.apache.tuscany.sdo:tuscany-sdo-impl:jar:1.1.1 is
invalid, transitive dependencies (if any) will not be available, enable debug
logging for more details
[WARNING] The POM for org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.1.1 is
invalid, transitive dependencies (if any) will not be available, enable debug
logging for more details
[WARNING] The POM for com.healthmarketscience.jackcess:jackcess:jar:2.1.4 is
invalid, transitive dependencies (if any) will not be available, enable debug
logging for more details
Downloading:
https://repository.apache.org/snapshots/org/apache/cxf/cxf-rt-databinding-sdo/3.1.13-SNAPSHOT/cxf-rt-databinding-sdo-3.1.13-20170906.115142-80.jar
Downloaded:
https://repository.apache.org/snapshots/org/apache/cxf/cxf-rt-databinding-sdo/3.1.13-SNAPSHOT/cxf-rt-databinding-sdo-3.1.13-20170906.115142-80.jar
(28 kB at 136 kB/s)
{code}
> Cannot define a List or List as a query param
> ---
>
> Key: CXF-7493
> URL: https://issues.apache.org/jira/browse/CXF-7493
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.12
>Reporter: John D. Ament
>
> When defining a resource method like:
> {code}
> public JsonObject verifyInjectedCustomIntegerArray(@QueryParam("value")
> List array)
> public JsonObject verifyInjectedCustomDoubleArray(@QueryParam("value")
> List array)
> {code}
> The following stacktrace is shown when parsing the body:
> {code}
> java.lang.NullPointerException
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.injectIntoCollectionOrArray(InjectionUtils.java:904)
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.createParameterObject(InjectionUtils.java:1003)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readQueryString(JAXRSUtils.java:1196)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.createHttpParameterValue(JAXRSUtils.java:872)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(JAXRSUtils.java:842)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(JAXRSUtils.java:793)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:212)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:263)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:189)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:223)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:274)
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7493) Cannot define a List or List as a query param
[
https://issues.apache.org/jira/browse/CXF-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16155274#comment-16155274
]
John D. Ament commented on CXF-7493:
Ok, I did some more digging.
The issue occurs when you have a CDI bean as your rest controller/rest resource
using Weld as your CDI implementation (problem does not replicate with
OpenWebBeans). In the {{OperationResourceInfo}} the
{{actualInGenericParamTypes}} field has {{List.class}} instead of the proper
{{ParameterizedType List}}.
So to replicate this, you'd need to add a test to the CDI test suite.
> Cannot define a List or List as a query param
> ---
>
> Key: CXF-7493
> URL: https://issues.apache.org/jira/browse/CXF-7493
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.12
>Reporter: John D. Ament
>
> When defining a resource method like:
> {code}
> public JsonObject verifyInjectedCustomIntegerArray(@QueryParam("value")
> List array)
> public JsonObject verifyInjectedCustomDoubleArray(@QueryParam("value")
> List array)
> {code}
> The following stacktrace is shown when parsing the body:
> {code}
> java.lang.NullPointerException
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.injectIntoCollectionOrArray(InjectionUtils.java:904)
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.createParameterObject(InjectionUtils.java:1003)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readQueryString(JAXRSUtils.java:1196)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.createHttpParameterValue(JAXRSUtils.java:872)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(JAXRSUtils.java:842)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(JAXRSUtils.java:793)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:212)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:263)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:189)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:223)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:274)
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7493) Cannot define a List or List as a query param
[
https://issues.apache.org/jira/browse/CXF-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16156304#comment-16156304
]
John D. Ament commented on CXF-7493:
Ok, well I figured out where the delta's coming from.
In Weld, when you do {{m.getAnnotations()}} it includes the {{@GET}} (and
other) annotation. In OWB, that annotation doesn't come back. Since it
doesn't come back in OWB, its falling back into the scan superclass logic,
which returns the non-proxied method.
I'm wondering if a check should be add for {{isSynthetic()}}, but not sure.
What Weld's doing here isn't wrong, just a bit surprising.
> Cannot define a List or List as a query param
> ---
>
> Key: CXF-7493
> URL: https://issues.apache.org/jira/browse/CXF-7493
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.12
>Reporter: John D. Ament
>
> When defining a resource method like:
> {code}
> public JsonObject verifyInjectedCustomIntegerArray(@QueryParam("value")
> List array)
> public JsonObject verifyInjectedCustomDoubleArray(@QueryParam("value")
> List array)
> {code}
> The following stacktrace is shown when parsing the body:
> {code}
> java.lang.NullPointerException
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.injectIntoCollectionOrArray(InjectionUtils.java:904)
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.createParameterObject(InjectionUtils.java:1003)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readQueryString(JAXRSUtils.java:1196)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.createHttpParameterValue(JAXRSUtils.java:872)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(JAXRSUtils.java:842)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(JAXRSUtils.java:793)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:212)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:263)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:189)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:223)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:274)
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CXF-7493) Cannot define a List or List as a query param
[
https://issues.apache.org/jira/browse/CXF-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16156304#comment-16156304
]
John D. Ament edited comment on CXF-7493 at 9/7/17 1:54 AM:
Ok, well I figured out where the delta's coming from. the issue starts from
{{ResourceUtils.evaluateResourceClass}}
In Weld, when you do {{m.getAnnotations()}} it includes the {{@GET}} (and
other) annotation. In OWB, that annotation doesn't come back. Since it
doesn't come back in OWB, its falling back into the scan superclass logic,
which returns the non-proxied method.
I'm wondering if a check should be add for {{isSynthetic()}}, but not sure.
What Weld's doing here isn't wrong, just a bit surprising.
was (Author: johndament):
Ok, well I figured out where the delta's coming from.
In Weld, when you do {{m.getAnnotations()}} it includes the {{@GET}} (and
other) annotation. In OWB, that annotation doesn't come back. Since it
doesn't come back in OWB, its falling back into the scan superclass logic,
which returns the non-proxied method.
I'm wondering if a check should be add for {{isSynthetic()}}, but not sure.
What Weld's doing here isn't wrong, just a bit surprising.
> Cannot define a List or List as a query param
> ---
>
> Key: CXF-7493
> URL: https://issues.apache.org/jira/browse/CXF-7493
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.12
>Reporter: John D. Ament
>
> When defining a resource method like:
> {code}
> public JsonObject verifyInjectedCustomIntegerArray(@QueryParam("value")
> List array)
> public JsonObject verifyInjectedCustomDoubleArray(@QueryParam("value")
> List array)
> {code}
> The following stacktrace is shown when parsing the body:
> {code}
> java.lang.NullPointerException
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.injectIntoCollectionOrArray(InjectionUtils.java:904)
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.createParameterObject(InjectionUtils.java:1003)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readQueryString(JAXRSUtils.java:1196)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.createHttpParameterValue(JAXRSUtils.java:872)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(JAXRSUtils.java:842)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(JAXRSUtils.java:793)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:212)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:263)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:189)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:223)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:274)
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7493) Cannot define a List or List as a query param
[
https://issues.apache.org/jira/browse/CXF-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16156781#comment-16156781
]
John D. Ament commented on CXF-7493:
I wouldn't necessarily have a superclass, my endpoint may just look like this:
{code}
@Path("/rest")
@RequestScoped
public class RestController {
@GET
public String doGet() {
return "Hello, World!";
}
@GET
@Path("/longs")
public String getLongs(@QueryParam("value") List longs) {
return longs.toString();
}
}
{code}
> Cannot define a List or List as a query param
> ---
>
> Key: CXF-7493
> URL: https://issues.apache.org/jira/browse/CXF-7493
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.12
>Reporter: John D. Ament
>
> When defining a resource method like:
> {code}
> public JsonObject verifyInjectedCustomIntegerArray(@QueryParam("value")
> List array)
> public JsonObject verifyInjectedCustomDoubleArray(@QueryParam("value")
> List array)
> {code}
> The following stacktrace is shown when parsing the body:
> {code}
> java.lang.NullPointerException
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.injectIntoCollectionOrArray(InjectionUtils.java:904)
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.createParameterObject(InjectionUtils.java:1003)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readQueryString(JAXRSUtils.java:1196)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.createHttpParameterValue(JAXRSUtils.java:872)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(JAXRSUtils.java:842)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(JAXRSUtils.java:793)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:212)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:263)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:189)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:223)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:274)
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7493) Cannot define a List or List as a query param
[
https://issues.apache.org/jira/browse/CXF-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament updated CXF-7493:
---
Fix Version/s: 3.2.1
> Cannot define a List or List as a query param
> ---
>
> Key: CXF-7493
> URL: https://issues.apache.org/jira/browse/CXF-7493
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.12
>Reporter: John D. Ament
> Fix For: 3.2.1
>
>
> When defining a resource method like:
> {code}
> public JsonObject verifyInjectedCustomIntegerArray(@QueryParam("value")
> List array)
> public JsonObject verifyInjectedCustomDoubleArray(@QueryParam("value")
> List array)
> {code}
> The following stacktrace is shown when parsing the body:
> {code}
> java.lang.NullPointerException
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.injectIntoCollectionOrArray(InjectionUtils.java:904)
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.createParameterObject(InjectionUtils.java:1003)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readQueryString(JAXRSUtils.java:1196)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.createHttpParameterValue(JAXRSUtils.java:872)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(JAXRSUtils.java:842)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(JAXRSUtils.java:793)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:212)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:263)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:189)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:223)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:274)
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CXF-7510) SSE integration abruptly fails with no indication why
John D. Ament created CXF-7510:
--
Summary: SSE integration abruptly fails with no indication why
Key: CXF-7510
URL: https://issues.apache.org/jira/browse/CXF-7510
Project: CXF
Issue Type: Bug
Reporter: John D. Ament
https://lists.apache.org/thread.html/10d99c0d013a3d23361a3898171e7bd2b311a509349433db3b6cacaa@%3Cusers.cxf.apache.org%3E
has more details
Intermittently, when bootstrapping CXF + CDI, the integration for SSE will
fail. When it fails, there's no log messages indicating the issue, however
attempts to invoke any rest endpoint will give a warning like:
{code}
Sep 17, 2017 7:50:33 PM org.apache.cxf.transport.servlet.ServletController
invoke
WARNING: Can't find the request for http://my-hostname:4403/rest's Observer
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7493) Cannot define a List or List as a query param
[
https://issues.apache.org/jira/browse/CXF-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188108#comment-16188108
]
John D. Ament commented on CXF-7493:
I have no preference to include in 3.1.x, but it would be trivial to cherry
pick it.
> Cannot define a List or List as a query param
> ---
>
> Key: CXF-7493
> URL: https://issues.apache.org/jira/browse/CXF-7493
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.12
>Reporter: John D. Ament
> Fix For: 3.2.1
>
>
> When defining a resource method like:
> {code}
> public JsonObject verifyInjectedCustomIntegerArray(@QueryParam("value")
> List array)
> public JsonObject verifyInjectedCustomDoubleArray(@QueryParam("value")
> List array)
> {code}
> The following stacktrace is shown when parsing the body:
> {code}
> java.lang.NullPointerException
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.injectIntoCollectionOrArray(InjectionUtils.java:904)
> at
> org.apache.cxf.jaxrs.utils.InjectionUtils.createParameterObject(InjectionUtils.java:1003)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readQueryString(JAXRSUtils.java:1196)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.createHttpParameterValue(JAXRSUtils.java:872)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(JAXRSUtils.java:842)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(JAXRSUtils.java:793)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:212)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:263)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:189)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:223)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:274)
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7510) SSE integration abruptly fails with no indication why
[
https://issues.apache.org/jira/browse/CXF-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16191123#comment-16191123
]
John D. Ament commented on CXF-7510:
I'll see if I can put something together. It is easiest to replicate in a unit
test. If I point you to an existing github repo would that work for you?
> SSE integration abruptly fails with no indication why
> -
>
> Key: CXF-7510
> URL: https://issues.apache.org/jira/browse/CXF-7510
> Project: CXF
> Issue Type: Bug
>Reporter: John D. Ament
>
> https://lists.apache.org/thread.html/10d99c0d013a3d23361a3898171e7bd2b311a509349433db3b6cacaa@%3Cusers.cxf.apache.org%3E
> has more details
> Intermittently, when bootstrapping CXF + CDI, the integration for SSE will
> fail. When it fails, there's no log messages indicating the issue, however
> attempts to invoke any rest endpoint will give a warning like:
> {code}
> Sep 17, 2017 7:50:33 PM org.apache.cxf.transport.servlet.ServletController
> invoke
> WARNING: Can't find the request for http://my-hostname:4403/rest's Observer
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7510) SSE integration in CDI abruptly fails with no indication why
[
https://issues.apache.org/jira/browse/CXF-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16196366#comment-16196366
]
John D. Ament commented on CXF-7510:
[~reta]
Sorry, my fault. I had on my TODO to get a link over and forgot :-( Here's a
test that can reproduce the intermitent issue (though its more of a case where
90% it fails).
https://github.com/hammock-project/hammock/blob/sse-issue/rest-cxf/src/test/java/org/hammock/test/cxf/CXFSseTest.java
When it works, you'll see the atmosphere install occurring, when it fails it
just does nothing.
> SSE integration in CDI abruptly fails with no indication why
>
>
> Key: CXF-7510
> URL: https://issues.apache.org/jira/browse/CXF-7510
> Project: CXF
> Issue Type: Bug
>Reporter: John D. Ament
>Assignee: Andriy Redko
>
> https://lists.apache.org/thread.html/10d99c0d013a3d23361a3898171e7bd2b311a509349433db3b6cacaa@%3Cusers.cxf.apache.org%3E
> has more details
> Intermittently, when bootstrapping CXF + CDI, the integration for SSE will
> fail. When it fails, there's no log messages indicating the issue, however
> attempts to invoke any rest endpoint will give a warning like:
> {code}
> Sep 17, 2017 7:50:33 PM org.apache.cxf.transport.servlet.ServletController
> invoke
> WARNING: Can't find the request for http://my-hostname:4403/rest's Observer
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7510) SSE integration in CDI abruptly fails with no indication why
[
https://issues.apache.org/jira/browse/CXF-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16196369#comment-16196369
]
John D. Ament commented on CXF-7510:
[~reta] RE the discovery of SseFeature, I was trying to figure out why it
wasn't working. I noticed that the {{beans.xml}} file in the archive is
missing a {{bean-discovery-mode}}, per the docs its required if you're using
{{version=1.1}}
bq. The version of CDI this beans.xml is for. If the version is "1.1" (or
later), then the attribute bean-discovery-mode must be added.
> SSE integration in CDI abruptly fails with no indication why
>
>
> Key: CXF-7510
> URL: https://issues.apache.org/jira/browse/CXF-7510
> Project: CXF
> Issue Type: Bug
>Reporter: John D. Ament
>Assignee: Andriy Redko
>
> https://lists.apache.org/thread.html/10d99c0d013a3d23361a3898171e7bd2b311a509349433db3b6cacaa@%3Cusers.cxf.apache.org%3E
> has more details
> Intermittently, when bootstrapping CXF + CDI, the integration for SSE will
> fail. When it fails, there's no log messages indicating the issue, however
> attempts to invoke any rest endpoint will give a warning like:
> {code}
> Sep 17, 2017 7:50:33 PM org.apache.cxf.transport.servlet.ServletController
> invoke
> WARNING: Can't find the request for http://my-hostname:4403/rest's Observer
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7510) SSE integration in CDI abruptly fails with no indication why
[
https://issues.apache.org/jira/browse/CXF-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16196394#comment-16196394
]
John D. Ament commented on CXF-7510:
Ah ok, I see. That actually explains why I sometimes see it in SE as well.
See my prior note about {{bean-discovery-mode}}. Note that this isn't an issue
{{cxf-integration-cdi}} since it has a CDI extension in it, that always enables
CDI scanning in that JAR.
I would actually recommend using {{annotated}} discovery and adding bean
defining annotations to the relevant classes. Thoughts?
> SSE integration in CDI abruptly fails with no indication why
>
>
> Key: CXF-7510
> URL: https://issues.apache.org/jira/browse/CXF-7510
> Project: CXF
> Issue Type: Bug
>Reporter: John D. Ament
>Assignee: Andriy Redko
>
> https://lists.apache.org/thread.html/10d99c0d013a3d23361a3898171e7bd2b311a509349433db3b6cacaa@%3Cusers.cxf.apache.org%3E
> has more details
> Intermittently, when bootstrapping CXF + CDI, the integration for SSE will
> fail. When it fails, there's no log messages indicating the issue, however
> attempts to invoke any rest endpoint will give a warning like:
> {code}
> Sep 17, 2017 7:50:33 PM org.apache.cxf.transport.servlet.ServletController
> invoke
> WARNING: Can't find the request for http://my-hostname:4403/rest's Observer
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7510) SSE integration in CDI abruptly fails with no indication why
[
https://issues.apache.org/jira/browse/CXF-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16196402#comment-16196402
]
John D. Ament commented on CXF-7510:
I was thinking a little more comprehensive patch:
{code}
diff --git a/rt/rs/sse/src/main/java/org/apache/cxf/jaxrs/sse/SseFeature.java
b/rt/rs/sse/src/main/java/org/apache/cxf/jaxrs/sse/SseFeature.java
index 36ea9ed..9193426 100644
--- a/rt/rs/sse/src/main/java/org/apache/cxf/jaxrs/sse/SseFeature.java
+++ b/rt/rs/sse/src/main/java/org/apache/cxf/jaxrs/sse/SseFeature.java
@@ -30,7 +30,10 @@ import org.apache.cxf.feature.AbstractFeature;
import org.apache.cxf.jaxrs.provider.ServerProviderFactory;
import
org.apache.cxf.jaxrs.sse.atmosphere.SseAtmosphereEventSinkContextProvider;
+import javax.enterprise.context.Dependent;
+
@Provider(value = Type.Feature, scope = Scope.Server)
+@Dependent
public class SseFeature extends AbstractFeature {
@Override
public void initialize(Server server, Bus bus) {
diff --git
a/rt/rs/sse/src/main/java/org/apache/cxf/jaxrs/sse/cdi/SseTransportCustomizationExtension.java
b/rt/rs/sse/src/main/java/org/apache/cxf/jaxrs/sse/cdi/SseTransportCustomizationExtension.java
index 68af13c..66cb166 100644
---
a/rt/rs/sse/src/main/java/org/apache/cxf/jaxrs/sse/cdi/SseTransportCustomizationExtension.java
+++
b/rt/rs/sse/src/main/java/org/apache/cxf/jaxrs/sse/cdi/SseTransportCustomizationExtension.java
@@ -22,6 +22,9 @@ import
org.apache.cxf.cdi.extension.JAXRSServerFactoryCustomizationExtension;
import org.apache.cxf.jaxrs.JAXRSServerFactoryBean;
import org.apache.cxf.transport.sse.SseHttpTransportFactory;
+import javax.enterprise.context.Dependent;
+
+@Dependent
public class SseTransportCustomizationExtension implements
JAXRSServerFactoryCustomizationExtension {
@Override
public void customize(final JAXRSServerFactoryBean bean) {
diff --git a/rt/rs/sse/src/main/resources/META-INF/beans.xml
b/rt/rs/sse/src/main/resources/META-INF/beans.xml
index 8d1007d..6b50728 100644
--- a/rt/rs/sse/src/main/resources/META-INF/beans.xml
+++ b/rt/rs/sse/src/main/resources/META-INF/beans.xml
@@ -1,5 +1,6 @@
http://java.sun.com/xml/ns/javaee";
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
- xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd";>
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
+ xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd";
+bean-discovery-mode="annotated">
{code}
Also RE the transport customization, I'm not sure that fixes it consistently.
I do add this servlet param, which I was told on list sets it as well
{code}
if(enableSseTransport) {
params.add(new WebParam(CXFNonSpringJaxrsServlet.TRANSPORT_ID,
SseHttpTransportFactory.TRANSPORT_ID));
}
{code}
> SSE integration in CDI abruptly fails with no indication why
>
>
> Key: CXF-7510
> URL: https://issues.apache.org/jira/browse/CXF-7510
> Project: CXF
> Issue Type: Bug
>Reporter: John D. Ament
>Assignee: Andriy Redko
>
> https://lists.apache.org/thread.html/10d99c0d013a3d23361a3898171e7bd2b311a509349433db3b6cacaa@%3Cusers.cxf.apache.org%3E
> has more details
> Intermittently, when bootstrapping CXF + CDI, the integration for SSE will
> fail. When it fails, there's no log messages indicating the issue, however
> attempts to invoke any rest endpoint will give a warning like:
> {code}
> Sep 17, 2017 7:50:33 PM org.apache.cxf.transport.servlet.ServletController
> invoke
> WARNING: Can't find the request for http://my-hostname:4403/rest's Observer
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7510) SSE integration in CDI abruptly fails with no indication why
[
https://issues.apache.org/jira/browse/CXF-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16200326#comment-16200326
]
John D. Ament commented on CXF-7510:
Technically the discovery in this way will only work in some deployment
scenarios (e.g. WARs). I'm using Java SE/CDI SE, so the present beans.xml
would never be valid.
> SSE integration in CDI abruptly fails with no indication why
>
>
> Key: CXF-7510
> URL: https://issues.apache.org/jira/browse/CXF-7510
> Project: CXF
> Issue Type: Bug
>Reporter: John D. Ament
>Assignee: Andriy Redko
>
> https://lists.apache.org/thread.html/10d99c0d013a3d23361a3898171e7bd2b311a509349433db3b6cacaa@%3Cusers.cxf.apache.org%3E
> has more details
> Intermittently, when bootstrapping CXF + CDI, the integration for SSE will
> fail. When it fails, there's no log messages indicating the issue, however
> attempts to invoke any rest endpoint will give a warning like:
> {code}
> Sep 17, 2017 7:50:33 PM org.apache.cxf.transport.servlet.ServletController
> invoke
> WARNING: Can't find the request for http://my-hostname:4403/rest's Observer
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7510) SSE integration in CDI abruptly fails with no indication why
[
https://issues.apache.org/jira/browse/CXF-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16200337#comment-16200337
]
John D. Ament commented on CXF-7510:
Ah, nevermind. I see you already pushed up the change to add
{{bean-discovery-mode}}
> SSE integration in CDI abruptly fails with no indication why
>
>
> Key: CXF-7510
> URL: https://issues.apache.org/jira/browse/CXF-7510
> Project: CXF
> Issue Type: Bug
>Reporter: John D. Ament
>Assignee: Andriy Redko
>
> https://lists.apache.org/thread.html/10d99c0d013a3d23361a3898171e7bd2b311a509349433db3b6cacaa@%3Cusers.cxf.apache.org%3E
> has more details
> Intermittently, when bootstrapping CXF + CDI, the integration for SSE will
> fail. When it fails, there's no log messages indicating the issue, however
> attempts to invoke any rest endpoint will give a warning like:
> {code}
> Sep 17, 2017 7:50:33 PM org.apache.cxf.transport.servlet.ServletController
> invoke
> WARNING: Can't find the request for http://my-hostname:4403/rest's Observer
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7510) SSE integration in CDI abruptly fails with no indication why
[
https://issues.apache.org/jira/browse/CXF-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206874#comment-16206874
]
John D. Ament commented on CXF-7510:
I made the changes noted here (mostly just adding
{{SseTransportCustomizationExtension}} as a bean to the JAR. Unfortunately I
still see the atmosphere bootstrap issue.
> SSE integration in CDI abruptly fails with no indication why
>
>
> Key: CXF-7510
> URL: https://issues.apache.org/jira/browse/CXF-7510
> Project: CXF
> Issue Type: Bug
>Reporter: John D. Ament
>Assignee: Andriy Redko
>
> https://lists.apache.org/thread.html/10d99c0d013a3d23361a3898171e7bd2b311a509349433db3b6cacaa@%3Cusers.cxf.apache.org%3E
> has more details
> Intermittently, when bootstrapping CXF + CDI, the integration for SSE will
> fail. When it fails, there's no log messages indicating the issue, however
> attempts to invoke any rest endpoint will give a warning like:
> {code}
> Sep 17, 2017 7:50:33 PM org.apache.cxf.transport.servlet.ServletController
> invoke
> WARNING: Can't find the request for http://my-hostname:4403/rest's Observer
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7510) SSE integration in CDI abruptly fails with no indication why
[
https://issues.apache.org/jira/browse/CXF-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206883#comment-16206883
]
John D. Ament commented on CXF-7510:
I figured it out, was something stupid on my part. I ended up getting it
working with 3.2.0 by running with the extension being registered.
One other note, in
https://github.com/apache/cxf/blob/master/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java#L361-L364
there's a bug. You're using `getBeanClass()` which isn't the class if you're
using a producer method/field. You're better off using the value
`JAXRSServerFactoryCustomizationExtension.class` instead.
If you want I can raise a PR for that.
> SSE integration in CDI abruptly fails with no indication why
>
>
> Key: CXF-7510
> URL: https://issues.apache.org/jira/browse/CXF-7510
> Project: CXF
> Issue Type: Bug
>Reporter: John D. Ament
>Assignee: Andriy Redko
>
> https://lists.apache.org/thread.html/10d99c0d013a3d23361a3898171e7bd2b311a509349433db3b6cacaa@%3Cusers.cxf.apache.org%3E
> has more details
> Intermittently, when bootstrapping CXF + CDI, the integration for SSE will
> fail. When it fails, there's no log messages indicating the issue, however
> attempts to invoke any rest endpoint will give a warning like:
> {code}
> Sep 17, 2017 7:50:33 PM org.apache.cxf.transport.servlet.ServletController
> invoke
> WARNING: Can't find the request for http://my-hostname:4403/rest's Observer
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7510) SSE integration in CDI abruptly fails with no indication why
[
https://issues.apache.org/jira/browse/CXF-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16208642#comment-16208642
]
John D. Ament commented on CXF-7510:
Sounds good to me. Looks good, hopefully 3.2.1 comes soon :)
> SSE integration in CDI abruptly fails with no indication why
>
>
> Key: CXF-7510
> URL: https://issues.apache.org/jira/browse/CXF-7510
> Project: CXF
> Issue Type: Bug
>Reporter: John D. Ament
>Assignee: Andriy Redko
>
> https://lists.apache.org/thread.html/10d99c0d013a3d23361a3898171e7bd2b311a509349433db3b6cacaa@%3Cusers.cxf.apache.org%3E
> has more details
> Intermittently, when bootstrapping CXF + CDI, the integration for SSE will
> fail. When it fails, there's no log messages indicating the issue, however
> attempts to invoke any rest endpoint will give a warning like:
> {code}
> Sep 17, 2017 7:50:33 PM org.apache.cxf.transport.servlet.ServletController
> invoke
> WARNING: Can't find the request for http://my-hostname:4403/rest's Observer
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CXF-7535) Support for Project Reactor as rx()
John D. Ament created CXF-7535: -- Summary: Support for Project Reactor as rx() Key: CXF-7535 URL: https://issues.apache.org/jira/browse/CXF-7535 Project: CXF Issue Type: New Feature Components: JAX-RS Affects Versions: 3.2.0 Reporter: John D. Ament It would be good if Project Reactor was supported as an rx() type in CXF. https://github.com/apache/cxf/tree/master/rt/rs/extensions/rx - only shows rx java and rx java 2. project reactor/reactor core seem like the v3's of this api stack. https://projectreactor.io/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7535) Support for Project Reactor as rx()
[ https://issues.apache.org/jira/browse/CXF-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16213912#comment-16213912 ] John D. Ament commented on CXF-7535: Agreed, I've even done some prototype work on using Reactor w/ CDI for events. It works pretty nicely. I plan to get a patch together for this, where would be a good place for tests, systests? > Support for Project Reactor as rx() > --- > > Key: CXF-7535 > URL: https://issues.apache.org/jira/browse/CXF-7535 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.2.0 >Reporter: John D. Ament > > It would be good if Project Reactor was supported as an rx() type in CXF. > https://github.com/apache/cxf/tree/master/rt/rs/extensions/rx - only shows rx > java and rx java 2. project reactor/reactor core seem like the v3's of this > api stack. > https://projectreactor.io/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7517) Codegen fails when using JDK9 with maven and cxf-plugin
[
https://issues.apache.org/jira/browse/CXF-7517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16214177#comment-16214177
]
John D. Ament commented on CXF-7517:
It may be easier to just declare the dependencies needed, it avoids having to
rely on the system behavior. I created a simple project w/ CXF + CDI, had it
fail with java 9, added these dependencies and it works:
{code}
javax.annotation
javax.annotation-api
1.3.1
javax.xml.ws
jaxws-api
2.3.0
javax.activation
activation
1.1.1
{code}
Maybe it will work for you? Maybe we want to add these to cxf-core as
dependencies? (activation may not be needed, it may be from CDI)
> Codegen fails when using JDK9 with maven and cxf-plugin
> ---
>
> Key: CXF-7517
> URL: https://issues.apache.org/jira/browse/CXF-7517
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 3.1.12
>Reporter: David J. M. Karlsen
>Assignee: Freeman Fang
> Labels: jdk9
>
> I get this stack trace when trying to generate code with the
> cxf-codegen-plugin:
> {noformat}
> [INFO] --- cxf-codegen-plugin:3.1.12:wsdl2java (default) @ jfr-srv-schemas ---
> [INFO] Using proxy server configured in maven.
> [INFO] Running code generation in fork mode...
> [INFO] The java executable is
> /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/java
> [INFO] Building jar:
> /var/folders/c7/18m1hlzs075_z0f5nfnt44jmgn/T/cxf-tmp-3400635706757982781/cxf-codegen16491176446297681426.jar
> [WARNING] WARNING: An illegal reflective access operation has occurred
> [WARNING] WARNING: Illegal reflective access by
> com.sun.xml.bind.v2.runtime.reflect.opt.Injector
> (file:/Users/et2448/.m2/repository/com/sun/xml/bind/jaxb-impl/2.2.11/jaxb-impl-2.2.11.jar)
> to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
> [WARNING] WARNING: Please consider reporting this to the maintainers of
> com.sun.xml.bind.v2.runtime.reflect.opt.Injector
> [WARNING] WARNING: Use --illegal-access=warn to enable warnings of further
> illegal reflective access operations
> [WARNING] WARNING: All illegal access operations will be denied in a future
> release
> [WARNING] Exception in thread "main" java.lang.NoClassDefFoundError:
> javax/xml/ws/Service
> [WARNING] at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.JAXWSContainer.isJaxws22(JAXWSContainer.java:64)
> [WARNING] at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.JAXWSContainer.getServiceTarget(JAXWSContainer.java:61)
> [WARNING] at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.JAXWSContainer.validate(JAXWSContainer.java:68)
> [WARNING] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:175)
> [WARNING] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164)
> [WARNING] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:415)
> [WARNING] at
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> [WARNING] at
> org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
> [WARNING] at
> org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
> [WARNING] at
> org.apache.cxf.maven_plugin.wsdl2java.ForkOnceWSDL2Java.main(ForkOnceWSDL2Java.java:51)
> [WARNING] Caused by: java.lang.ClassNotFoundException: javax.xml.ws.Service
> [WARNING] at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
> [WARNING] at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185)
> [WARNING] at
> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
> [WARNING] ... 10 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CXF-7543) JAX-RS Features not used in proxies or WebClients
John D. Ament created CXF-7543:
--
Summary: JAX-RS Features not used in proxies or WebClients
Key: CXF-7543
URL: https://issues.apache.org/jira/browse/CXF-7543
Project: CXF
Issue Type: Bug
Affects Versions: 3.2.0
Reporter: John D. Ament
Suppose that you are using JAXRSClientFactoryBean to create a new client. You
may call some code like this:
{code}
JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
bean.setAddress(baseUri);
bean.setServiceClass(aClass);
bean.setProviders(asList(new SomeFeature()));
bean.setProperties(properties);
return bean.create(aClass);
{code}
If your {{SomeFeature}} registers additional providers, then those providers
are never considered for use on the proxy or WebClient instance created.
--
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=16224128#comment-16224128
]
John D. Ament commented on CXF-7544:
Does it happen even with the CDIClassUnwrapper in use?
> 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] [Assigned] (CXF-7535) Support for Project Reactor as rx()
[ https://issues.apache.org/jira/browse/CXF-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament reassigned CXF-7535: -- Assignee: John D. Ament > Support for Project Reactor as rx() > --- > > Key: CXF-7535 > URL: https://issues.apache.org/jira/browse/CXF-7535 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.2.0 >Reporter: John D. Ament >Assignee: John D. Ament > > It would be good if Project Reactor was supported as an rx() type in CXF. > https://github.com/apache/cxf/tree/master/rt/rs/extensions/rx - only shows rx > java and rx java 2. project reactor/reactor core seem like the v3's of this > api stack. > https://projectreactor.io/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CXF-7535) Support for Project Reactor as rx()
[ https://issues.apache.org/jira/browse/CXF-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament updated CXF-7535: --- Fix Version/s: 3.2.2 > Support for Project Reactor as rx() > --- > > Key: CXF-7535 > URL: https://issues.apache.org/jira/browse/CXF-7535 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.2.0 >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 3.2.2 > > > It would be good if Project Reactor was supported as an rx() type in CXF. > https://github.com/apache/cxf/tree/master/rt/rs/extensions/rx - only shows rx > java and rx java 2. project reactor/reactor core seem like the v3's of this > api stack. > https://projectreactor.io/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7535) Support for Project Reactor as rx()
[ https://issues.apache.org/jira/browse/CXF-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245606#comment-16245606 ] John D. Ament commented on CXF-7535: Hi Sergey, I don't believe we can actually de-dupe them. AbstractSubscriber uses the reactor specific subscriber object, whereas AbstractAsyncSubscriber is designed for the RxJava class. So while the implementations of both are very similar, they each rely on the implementation specific subscription. DeafultSubscriber is from RxJava 2, and has no direct equivalent in Reactor. As for why there are subtle differences. In Project Reactor, you have a mono which is always 0/1. It doesn't make sense to send this over the wire as an array type. Likewise, a consumer should only ever try to read this as a single entry. Hence I had to make a small modification to support no prefix/suffix/separator. > Support for Project Reactor as rx() > --- > > Key: CXF-7535 > URL: https://issues.apache.org/jira/browse/CXF-7535 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.2.0 >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 3.2.2 > > > It would be good if Project Reactor was supported as an rx() type in CXF. > https://github.com/apache/cxf/tree/master/rt/rs/extensions/rx - only shows rx > java and rx java 2. project reactor/reactor core seem like the v3's of this > api stack. > https://projectreactor.io/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7535) Support for Project Reactor as rx()
[ https://issues.apache.org/jira/browse/CXF-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245740#comment-16245740 ] John D. Ament commented on CXF-7535: There's some definite refactoring that can happen. Its probably not here though, probably a composition pattern to fix it. > Support for Project Reactor as rx() > --- > > Key: CXF-7535 > URL: https://issues.apache.org/jira/browse/CXF-7535 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.2.0 >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 3.2.2 > > > It would be good if Project Reactor was supported as an rx() type in CXF. > https://github.com/apache/cxf/tree/master/rt/rs/extensions/rx - only shows rx > java and rx java 2. project reactor/reactor core seem like the v3's of this > api stack. > https://projectreactor.io/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7535) Support for Project Reactor as rx()
[ https://issues.apache.org/jira/browse/CXF-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16247759#comment-16247759 ] John D. Ament commented on CXF-7535: Cool, so you have it consolidated? > Support for Project Reactor as rx() > --- > > Key: CXF-7535 > URL: https://issues.apache.org/jira/browse/CXF-7535 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.2.0 >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 3.2.2 > > > It would be good if Project Reactor was supported as an rx() type in CXF. > https://github.com/apache/cxf/tree/master/rt/rs/extensions/rx - only shows rx > java and rx java 2. project reactor/reactor core seem like the v3's of this > api stack. > https://projectreactor.io/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[ https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266006#comment-16266006 ] John D. Ament commented on CXF-7571: Looking at the issue, is it as simple as: - Moving init into the ResourceProvider interface - Maybe even making it default, to call InjectionUtils on the instance Or even more simply In CdiResourceProvider.getInstance add a call to InjectionUtils ? > Revamp of the CXF injection implementation > --- > > Key: CXF-7571 > URL: https://issues.apache.org/jira/browse/CXF-7571 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko > > As more deep integration with CDI revealed, there are complexities in > bringing together `@Context`- and `@Inject`-based injections. Encapsulating > CXF injection implementation and than delegating the hard work to appropriate > strategy (CDI, Spring, ...) would be the right solution to address the > problem at its roots. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266816#comment-16266816
]
John D. Ament commented on CXF-7571:
yeah, but you have to weigh what the spec is asking for vs what may make sense
to do in a future JAX-RS impl. Its pretty simple IMHO to loop through the
annotated fields and add {{@Inject}} to each {{@Context}} field.
Personally, I think having support for {{@Inject}} for the built in
{{@Context}} objects makes sense. But to solve that, I think it makes the most
sense to just register them as beans and then satisfy what I just described.
You get the added benefit that any CDI bean could inject a {{UriInfo}} for
instance.
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together `@Context`- and `@Inject`-based injections. Encapsulating
> CXF injection implementation and than delegating the hard work to appropriate
> strategy (CDI, Spring, ...) would be the right solution to address the
> problem at its roots.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266850#comment-16266850
]
John D. Ament commented on CXF-7571:
Sergey, no, that's not what I am suggesting.
In the CDI extension, find any managed bean that declares a {{@Context}}, and
update the underlying {{Annotated}} object to add {{@Inject}} to the
annotations. CDI exposes {{AnnotatedField}}, {{AnnotatedMethod}},
{{AnnotatedParameter}} for these use cases. For instance, if a method param is
annotated {{@Context}} you'll need to add {{@Inject}} to the method. What will
be curious is how to handle {{@Context}} in a service method. I did something
like that recently for a custom event model I was implementing. This would
allow CDI to take over the injection of the field, since it'll have the JSR-330
annotation.
I think Andriy has my point. It makes it so that CXF doesn't have to do
anything (other than register additional beans).
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together `@Context`- and `@Inject`-based injections. Encapsulating
> CXF injection implementation and than delegating the hard work to appropriate
> strategy (CDI, Spring, ...) would be the right solution to address the
> problem at its roots.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275336#comment-16275336
]
John D. Ament commented on CXF-7571:
[~reta] this is assigned to you, but if you need help I'm happy to start on the
work.
I ran into a similar issue,
https://lists.apache.org/thread.html/40c3438b7299d53063b5ae98f6a6d674ea8b1c954f9af160033c05f8@%3Cdev.cxf.apache.org%3E
, where {{@Context}} doesn't work for sub-resources. I started to add
support, but it doesn't make sense if we're going to make the contexts all CDI
aware.
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together `@Context`- and `@Inject`-based injections. Encapsulating
> CXF injection implementation and than delegating the hard work to appropriate
> strategy (CDI, Spring, ...) would be the right solution to address the
> problem at its roots.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[ https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275580#comment-16275580 ] John D. Ament commented on CXF-7571: Ok, I have it mostly implemented. I won't be back by a computer until tonight to push it. The hardest part was figuring out where the context objects are instantiated > Revamp of the CXF injection implementation > --- > > Key: CXF-7571 > URL: https://issues.apache.org/jira/browse/CXF-7571 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko > > As more deep integration with CDI revealed, there are complexities in > bringing together `@Context`- and `@Inject`-based injections. Encapsulating > CXF injection implementation and than delegating the hard work to appropriate > strategy (CDI, Spring, ...) would be the right solution to address the > problem at its roots. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (CXF-7571) Revamp of the CXF injection implementation
[ https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament reassigned CXF-7571: -- Assignee: John D. Ament (was: Andriy Redko) > Revamp of the CXF injection implementation > --- > > Key: CXF-7571 > URL: https://issues.apache.org/jira/browse/CXF-7571 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: John D. Ament > > As more deep integration with CDI revealed, there are complexities in > bringing together `@Context`- and `@Inject`-based injections. Encapsulating > CXF injection implementation and than delegating the hard work to appropriate > strategy (CDI, Spring, ...) would be the right solution to address the > problem at its roots. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament updated CXF-7571:
---
Description: As more deep integration with CDI revealed, there are
complexities in bringing together {{@Context}}- and {{@Inject}}-based
injections. Encapsulating CXF injection implementation and than delegating the
hard work to appropriate strategy (CDI, Spring, ...) would be the right
solution to address the problem at its roots. (was: As more deep integration
with CDI revealed, there are complexities in bringing together `@Context`- and
`@Inject`-based injections. Encapsulating CXF injection implementation and than
delegating the hard work to appropriate strategy (CDI, Spring, ...) would be
the right solution to address the problem at its roots.)
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: John D. Ament
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together {{@Context}}- and {{@Inject}}-based injections.
> Encapsulating CXF injection implementation and than delegating the hard work
> to appropriate strategy (CDI, Spring, ...) would be the right solution to
> address the problem at its roots.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275946#comment-16275946
]
John D. Ament commented on CXF-7571:
If it makes sense, we can create separate tickets for CDI/Spring injection.
But IMHO it won't be done until we stop processing {{@Context}} injection for
those runtimes. To do that, we'll need handle methods as well (which this
doesn't do).
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: John D. Ament
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together {{@Context}}- and {{@Inject}}-based injections.
> Encapsulating CXF injection implementation and than delegating the hard work
> to appropriate strategy (CDI, Spring, ...) would be the right solution to
> address the problem at its roots.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CXF-7579) Implement MicroProfile Rest Client 1.0
John D. Ament created CXF-7579: -- Summary: Implement MicroProfile Rest Client 1.0 Key: CXF-7579 URL: https://issues.apache.org/jira/browse/CXF-7579 Project: CXF Issue Type: New Feature Reporter: John D. Ament Assignee: John D. Ament Implement MP Rest Client 1.0 (Draft spec at download.eclipse.org/microprofile/microprofile-rest-client-1.0-T9/microprofile-rest-client.pdf ) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CXF-7579) Implement MicroProfile Rest Client 1.0
[ https://issues.apache.org/jira/browse/CXF-7579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament resolved CXF-7579. Resolution: Fixed Fix Version/s: 3.2.2 > Implement MicroProfile Rest Client 1.0 > -- > > Key: CXF-7579 > URL: https://issues.apache.org/jira/browse/CXF-7579 > Project: CXF > Issue Type: New Feature >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 3.2.2 > > > Implement MP Rest Client 1.0 (Draft spec at > download.eclipse.org/microprofile/microprofile-rest-client-1.0-T9/microprofile-rest-client.pdf > ) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CXF-7103) CDI Client Proxy injection
[ https://issues.apache.org/jira/browse/CXF-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament resolved CXF-7103. Resolution: Duplicate Fix Version/s: 3.2.2 This was technically done via the MP Rest Client feature - CXF-7579 > CDI Client Proxy injection > -- > > Key: CXF-7103 > URL: https://issues.apache.org/jira/browse/CXF-7103 > Project: CXF > Issue Type: Improvement > Components: Integration >Reporter: John D. Ament > Fix For: 3.2.2 > > > Add support for injecting client proxies via CDI, without additional producer > methods etc being required. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CXF-7610) Manage customizations of JAXRSServerFactoryBean in core
John D. Ament created CXF-7610:
--
Summary: Manage customizations of JAXRSServerFactoryBean in core
Key: CXF-7610
URL: https://issues.apache.org/jira/browse/CXF-7610
Project: CXF
Issue Type: New Feature
Components: JAX-RS
Reporter: John D. Ament
Assignee: John D. Ament
CDI has a built in way to manage customizations to the server, via
implementations of beans of type {{JAXRSServerFactoryCustomizationExtension}}.
However, it makes sense for this to be a core feature and leverage something
like a {{ServiceLoader}} pattern to discover those implementations, as well as
allowing CDI beans to be discovered.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CXF-7611) Define an internal SPI for automatically discovering components
John D. Ament created CXF-7611:
--
Summary: Define an internal SPI for automatically discovering
components
Key: CXF-7611
URL: https://issues.apache.org/jira/browse/CXF-7611
Project: CXF
Issue Type: New Feature
Components: JAX-RS
Reporter: John D. Ament
Other JAX-RS runtimes provide an internal SPI for registering components to be
discovered automatically.
For instance, Jersey uses
[AutoDiscoverable|https://github.com/jersey/jersey/blob/master/core-common/src/main/java/org/glassfish/jersey/internal/spi/AutoDiscoverable.java]
(this link may change due to ee4j moves)
and Resteasy will look for {{ServiceLoader}} files that are defined as
{{javax.ws.rs.ext.Providers}} but manually process the entries to load them.
CXF as best as I can tell has no capability like this, and instead relies on
the DI runtimes to register providers. This type of feature may make sense to
have in a future JAX-RS specification update, and I think we should have a
similar mechanism available so that users can register providers in a DI
independent way.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CXF-7612) Don't require a default constructor for CDI managed JAX-RS resources
John D. Ament created CXF-7612:
--
Summary: Don't require a default constructor for CDI managed
JAX-RS resources
Key: CXF-7612
URL: https://issues.apache.org/jira/browse/CXF-7612
Project: CXF
Issue Type: New Feature
Components: JAX-RS
Reporter: John D. Ament
Presently, CXF requires a default constructor on all components being used in a
CDI runtime. This is because we first create a {{PerRequestResourceProvider}}
and then replace that with a {{CdiResourceProvider}}. We should come up with a
way to use the already created {{ResourceProvider}} instead of instantiating
two of them.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7610) Manage customizations of JAXRSServerFactoryBean in JAX-RS Frontend
[
https://issues.apache.org/jira/browse/CXF-7610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament updated CXF-7610:
---
Summary: Manage customizations of JAXRSServerFactoryBean in JAX-RS Frontend
(was: Manage customizations of JAXRSServerFactoryBean in core)
> Manage customizations of JAXRSServerFactoryBean in JAX-RS Frontend
> --
>
> Key: CXF-7610
> URL: https://issues.apache.org/jira/browse/CXF-7610
> Project: CXF
> Issue Type: New Feature
> Components: JAX-RS
>Reporter: John D. Ament
>Assignee: John D. Ament
>
> CDI has a built in way to manage customizations to the server, via
> implementations of beans of type
> {{JAXRSServerFactoryCustomizationExtension}}. However, it makes sense for
> this to be a core feature and leverage something like a {{ServiceLoader}}
> pattern to discover those implementations, as well as allowing CDI beans to
> be discovered.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament updated CXF-7571:
---
Fix Version/s: 3.2.2
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: John D. Ament
> Fix For: 3.2.2
>
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together {{@Context}}- and {{@Inject}}-based injections.
> Encapsulating CXF injection implementation and than delegating the hard work
> to appropriate strategy (CDI, Spring, ...) would be the right solution to
> address the problem at its roots.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament resolved CXF-7571.
Resolution: Fixed
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: John D. Ament
>Priority: Major
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together {{@Context}}- and {{@Inject}}-based injections.
> Encapsulating CXF injection implementation and than delegating the hard work
> to appropriate strategy (CDI, Spring, ...) would be the right solution to
> address the problem at its roots.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16350769#comment-16350769
]
John D. Ament commented on CXF-7571:
[~dkulp] whats left to do on this?
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: John D. Ament
>Priority: Major
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together {{@Context}}- and {{@Inject}}-based injections.
> Encapsulating CXF injection implementation and than delegating the hard work
> to appropriate strategy (CDI, Spring, ...) would be the right solution to
> address the problem at its roots.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament updated CXF-7571:
---
Fix Version/s: 3.2.2
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Reporter: Andriy Redko
>Assignee: John D. Ament
>Priority: Major
> Fix For: 3.2.2
>
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together {{@Context}}- and {{@Inject}}-based injections.
> Encapsulating CXF injection implementation and than delegating the hard work
> to appropriate strategy (CDI, Spring, ...) would be the right solution to
> address the problem at its roots.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16351840#comment-16351840
]
John D. Ament commented on CXF-7571:
[~dkulp] K, fixed.
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Reporter: Andriy Redko
>Assignee: John D. Ament
>Priority: Major
> Fix For: 3.2.2
>
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together {{@Context}}- and {{@Inject}}-based injections.
> Encapsulating CXF injection implementation and than delegating the hard work
> to appropriate strategy (CDI, Spring, ...) would be the right solution to
> address the problem at its roots.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament updated CXF-7571:
---
Component/s: JAX-RS
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Reporter: Andriy Redko
>Assignee: John D. Ament
>Priority: Major
> Fix For: 3.2.2
>
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together {{@Context}}- and {{@Inject}}-based injections.
> Encapsulating CXF injection implementation and than delegating the hard work
> to appropriate strategy (CDI, Spring, ...) would be the right solution to
> address the problem at its roots.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7631) Automatically register rx in server customizations
John D. Ament created CXF-7631:
--
Summary: Automatically register rx in server customizations
Key: CXF-7631
URL: https://issues.apache.org/jira/browse/CXF-7631
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Affects Versions: 3.2.2
Reporter: John D. Ament
Assignee: John D. Ament
Presently to register reactive for server components, you need to add this
logic:
{code:java}
ReactorInvoker invoker = new ReactorInvoker();
invoker.setUseStreamingSubscriberIfPossible(false);
jaxrsServerFactoryBean.setInvoker(invoker);
StreamingResponseProvider streamProvider = new StreamingResponseProvider<>();
streamProvider.setProduceMediaTypes(Collections.singletonList("application/json"));
jaxrsServerFactoryBean.setProvider(streamProvider);{code}
This ideally should be automated, and auto discovered when deployed to a server.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7632) MP Rest Client uses a static discovery pattern instead of an instance discovery pattern
John D. Ament created CXF-7632: -- Summary: MP Rest Client uses a static discovery pattern instead of an instance discovery pattern Key: CXF-7632 URL: https://issues.apache.org/jira/browse/CXF-7632 Project: CXF Issue Type: Improvement Affects Versions: 3.2.2 Reporter: John D. Ament The extension used by the MP Rest Client for CDI beans is static based. This could mean that multiple applications would conflict with the discovered classes. Instead it should be instance based. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7635) Reactive Streams is not an optional dependency
John D. Ament created CXF-7635: -- Summary: Reactive Streams is not an optional dependency Key: CXF-7635 URL: https://issues.apache.org/jira/browse/CXF-7635 Project: CXF Issue Type: Improvement Components: JAX-RS Affects Versions: 3.2.2 Reporter: John D. Ament Assignee: John D. Ament The reactive streams dependency is incorrectly marked as provided, optional, but it's not. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7610) Manage customizations of JAXRSServerFactoryBean in JAX-RS Frontend
[
https://issues.apache.org/jira/browse/CXF-7610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament updated CXF-7610:
---
Fix Version/s: 3.2.3
> Manage customizations of JAXRSServerFactoryBean in JAX-RS Frontend
> --
>
> Key: CXF-7610
> URL: https://issues.apache.org/jira/browse/CXF-7610
> Project: CXF
> Issue Type: New Feature
> Components: JAX-RS
>Reporter: John D. Ament
>Assignee: John D. Ament
>Priority: Major
> Fix For: 3.2.3
>
>
> CDI has a built in way to manage customizations to the server, via
> implementations of beans of type
> {{JAXRSServerFactoryCustomizationExtension}}. However, it makes sense for
> this to be a core feature and leverage something like a {{ServiceLoader}}
> pattern to discover those implementations, as well as allowing CDI beans to
> be discovered.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-7610) Manage customizations of JAXRSServerFactoryBean in JAX-RS Frontend
[
https://issues.apache.org/jira/browse/CXF-7610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament resolved CXF-7610.
Resolution: Fixed
> Manage customizations of JAXRSServerFactoryBean in JAX-RS Frontend
> --
>
> Key: CXF-7610
> URL: https://issues.apache.org/jira/browse/CXF-7610
> Project: CXF
> Issue Type: New Feature
> Components: JAX-RS
>Reporter: John D. Ament
>Assignee: John D. Ament
>Priority: Major
> Fix For: 3.2.3
>
>
> CDI has a built in way to manage customizations to the server, via
> implementations of beans of type
> {{JAXRSServerFactoryCustomizationExtension}}. However, it makes sense for
> this to be a core feature and leverage something like a {{ServiceLoader}}
> pattern to discover those implementations, as well as allowing CDI beans to
> be discovered.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7642) Split rxjava and rxjava2 modules
John D. Ament created CXF-7642: -- Summary: Split rxjava and rxjava2 modules Key: CXF-7642 URL: https://issues.apache.org/jira/browse/CXF-7642 Project: CXF Issue Type: Improvement Components: JAX-RS Affects Versions: 3.2.2 Reporter: John D. Ament Split the two modules (rxjava, rxjava2) to fix the dependency hierarchy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7638) JAXRS CTS/TCK issue: register(...) should ignore components when invalid contracts are passed in
[
https://issues.apache.org/jira/browse/CXF-7638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16359955#comment-16359955
]
John D. Ament commented on CXF-7638:
[~andymc] what about the following (in your case)?
{code:java}
c.register(new MyProvider(), ExceptionMapper.class,
MessageBodyWriter.class);{code}
where one contract is valid, and the other is not.
> JAXRS CTS/TCK issue: register(...) should ignore components when invalid
> contracts are passed in
> -
>
> Key: CXF-7638
> URL: https://issues.apache.org/jira/browse/CXF-7638
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.2.3
>
>
> We're seeing some failures when running the JAX-RS 2.1 TCK - particularly
> around the register method. The javadoc states that the implementation MUST
> ignore the component if the call to register specifies a contract (interface)
> that the component does not implement.
> So, for example, suppose somebody calls code like this:
>
> public class MyProvider implements MessageBodyWriter ...
>
> Client c = ClientBuilder.newClient();
> c.register(MyProvider.class, ContainerRequestFilter.class); // should ignore
> c.register(new MyProvider, ExceptionMapper.class, MessageBodyReader.class);
> // should ignore
> Map contractPriorityMap = new HashMap<>();
> contractPriorityMap.put(ClientResponseFilter.class, 20);
> c.register(MyProvider.class, contractPriorityMap); // should ignore
> c.register(new MyProvider.class, contractPriorityMap); // should ignore
>
> The TCK tests basically check that nothing gets registered when a passed-in
> contract is not assignable to the provider class. And scenarios like the
> four mentioned above are failing.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7631) Automatically register rx in server customizations
[
https://issues.apache.org/jira/browse/CXF-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16359967#comment-16359967
]
John D. Ament commented on CXF-7631:
This ticket will only be for project reactor. As a part of CXF-7642, I'm
splitting the modules and will take care of rxjava there.
> Automatically register rx in server customizations
> --
>
> Key: CXF-7631
> URL: https://issues.apache.org/jira/browse/CXF-7631
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: John D. Ament
>Assignee: John D. Ament
>Priority: Major
>
> Presently to register reactive for server components, you need to add this
> logic:
>
> {code:java}
> ReactorInvoker invoker = new ReactorInvoker();
> invoker.setUseStreamingSubscriberIfPossible(false);
> jaxrsServerFactoryBean.setInvoker(invoker);
> StreamingResponseProvider streamProvider = new
> StreamingResponseProvider<>();
> streamProvider.setProduceMediaTypes(Collections.singletonList("application/json"));
> jaxrsServerFactoryBean.setProvider(streamProvider);{code}
>
> This ideally should be automated, and auto discovered when deployed to a
> server.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7635) Reactive Streams is not an optional dependency
[ https://issues.apache.org/jira/browse/CXF-7635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16359972#comment-16359972 ] John D. Ament commented on CXF-7635: This only dealt with project-reactor integration, rxjava2 is being handled in CXF-7642 due to the module split. > Reactive Streams is not an optional dependency > -- > > Key: CXF-7635 > URL: https://issues.apache.org/jira/browse/CXF-7635 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.2.2 >Reporter: John D. Ament >Assignee: John D. Ament >Priority: Major > Fix For: 3.2.3 > > > The reactive streams dependency is incorrectly marked as provided, optional, > but it's not. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7635) Reactive Streams is not an optional dependency
[ https://issues.apache.org/jira/browse/CXF-7635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament resolved CXF-7635. Resolution: Fixed Fix Version/s: 3.2.3 > Reactive Streams is not an optional dependency > -- > > Key: CXF-7635 > URL: https://issues.apache.org/jira/browse/CXF-7635 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.2.2 >Reporter: John D. Ament >Assignee: John D. Ament >Priority: Major > Fix For: 3.2.3 > > > The reactive streams dependency is incorrectly marked as provided, optional, > but it's not. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7642) Split rxjava and rxjava2 modules
[ https://issues.apache.org/jira/browse/CXF-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament updated CXF-7642: --- Fix Version/s: 3.2.3 > Split rxjava and rxjava2 modules > > > Key: CXF-7642 > URL: https://issues.apache.org/jira/browse/CXF-7642 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.2.2 >Reporter: John D. Ament >Priority: Major > Fix For: 3.2.3 > > > Split the two modules (rxjava, rxjava2) to fix the dependency hierarchy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7631) Automatically register rx in server customizations
[
https://issues.apache.org/jira/browse/CXF-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John D. Ament resolved CXF-7631.
Resolution: Fixed
Fix Version/s: 3.2.3
> Automatically register rx in server customizations
> --
>
> Key: CXF-7631
> URL: https://issues.apache.org/jira/browse/CXF-7631
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: John D. Ament
>Assignee: John D. Ament
>Priority: Major
> Fix For: 3.2.3
>
>
> Presently to register reactive for server components, you need to add this
> logic:
>
> {code:java}
> ReactorInvoker invoker = new ReactorInvoker();
> invoker.setUseStreamingSubscriberIfPossible(false);
> jaxrsServerFactoryBean.setInvoker(invoker);
> StreamingResponseProvider streamProvider = new
> StreamingResponseProvider<>();
> streamProvider.setProduceMediaTypes(Collections.singletonList("application/json"));
> jaxrsServerFactoryBean.setProvider(streamProvider);{code}
>
> This ideally should be automated, and auto discovered when deployed to a
> server.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-7642) Split rxjava and rxjava2 modules
[ https://issues.apache.org/jira/browse/CXF-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament resolved CXF-7642. Resolution: Fixed Assignee: John D. Ament > Split rxjava and rxjava2 modules > > > Key: CXF-7642 > URL: https://issues.apache.org/jira/browse/CXF-7642 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.2.2 >Reporter: John D. Ament >Assignee: John D. Ament >Priority: Major > Fix For: 3.2.3 > > > Split the two modules (rxjava, rxjava2) to fix the dependency hierarchy. -- 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=16365429#comment-16365429
]
John D. Ament commented on CXF-7643:
[~romain.manni-bucau] the entire CDI feature is not per spec, since most of the
integration is meant for the application server. AIUI the conflict is
{{javax.servlet}} only, so you could just observe that {{ProcessBean}} event
and rewrite it then.
> [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)
