[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=15641468#comment-15641468
]
Concombre Masqué commented on CXF-7117:
---
Hi Sergey,
If I remove both "basePath" and "usePathBasedConfig" it works yes. But I have
to use these properties since I deploy several bundles that expose jax-rs
servers.
Following what you suggest, if I deploy a second bundle (a modified version of
sample description_swagger2_osgi listening on
http://localhost:9090/test/swaggerSample2 for example) then I get the same
Swagger descriptor as first bundle (see issue CXF-6740).
That's why I use "usePathBasedConfig" but the fix for issue CXF-6740 does not
seem to handle jax-rs servers using addresses not under CXF servlet path
("/cxf").
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é
>
> 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] [Assigned] (CXF-7097) [CDI] application leaks a creational context
[ https://issues.apache.org/jira/browse/CXF-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko reassigned CXF-7097: - Assignee: Andriy Redko > [CDI] application leaks a creational context > > > Key: CXF-7097 > URL: https://issues.apache.org/jira/browse/CXF-7097 > Project: CXF > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko > > JAXRS application are not CDI beans but that's the way CXF CDI integration > gets the application - this is a nice feature. > It implies the application will rarely be normal-scope so it needs to release > its creational context created at > org.apache.cxf.cdi.JAXRSCdiResourceExtension#load > This should be done in BeforeShutdown container event I think. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [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=15642217#comment-15642217
]
Sergey Beryozkin commented on CXF-7117:
---
Hi,
So the issue is not about Swagger2Feature not working in OSGI when the
endpoints have the absolute URIs - it does for a single endpoint in a given
context case. But that the fix which supports the separation between Swagger
infos for different endpoints does not apply in this case.
The reason that fix does not apply is because it depends on the availability of
the servlet config which is not available in the case of the embedded Jetty
transport.
I can only suggest to disable those properties nonetheless and set a 'scan'
property to false, would that work ?
[~reta] Hey Andriy - please watch this issue in case you have some more ideas.
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é
>
> 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-6969) CXF Async HTTP Transport - add supports to configure httpclient with new method
[ https://issues.apache.org/jira/browse/CXF-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15642945#comment-15642945 ] Freeman Fang commented on CXF-6969: --- Hi Sergey, Sure, I will take a close look. Cheers Freeman > CXF Async HTTP Transport - add supports to configure httpclient with new > method > --- > > Key: CXF-6969 > URL: https://issues.apache.org/jira/browse/CXF-6969 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Chester Kim > > Refer to https://issues.apache.org/jira/browse/CXF-6964 > Configuration of timeout and etc of httpclient with properties are deprecated > in the latest version of apache httpcomponents. We need to go with new way > (Configuration class). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7122) Infinite loop due to AsyncHTTPConduit read timeout with exhausted connection pool
[ https://issues.apache.org/jira/browse/CXF-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15643233#comment-15643233 ] Freeman Fang commented on CXF-7122: --- Hi William, FYI, with your original patch, with the AsyncHTTPConduitTest I appended, you can run into infinite loop also with AsyncHTTPConduitTest#testTimeout, so both the sync and async way has the infinite loop issue. If you will re-work a solution, please also consider this. Btw, the SocketTimeoutException name may not be appropriate for all case, we can reconsider to use more accurate exception name like RecieveTimeoutException after the real issue get resolved. And if you wanna more help from community to resolve the issue you ran into, a reproducer test case definitely would be more helpful. Thanks Freeman > Infinite loop due to AsyncHTTPConduit read timeout with exhausted connection > pool > - > > Key: CXF-7122 > URL: https://issues.apache.org/jira/browse/CXF-7122 > Project: CXF > Issue Type: Bug > Components: Transports >Reporter: William Montaz >Assignee: Freeman Fang >Priority: Critical > Fix For: 3.2.0, 3.1.9 > > Attachments: AsyncHTTPConduitTest.java > > > Using AsyncHTTPConduit, when the underlying connection pool gets exhausted, > requests waiting for a connection will lead to an infinite loop if they reach > receive timeout. > The problem occured on all versions of CXF above 3.0.5 (we did not tested > other ones). > Let's imagine a backend that's broken and leads to timeout for all requests. > When handling requests, the cxf worker thread will eventually go in wait > state (AsyncHTTPConduit:618), with a timeout that matches the > HTTPClientPolicy.setReceiveTimeout() value, waiting for the NIO stack to > complete and call notifyAll via responseCallback (AsyncHTTPConduit:455). > The timeout on the wait is the big problem : > With our broken backend, the connection pool is exhausted waiting for other > requests to timeout. When a new request is made by cxf against this backend, > after timeout time this will happen : > - on the one side the reactor threads will get a connection from the pool > and try to write to the output stream. Waiting in the pool is not considered > as receive timeout. > - on the other side the cxf worker thread will wake up (because of the > timedout wait), and shutdown SharedOutputBuffer and SharedInputBuffer > (AsyncHTTPClient:624) > - reactor threads will go to infinite loop because they will try to > produceContent from a shutdown buffer (SharedOutputBuffer:120) > > From there, application recovery is compromised. > > To fix that, timeout should be handled only via the client callback > (AsyncHTTPConduit:463). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
