[jira] [Commented] (CXF-7117) Swagger2Feature not working in OSGi container when jaxrs server address not attached to CXF servlet
[
https://issues.apache.org/jira/browse/CXF-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15666597#comment-15666597
]
Concombre Masqué commented on CXF-7117:
---
Hi Andriy,
Thank you for your effort on this issue. Yes, after my own investigation, I
have figured out that ServletConfig is required to make Swagger2Feature work as
expected.
Using "scan" does not help in fact since I always have to deploy several
bundles with JAX-RS servers. And I think my use case is not an exception. As a
result Swagger2Feature seems to be of no use in an OSGi environment.
Do you think it is possible to instantiate a ServletConfig object and provide
it to Swagger2Feature (by exposing a dedicated setter) to solve the problem?
Many thanks.
> Swagger2Feature not working in OSGi container when jaxrs server address not
> attached to CXF servlet
> ---
>
> Key: CXF-7117
> URL: https://issues.apache.org/jira/browse/CXF-7117
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.8
> Environment: Apache Karaf 3.0.8
>Reporter: Concombre Masqué
>Assignee: Andriy Redko
>
> Just modify sample description_swagger2_osgi as follows:
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
> address="http://localhost:9091/test/swaggerSample";>
>
>
>
>
>
>
>
>
>
>
>
>
> Then deploy modified bundle into Karaf and browse Swagger service definition
> at http://localhost:9091/test/swaggerSample/swagger.json
> Result is:
> {"swagger":"2.0"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7015) Invalid URL encoding causes error 500
[
https://issues.apache.org/jira/browse/CXF-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15666721#comment-15666721
]
ASF GitHub Bot commented on CXF-7015:
-
GitHub user iammichaelgrant opened a pull request:
https://github.com/apache/cxf/pull/196
[CXF-7015] Capture invalid escapes and throw IllegalArgumentException
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/iammichaelgrant/cxf CXF-7015
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/196.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #196
commit 8245a77f706a2611857700d9922c149397384c52
Author: Michael Grant
Date: 2016-11-15T10:01:04Z
[CXF-7015] Capture invalid escapes and throw IllegalArgumentException
> Invalid URL encoding causes error 500
> -
>
> Key: CXF-7015
> URL: https://issues.apache.org/jira/browse/CXF-7015
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.4
>Reporter: Sanjay Patel
>
> When using Apache CXF JAX RS Client 3.0.3
> We would get a 400 Response with URLDecoder: Incomplete trailing escape (%)
> pattern.
> Using Apache CXF JAX RS Client 3.0.4 and above we see the below issue.
> If we make a request using JAX RS to Spring with an invalid URL encoding,
> such as %3, we are getting a 500 Response, and an BufferUnderflowException.
> As seen below.
> {code}
> java.nio.BufferUnderflowException at
> java.nio.Buffer.nextGetIndex(Buffer.java:500) at
> java.nio.HeapByteBuffer.get(HeapByteBuffer.java:135) at
> org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:96) at
> org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:67) at
> org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:122) at
> org.apache.cxf.jaxrs.utils.HttpUtils.urlDecode(HttpUtils.java:97) at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1262)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1236)
> at
> org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:115)
> at
> org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:109)
> at
> org.apache.cxf.jaxrs.impl.RequestPreprocessor.preprocess(RequestPreprocessor.java:74)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:102)
> 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:254)
> 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:180)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:222)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:622) at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(Standard
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15666919#comment-15666919 ] ASF GitHub Bot commented on CXF-7132: - Github user johnament commented on the issue: https://github.com/apache/cxf/pull/195 Looks like the failures are not related to CDI... https://builds.apache.org/job/CXF-Trunk-PR/200/ > 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] [Commented] (CXF-7000) Allow logging to be enabled on-the-fly
[ https://issues.apache.org/jira/browse/CXF-7000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15666953#comment-15666953 ] Ingo Weiss commented on CXF-7000: - Hi [~sergey_beryozkin], what is the issue number? I would like to take a look at it. Thanks. > Allow logging to be enabled on-the-fly > -- > > Key: CXF-7000 > URL: https://issues.apache.org/jira/browse/CXF-7000 > Project: CXF > Issue Type: Improvement > Components: Core, logging >Affects Versions: 3.1.7 >Reporter: Ingo Weiss >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.8 > > > Allow the logging feature to be enabled on-the-fly without restarting the bus. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15667013#comment-15667013 ] ASF GitHub Bot commented on CXF-7132: - Github user reta commented on the issue: https://github.com/apache/cxf/pull/195 Thanks a lot for the fix, @johnament, will work on merging tonight > 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] [Commented] (CXF-7117) Swagger2Feature not working in OSGi container when jaxrs server address not attached to CXF servlet
[
https://issues.apache.org/jira/browse/CXF-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15667024#comment-15667024
]
Andriy Redko commented on CXF-7117:
---
Hi Concombre,
Yes, there is a way to introduce the ServletConfig even if it not available. We
are discussing this option with [~sergey_beryozkin] at the moment to make sure
that we won't have unexpected side-effects (where Swagger will work but some
other parts may stop working). I will post an update shortly. Thanks!
Best Regards,
Andriy Redko
> Swagger2Feature not working in OSGi container when jaxrs server address not
> attached to CXF servlet
> ---
>
> Key: CXF-7117
> URL: https://issues.apache.org/jira/browse/CXF-7117
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.8
> Environment: Apache Karaf 3.0.8
>Reporter: Concombre Masqué
>Assignee: Andriy Redko
>
> Just modify sample description_swagger2_osgi as follows:
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
> address="http://localhost:9091/test/swaggerSample";>
>
>
>
>
>
>
>
>
>
>
>
>
> Then deploy modified bundle into Karaf and browse Swagger service definition
> at http://localhost:9091/test/swaggerSample/swagger.json
> Result is:
> {"swagger":"2.0"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-7117) Swagger2Feature not working in OSGi container when jaxrs server address not attached to CXF servlet
[
https://issues.apache.org/jira/browse/CXF-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15667025#comment-15667025
]
Andriy Redko edited comment on CXF-7117 at 11/15/16 12:37 PM:
--
Hi Concombre,
Yes, there is a way to introduce the ServletConfig even if it is not available.
We are discussing this option with [~sergey_beryozkin] at the moment to make
sure that we won't have unexpected side-effects (where Swagger will work but
some other parts may stop working). I will post an update shortly. Thanks!
Best Regards,
Andriy Redko
was (Author: reta):
Hi Concombre,
Yes, there is a way to introduce the ServletConfig even if it not available. We
are discussing this option with [~sergey_beryozkin] at the moment to make sure
that we won't have unexpected side-effects (where Swagger will work but some
other parts may stop working). I will post an update shortly. Thanks!
Best Regards,
Andriy Redko
> Swagger2Feature not working in OSGi container when jaxrs server address not
> attached to CXF servlet
> ---
>
> Key: CXF-7117
> URL: https://issues.apache.org/jira/browse/CXF-7117
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.8
> Environment: Apache Karaf 3.0.8
>Reporter: Concombre Masqué
>Assignee: Andriy Redko
>
> Just modify sample description_swagger2_osgi as follows:
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
> address="http://localhost:9091/test/swaggerSample";>
>
>
>
>
>
>
>
>
>
>
>
>
> Then deploy modified bundle into Karaf and browse Swagger service definition
> at http://localhost:9091/test/swaggerSample/swagger.json
> Result is:
> {"swagger":"2.0"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7117) Swagger2Feature not working in OSGi container when jaxrs server address not attached to CXF servlet
[
https://issues.apache.org/jira/browse/CXF-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15667025#comment-15667025
]
Andriy Redko commented on CXF-7117:
---
Hi Concombre,
Yes, there is a way to introduce the ServletConfig even if it not available. We
are discussing this option with [~sergey_beryozkin] at the moment to make sure
that we won't have unexpected side-effects (where Swagger will work but some
other parts may stop working). I will post an update shortly. Thanks!
Best Regards,
Andriy Redko
> Swagger2Feature not working in OSGi container when jaxrs server address not
> attached to CXF servlet
> ---
>
> Key: CXF-7117
> URL: https://issues.apache.org/jira/browse/CXF-7117
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.8
> Environment: Apache Karaf 3.0.8
>Reporter: Concombre Masqué
>Assignee: Andriy Redko
>
> Just modify sample description_swagger2_osgi as follows:
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
> address="http://localhost:9091/test/swaggerSample";>
>
>
>
>
>
>
>
>
>
>
>
>
> Then deploy modified bundle into Karaf and browse Swagger service definition
> at http://localhost:9091/test/swaggerSample/swagger.json
> Result is:
> {"swagger":"2.0"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15667081#comment-15667081 ] ASF GitHub Bot commented on CXF-7132: - Github user rmannibucau commented on the issue: https://github.com/apache/cxf/pull/195 should loadResourceProviders support not normal-scoped instances too (doesn't ATM it seems)? > 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] [Commented] (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:comment-tabpanel&focusedCommentId=15667155#comment-15667155 ] ASF GitHub Bot commented on CXF-7132: - Github user johnament commented on the issue: https://github.com/apache/cxf/pull/195 @rmannibucau you are correct, there is a regression problem with non-normal scoped beans. The code works. Specifically for dependent and singleton, since they're not using proxies, the instance you get back is the same. This essentially makes dependent == singleton. You can see that the test does include both normal scoped and dependent beans https://github.com/johnament/cxf/tree/81e9215b75c02a6b108e94f474b9aa6011c8f00c/systests/cdi/base/src/main/java/org/apache/cxf/systests/cdi/base - look at BookStore and VersionService as examples. The code does work, but I would expect a per-request pattern to be used for dependent. More refinement required to clean up this CDI integration. > 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] [Commented] (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:comment-tabpanel&focusedCommentId=15667161#comment-15667161 ] ASF GitHub Bot commented on CXF-7132: - Github user rmannibucau commented on the issue: https://github.com/apache/cxf/pull/195 @johnament think singleton per default is fine (even good) but I don't think it works. Add a @PreDestroy releasing a socket pool (http pool to get some meta config for instance) and you will just leak this since the creational context is not released. > 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-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] [Commented] (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:comment-tabpanel&focusedCommentId=15667167#comment-15667167 ] ASF GitHub Bot commented on CXF-7132: - Github user reta commented on the issue: https://github.com/apache/cxf/pull/195 @rmannibucau @johnament I think the CdiResourceProvider should be involved more here. The creation context could be released when `release` call happens. > 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] [Commented] (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:comment-tabpanel&focusedCommentId=15667168#comment-15667168 ] ASF GitHub Bot commented on CXF-7132: - Github user johnament commented on the issue: https://github.com/apache/cxf/pull/195 @rmannibucau yes, that is the other problem. But that's been a long standing issue with leaking instances, way before my time. I'll clean that up though. Raised https://issues.apache.org/jira/browse/CXF-7134 @reta Yes, I agree. That's where I plan to put the `release`. > 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] [Commented] (CXF-7117) Swagger2Feature not working in OSGi container when jaxrs server address not attached to CXF servlet
[
https://issues.apache.org/jira/browse/CXF-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15667651#comment-15667651
]
Sergey Beryozkin commented on CXF-7117:
---
Hi [~nsaboy], as I already noted the feature does work in OSGI for a case where
JAX-RS endpoints bind to OSGI HttpService which is usually a recommended
approach for CXF endpoints, it also works for embedded Jetty, the only
limitation I see is that if you have multiple endpoints with absolute HTTP
addresses in a single bundle then it won't work correctly which is not the same
as the feature is of no use in OSGI.
Hi Andriy, I wonder if we should explore why 'scan'='false' has no effect in
this case...
Thanks, Sergey
> Swagger2Feature not working in OSGi container when jaxrs server address not
> attached to CXF servlet
> ---
>
> Key: CXF-7117
> URL: https://issues.apache.org/jira/browse/CXF-7117
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.8
> Environment: Apache Karaf 3.0.8
>Reporter: Concombre Masqué
>Assignee: Andriy Redko
>
> Just modify sample description_swagger2_osgi as follows:
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
> address="http://localhost:9091/test/swaggerSample";>
>
>
>
>
>
>
>
>
>
>
>
>
> Then deploy modified bundle into Karaf and browse Swagger service definition
> at http://localhost:9091/test/swaggerSample/swagger.json
> Result is:
> {"swagger":"2.0"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7117) Swagger2Feature not working in OSGi container when jaxrs server address not attached to CXF servlet
[
https://issues.apache.org/jira/browse/CXF-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15667736#comment-15667736
]
Concombre Masqué commented on CXF-7117:
---
Hi Sergey,
That's not exactly what I experience: the limitation is mostly annoying when
you have several bundle exposing one JAX-RS endpoint with absolute HTTP
address. This is my use case (1 JAX-RS endpoint with absolute HTTP address per
bundle and several bundle deployed in Karaf: always got same Swagger descriptor
for all JAX-RS endpoints). Thus, to me, this feature is of no use in OSGi
(unless you use default CXF Servlet but I don't want to have all of my REST
services on the same port).
Regards.
> Swagger2Feature not working in OSGi container when jaxrs server address not
> attached to CXF servlet
> ---
>
> Key: CXF-7117
> URL: https://issues.apache.org/jira/browse/CXF-7117
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.8
> Environment: Apache Karaf 3.0.8
>Reporter: Concombre Masqué
>Assignee: Andriy Redko
>
> Just modify sample description_swagger2_osgi as follows:
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
> address="http://localhost:9091/test/swaggerSample";>
>
>
>
>
>
>
>
>
>
>
>
>
> Then deploy modified bundle into Karaf and browse Swagger service definition
> at http://localhost:9091/test/swaggerSample/swagger.json
> Result is:
> {"swagger":"2.0"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7117) Swagger2Feature not working in OSGi container when jaxrs server address not attached to CXF servlet
[
https://issues.apache.org/jira/browse/CXF-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15668455#comment-15668455
]
Sergey Beryozkin commented on CXF-7117:
---
Right, I see what you mean. Swagger just picks up everything and at least with
a servlet based approach it can be dealt with. It is quite hard to control the
Swagger behaviour, Swagger2Feature already does many tricks. Looks like one
more is needed, surely Andriy will think of something :-)
> Swagger2Feature not working in OSGi container when jaxrs server address not
> attached to CXF servlet
> ---
>
> Key: CXF-7117
> URL: https://issues.apache.org/jira/browse/CXF-7117
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.8
> Environment: Apache Karaf 3.0.8
>Reporter: Concombre Masqué
>Assignee: Andriy Redko
>
> Just modify sample description_swagger2_osgi as follows:
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
> address="http://localhost:9091/test/swaggerSample";>
>
>
>
>
>
>
>
>
>
>
>
>
> Then deploy modified bundle into Karaf and browse Swagger service definition
> at http://localhost:9091/test/swaggerSample/swagger.json
> Result is:
> {"swagger":"2.0"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15669079#comment-15669079 ] ASF GitHub Bot commented on CXF-7132: - Github user johnament commented on the issue: https://github.com/apache/cxf/pull/195 Ok, I added a couple more commits to this. I'm not 100% happy with CXF-7134 but don't want to block a potential release. What I'm seeing is that validation feature doesn't get registered on the JAX-RS resource when I move the creational context to the point of getting the instance. Need to debug a bit further, but I think this is OK to merge for now. Just leave 7134 open I'll clean up further. > 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] [Commented] (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:comment-tabpanel&focusedCommentId=15669089#comment-15669089 ] ASF GitHub Bot commented on CXF-7132: - Github user reta commented on the issue: https://github.com/apache/cxf/pull/195 Hey @johnament , could you please create a separate PRs for these commits? I am about to close the original one, related to @RequestScoped. Now things may get complicated :-) Thanks! > 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] [Commented] (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:comment-tabpanel&focusedCommentId=15669094#comment-15669094 ] ASF GitHub Bot commented on CXF-7132: - Github user johnament commented on the issue: https://github.com/apache/cxf/pull/195 I can. I wasn't sure if you were holding off due to the conversation here. > 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] [Commented] (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:comment-tabpanel&focusedCommentId=15669098#comment-15669098 ] ASF GitHub Bot commented on CXF-7132: - Github user johnament closed the pull request at: https://github.com/apache/cxf/pull/195 > 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] [Commented] (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:comment-tabpanel&focusedCommentId=15669099#comment-15669099 ] ASF GitHub Bot commented on CXF-7132: - GitHub user johnament opened a pull request: https://github.com/apache/cxf/pull/197 [CXF-7132] Use the original class when it comes to determining classe… …s for ResourceProvider usage. You can merge this pull request into a Git repository by running: $ git pull https://github.com/johnament/cxf CXF-7132-solo Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/197.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #197 commit 6964968e9a43970290576f01f8634f8d892ebf03 Author: John D. Ament Date: 2016-11-15T01:26:58Z [CXF-7132] Use the original class when it comes to determining classes for ResourceProvider usage. > 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] [Commented] (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:comment-tabpanel&focusedCommentId=15669101#comment-15669101 ] ASF GitHub Bot commented on CXF-7132: - Github user johnament closed the pull request at: https://github.com/apache/cxf/pull/197 > 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] [Commented] (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:comment-tabpanel&focusedCommentId=15669103#comment-15669103 ] ASF GitHub Bot commented on CXF-7132: - Github user reta commented on the issue: https://github.com/apache/cxf/pull/195 I taken the approach we have discussed, moving more responsibilities to CdiResourceProvider, I think I have gotten a bit cleaner implementation. > 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] [Commented] (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:comment-tabpanel&focusedCommentId=15669108#comment-15669108 ] ASF GitHub Bot commented on CXF-7132: - GitHub user johnament opened a pull request: https://github.com/apache/cxf/pull/198 [CXF-7132] Use the original class when it comes to determining classe… …s for ResourceProvider usage. You can merge this pull request into a Git repository by running: $ git pull https://github.com/johnament/cxf CXF-7132 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/198.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #198 commit 81e9215b75c02a6b108e94f474b9aa6011c8f00c Author: John D. Ament Date: 2016-11-15T01:26:58Z [CXF-7132] Use the original class when it comes to determining classes for ResourceProvider usage. > 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] [Commented] (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:comment-tabpanel&focusedCommentId=15669170#comment-15669170 ] ASF GitHub Bot commented on CXF-7132: - Github user asfgit closed the pull request at: https://github.com/apache/cxf/pull/198 > 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] [Commented] (CXF-7133) Don't rely on disabled scanning in CDI
[ https://issues.apache.org/jira/browse/CXF-7133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15669229#comment-15669229 ] ASF GitHub Bot commented on CXF-7133: - GitHub user johnament opened a pull request: https://github.com/apache/cxf/pull/199 CXF-7133 Clean up how default app is loaded and avoid extra XML confi… …guration. You can merge this pull request into a Git repository by running: $ git pull https://github.com/johnament/cxf CXF-7133-default-app Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/199.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #199 commit 1c21a8e1b8db2c03e1a20108085a9ba4ef939f5e Author: John D. Ament Date: 2016-11-16T03:16:36Z CXF-7133 Clean up how default app is loaded and avoid extra XML configuration. > 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] [Commented] (CXF-7134) Fix how non-normal scoped beans are used in CDI extension
[ https://issues.apache.org/jira/browse/CXF-7134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15669230#comment-15669230 ] ASF GitHub Bot commented on CXF-7134: - GitHub user johnament opened a pull request: https://github.com/apache/cxf/pull/200 CXF-7134 Store the creational context of each bean being created so t… …hey can be destroyed later on. You can merge this pull request into a Git repository by running: $ git pull https://github.com/johnament/cxf CXF-7134-creational-context Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/200.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #200 commit 7d9a71658443c409b378f9f19949351845f83d86 Author: John D. Ament Date: 2016-11-16T03:19:03Z CXF-7134 Store the creational context of each bean being created so they can be destroyed later on. > 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] [Commented] (CXF-7133) Don't rely on disabled scanning in CDI
[ https://issues.apache.org/jira/browse/CXF-7133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15669242#comment-15669242 ] ASF GitHub Bot commented on CXF-7133: - Github user johnament commented on a diff in the pull request: https://github.com/apache/cxf/pull/199#discussion_r88162864 --- Diff: integration/cdi/src/main/resources/META-INF/beans.xml --- @@ -2,7 +2,4 @@ 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://jboss.org/schema/cdi/beans_1_1.xsd";> - --- End diff -- Having this config here makes shaded JARs hard to deal with in CXF. CDI has this feature built in to ignore the bean, which works better IMHO. > 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] [Commented] (CXF-7134) Fix how non-normal scoped beans are used in CDI extension
[ https://issues.apache.org/jira/browse/CXF-7134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15669247#comment-15669247 ] ASF GitHub Bot commented on CXF-7134: - Github user johnament commented on the pull request: https://github.com/apache/cxf/commit/13fa5dc1ffebe4e63a27f17528598925af04d570#commitcomment-19839560 In integration/cdi/src/main/java/org/apache/cxf/cdi/CdiResourceProvider.java: In integration/cdi/src/main/java/org/apache/cxf/cdi/CdiResourceProvider.java on line 43: These changes look more like changes for CXF-7134. > 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)
