[jira] [Comment Edited] (CXF-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter

2016-10-21 Thread JIRA

[ 
https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15592627#comment-15592627
 ] 

Rainer Müller edited comment on CXF-7023 at 10/21/16 7:29 AM:
--

Patch fixed our issue with WebSphere MQ Resource Adapter 7.5.0.5 running in 
JBoss EAP 7.0.2.GA and Apache CXF version 3.1.6.

Any plans when the fix will be release with Apache CXF?

Closed the duplicate issue CXF-7094.


was (Author: rainer.mueller):
Patch fixed our issue with WebSphere MQ Resource Adapter running in JBoss EAP 
7.0.2.GA and Apache CXF version 3.1.6.

Any plans when the fix will be release with Apache CXF?

Closed the duplicate issue CXF-7094.

> SOAP over JMS transport does not use XA transactions with Websphere MQ 
> resource adapter
> ---
>
> Key: CXF-7023
> URL: https://issues.apache.org/jira/browse/CXF-7023
> Project: CXF
>  Issue Type: Bug
>  Components: JMS
>Affects Versions: 3.1.7
>Reporter: Nikolay Boklaschuk
>
> When using Websphere MQ resource adapter
> Inbound one-way service does not uses XA transactions.
> This is because WMQ adapter decides to use XA transaction when creates jms 
> connection, but connection opened in JMSDestination, and transaction started 
> in PollingMessageListnerContainer after connection created.
> Futhermore WMQ adapter holds only one session per connection.
> I have patched XAPoller to hold connection for each thread, it works, but may 
> be there are better way to provide support for WMQ adapter? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CXF-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter

2016-10-21 Thread JIRA

[ 
https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594356#comment-15594356
 ] 

Rainer Müller commented on CXF-7023:


Your last commit (7301fd2) breaks a test in the transport-jms testsuite.
In SoapJmsSpecTest, line 109
{{Assert.assertEquals(null, responseHeader.getSOAPJMSSOAPAction());}}
should be
{{Assert.assertEquals("\"test\"", responseHeader.getSOAPJMSSOAPAction());}}

Could you please fix this to increase the probability to get the pull request 
merged?

> SOAP over JMS transport does not use XA transactions with Websphere MQ 
> resource adapter
> ---
>
> Key: CXF-7023
> URL: https://issues.apache.org/jira/browse/CXF-7023
> Project: CXF
>  Issue Type: Bug
>  Components: JMS
>Affects Versions: 3.1.7
>Reporter: Nikolay Boklaschuk
>
> When using Websphere MQ resource adapter
> Inbound one-way service does not uses XA transactions.
> This is because WMQ adapter decides to use XA transaction when creates jms 
> connection, but connection opened in JMSDestination, and transaction started 
> in PollingMessageListnerContainer after connection created.
> Futhermore WMQ adapter holds only one session per connection.
> I have patched XAPoller to hold connection for each thread, it works, but may 
> be there are better way to provide support for WMQ adapter? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CXF-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter

2016-10-21 Thread Nikolay Boklaschuk (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594400#comment-15594400
 ] 

Nikolay Boklaschuk commented on CXF-7023:
-

Thanks, Rainer.
Done.

> SOAP over JMS transport does not use XA transactions with Websphere MQ 
> resource adapter
> ---
>
> Key: CXF-7023
> URL: https://issues.apache.org/jira/browse/CXF-7023
> Project: CXF
>  Issue Type: Bug
>  Components: JMS
>Affects Versions: 3.1.7
>Reporter: Nikolay Boklaschuk
>
> When using Websphere MQ resource adapter
> Inbound one-way service does not uses XA transactions.
> This is because WMQ adapter decides to use XA transaction when creates jms 
> connection, but connection opened in JMSDestination, and transaction started 
> in PollingMessageListnerContainer after connection created.
> Futhermore WMQ adapter holds only one session per connection.
> I have patched XAPoller to hold connection for each thread, it works, but may 
> be there are better way to provide support for WMQ adapter? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (CXF-7096) Server side memory leaking if clients do not send CloseSequence

2016-10-21 Thread Sergey Beryozkin (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Beryozkin reassigned CXF-7096:
-

Assignee: Sergey Beryozkin

> Server side memory leaking if clients do not send CloseSequence
> ---
>
> Key: CXF-7096
> URL: https://issues.apache.org/jira/browse/CXF-7096
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.1.6, 3.1.7, 3.1.8
> Environment: Windows 7, CXF3.1.6, CXF3.1.7 and CXF3.1.8, Visual 
> Studio 12 client, Java 7, JBoss EAP 6
>Reporter: Andy Zhang
>Assignee: Sergey Beryozkin
>Priority: Blocker
>  Labels: features
> Fix For: 3.1.9
>
>
> I have a dot net client that invokes a RM web service many times. It does not 
> send CloseSequence at the end. The server side tries to terminate the 
> sequence based on inactivityTimeout in the WSDL. But it does not seem to 
> cleanup the sequence completely since the memory usage gets larger and larger 
> and eventually the server will run out of memory. java.lang.OutOfMemoryError: 
> Java heap space



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CXF-7096) Server side memory leaking if clients do not send CloseSequence

2016-10-21 Thread Sergey Beryozkin (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594519#comment-15594519
 ] 

Sergey Beryozkin commented on CXF-7096:
---

Andy, Aki may be unavailable so I'd also recommend you to consider working on 
the patch, if you'd like to depend on the CXF WS-RM code then it would be 
worthwhile investing the time and understanding how it works :-)

 

> Server side memory leaking if clients do not send CloseSequence
> ---
>
> Key: CXF-7096
> URL: https://issues.apache.org/jira/browse/CXF-7096
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.1.6, 3.1.7, 3.1.8
> Environment: Windows 7, CXF3.1.6, CXF3.1.7 and CXF3.1.8, Visual 
> Studio 12 client, Java 7, JBoss EAP 6
>Reporter: Andy Zhang
>Assignee: Sergey Beryozkin
>Priority: Blocker
>  Labels: features
> Fix For: 3.1.9
>
>
> I have a dot net client that invokes a RM web service many times. It does not 
> send CloseSequence at the end. The server side tries to terminate the 
> sequence based on inactivityTimeout in the WSDL. But it does not seem to 
> cleanup the sequence completely since the memory usage gets larger and larger 
> and eventually the server will run out of memory. java.lang.OutOfMemoryError: 
> Java heap space



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (CXF-7096) Server side memory leaking if clients do not send CloseSequence

2016-10-21 Thread Sergey Beryozkin (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Beryozkin reassigned CXF-7096:
-

Assignee: (was: Sergey Beryozkin)

> Server side memory leaking if clients do not send CloseSequence
> ---
>
> Key: CXF-7096
> URL: https://issues.apache.org/jira/browse/CXF-7096
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.1.6, 3.1.7, 3.1.8
> Environment: Windows 7, CXF3.1.6, CXF3.1.7 and CXF3.1.8, Visual 
> Studio 12 client, Java 7, JBoss EAP 6
>Reporter: Andy Zhang
>Priority: Blocker
>  Labels: features
> Fix For: 3.1.9
>
>
> I have a dot net client that invokes a RM web service many times. It does not 
> send CloseSequence at the end. The server side tries to terminate the 
> sequence based on inactivityTimeout in the WSDL. But it does not seem to 
> cleanup the sequence completely since the memory usage gets larger and larger 
> and eventually the server will run out of memory. java.lang.OutOfMemoryError: 
> Java heap space



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CXF-6986) Don't require an application class if using CDI

2016-10-21 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595084#comment-15595084
 ] 

ASF GitHub Bot commented on CXF-6986:
-

Github user reta commented on a diff in the pull request:

https://github.com/apache/cxf/pull/182#discussion_r84469141
  
--- Diff: integration/cdi/src/main/java/org/apache/cxf/cdi/CdiBusBean.java 
---
@@ -61,44 +53,14 @@ public String getName() {
 return CXF;
 }
 
-@SuppressWarnings("serial")
-@Override
-public Set< Annotation > getQualifiers() {
-Set qualifiers = new HashSet();
-qualifiers.add(new AnnotationLiteral< Default >() { });
-qualifiers.add(new AnnotationLiteral< Any >() { });
-return qualifiers;
-}
-
 @Override
 public Set getTypes() {
-final Set< Type > types = new HashSet< Type >();
+final Set< Type > types = super.getTypes();
--- End diff --

`final Set< Type > types = new HashSet<>(super.getTypes());`, it is just 
safer 


> 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] [Commented] (CXF-6986) Don't require an application class if using CDI

2016-10-21 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595089#comment-15595089
 ] 

ASF GitHub Bot commented on CXF-6986:
-

Github user reta commented on the issue:

https://github.com/apache/cxf/pull/182
  
@johnament I like it more, very minor comment, otherwise good to be merged, 
@sberyozkin what do you think?


> 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] [Commented] (CXF-6986) Don't require an application class if using CDI

2016-10-21 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595173#comment-15595173
 ] 

ASF GitHub Bot commented on CXF-6986:
-

Github user sberyozkin commented on the issue:

https://github.com/apache/cxf/pull/182
  
Hey Andriy, IMHO it is ready to be merged, re your last comment, 
super.getTypes() returns a new set, John just pushed this code to the 
superclass. thanks


> 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] [Commented] (CXF-6986) Don't require an application class if using CDI

2016-10-21 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595267#comment-15595267
 ] 

ASF GitHub Bot commented on CXF-6986:
-

Github user johnament commented on the issue:

https://github.com/apache/cxf/pull/182
  
I'm fine either way.  If its not merged when I get back to this code this 
evening, I'll make the change.


> 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] [Commented] (CXF-6986) Don't require an application class if using CDI

2016-10-21 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595373#comment-15595373
 ] 

ASF GitHub Bot commented on CXF-6986:
-

Github user asfgit closed the pull request at:

https://github.com/apache/cxf/pull/182


> 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] [Resolved] (CXF-6986) Don't require an application class if using CDI

2016-10-21 Thread Sergey Beryozkin (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Beryozkin resolved CXF-6986.
---
   Resolution: Fixed
 Assignee: Sergey Beryozkin
Fix Version/s: 3.1.9
   3.2.0

Thanks for the patch

> 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
>Assignee: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.9
>
>
> 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] [Commented] (CXF-6986) Don't require an application class if using CDI

2016-10-21 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595391#comment-15595391
 ] 

ASF GitHub Bot commented on CXF-6986:
-

Github user reta commented on the issue:

https://github.com/apache/cxf/pull/182
  
:+1:  wanted to merge but you did it first :) Thanks @johnament @sberyozkin 
!


> 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
>Assignee: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.9
>
>
> 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] [Commented] (CXF-6986) Don't require an application class if using CDI

2016-10-21 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595394#comment-15595394
 ] 

ASF GitHub Bot commented on CXF-6986:
-

Github user sberyozkin commented on the issue:

https://github.com/apache/cxf/pull/182
  
oops :-), Sorry Andriy :-)


> 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
>Assignee: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.9
>
>
> 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] [Commented] (CXF-6986) Don't require an application class if using CDI

2016-10-21 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595382#comment-15595382
 ] 

ASF GitHub Bot commented on CXF-6986:
-

Github user sberyozkin commented on the issue:

https://github.com/apache/cxf/pull/182
  
Hi Guys, I've just applied, double checked that the super class creates a 
new set so that should be safe, Andriy, hope you are OK, we can always tweak 
few things in the source too :-).


> 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] [Resolved] (CXF-7091) JAXRSBeanValidationOutInterceptor fails to validate Response entity on the 2nd try

2016-10-21 Thread Sergey Beryozkin (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-7091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Beryozkin resolved CXF-7091.
---
Resolution: Fixed

> JAXRSBeanValidationOutInterceptor fails to validate Response entity on the 
> 2nd try
> --
>
> Key: CXF-7091
> URL: https://issues.apache.org/jira/browse/CXF-7091
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.9, 3.0.12
>
>
> JAX-RS out filters can be run twice if the exception thrown from these 
> filters during the 1st run has been mapped.  
> JAXRSBeanValidationOutInterceptor fails to pass the mapped Response to the 
> abstract validation code. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CXF-7092) Swagger2Feature tries to resolve swagger-ui resources with api-docs

2016-10-21 Thread Sergey Beryozkin (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-7092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Beryozkin resolved CXF-7092.
---
   Resolution: Fixed
 Assignee: Sergey Beryozkin
Fix Version/s: 3.1.9

> Swagger2Feature tries to resolve swagger-ui resources with api-docs
> ---
>
> Key: CXF-7092
> URL: https://issues.apache.org/jira/browse/CXF-7092
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.7
> Environment: Spring Boot 1.4.1
> Swagger 2.2.2
>Reporter: Dennis Kieselhorst
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.2.0, 3.1.9
>
> Attachments: cxf7092.png
>
>
> Add Swagger2Feature for customization to the class annotated with 
> @SpringBootApplication, e.g.:
> {code:java}
>@Bean
>public Swagger2Feature swagger2Feature() {
>   Swagger2Feature swagger2Feature = new Swagger2Feature();
>   swagger2Feature.setPrettyPrint(true);
>   swagger2Feature.setContact("person who knows the API");
>   return swagger2Feature;
>}
> {code}
> Open url for swagger UI in browser will fail with:
> {noformat}
> Caused by: java.io.FileNotFoundException: JAR entry 
> META-INF/resources/webjars/swagger-ui/2.2.2/api-docs/lib/swagger-oauth.js not 
> found in /work/m2repository/org/webjars/swagger-ui/2.2.2/swagger-ui-2.2.2.jar
>   at 
> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:142)
>   at 
> sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
>   at java.net.URL.openStream(URL.java:1045)
>   at 
> org.apache.cxf.jaxrs.swagger.Swagger2Feature$SwaggerUIService.getResource(Swagger2Feature.java:298)
>   ... 102 more
> {noformat}
> Please note that it works correctly when the Swagger2Feature is 
> auto-configured without customizations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CXF-7092) Swagger2Feature tries to resolve swagger-ui resources with api-docs

2016-10-21 Thread Sergey Beryozkin (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-7092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15596104#comment-15596104
 ] 

Sergey Beryozkin commented on CXF-7092:
---

I've ended up adding a warning if the providers with the same class name have 
been detected.
In most cases it is a sign of the configuration/setup issue, but besides that, 
even though @Component classes are only detected if they have been explicitly 
enabled via @Bean or in the application context resources, I've been thinking 
for a while to also support the class path scanning of @Component classes, 
Spring scanner does support it but it has not just been integrated into CXF and 
in that case it will be hard to decide what takes the priority if we can have 
say a JAX-RS provider which is also annotated as @Component.
IMHO doing the warning is reasonable at this stage...
thanks  

> Swagger2Feature tries to resolve swagger-ui resources with api-docs
> ---
>
> Key: CXF-7092
> URL: https://issues.apache.org/jira/browse/CXF-7092
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.7
> Environment: Spring Boot 1.4.1
> Swagger 2.2.2
>Reporter: Dennis Kieselhorst
>Priority: Minor
> Fix For: 3.2.0, 3.1.9
>
> Attachments: cxf7092.png
>
>
> Add Swagger2Feature for customization to the class annotated with 
> @SpringBootApplication, e.g.:
> {code:java}
>@Bean
>public Swagger2Feature swagger2Feature() {
>   Swagger2Feature swagger2Feature = new Swagger2Feature();
>   swagger2Feature.setPrettyPrint(true);
>   swagger2Feature.setContact("person who knows the API");
>   return swagger2Feature;
>}
> {code}
> Open url for swagger UI in browser will fail with:
> {noformat}
> Caused by: java.io.FileNotFoundException: JAR entry 
> META-INF/resources/webjars/swagger-ui/2.2.2/api-docs/lib/swagger-oauth.js not 
> found in /work/m2repository/org/webjars/swagger-ui/2.2.2/swagger-ui-2.2.2.jar
>   at 
> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:142)
>   at 
> sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
>   at java.net.URL.openStream(URL.java:1045)
>   at 
> org.apache.cxf.jaxrs.swagger.Swagger2Feature$SwaggerUIService.getResource(Swagger2Feature.java:298)
>   ... 102 more
> {noformat}
> Please note that it works correctly when the Swagger2Feature is 
> auto-configured without customizations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CXF-7092) Swagger2Feature tries to resolve swagger-ui resources with api-docs

2016-10-21 Thread Dennis Kieselhorst (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-7092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15596156#comment-15596156
 ] 

Dennis Kieselhorst commented on CXF-7092:
-

fine for me, a warning would have pointed me in the right direction...thx!

> Swagger2Feature tries to resolve swagger-ui resources with api-docs
> ---
>
> Key: CXF-7092
> URL: https://issues.apache.org/jira/browse/CXF-7092
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.7
> Environment: Spring Boot 1.4.1
> Swagger 2.2.2
>Reporter: Dennis Kieselhorst
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.2.0, 3.1.9
>
> Attachments: cxf7092.png
>
>
> Add Swagger2Feature for customization to the class annotated with 
> @SpringBootApplication, e.g.:
> {code:java}
>@Bean
>public Swagger2Feature swagger2Feature() {
>   Swagger2Feature swagger2Feature = new Swagger2Feature();
>   swagger2Feature.setPrettyPrint(true);
>   swagger2Feature.setContact("person who knows the API");
>   return swagger2Feature;
>}
> {code}
> Open url for swagger UI in browser will fail with:
> {noformat}
> Caused by: java.io.FileNotFoundException: JAR entry 
> META-INF/resources/webjars/swagger-ui/2.2.2/api-docs/lib/swagger-oauth.js not 
> found in /work/m2repository/org/webjars/swagger-ui/2.2.2/swagger-ui-2.2.2.jar
>   at 
> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:142)
>   at 
> sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
>   at java.net.URL.openStream(URL.java:1045)
>   at 
> org.apache.cxf.jaxrs.swagger.Swagger2Feature$SwaggerUIService.getResource(Swagger2Feature.java:298)
>   ... 102 more
> {noformat}
> Please note that it works correctly when the Swagger2Feature is 
> auto-configured without customizations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CXF-7096) Server side memory leaking if clients do not send CloseSequence

2016-10-21 Thread Andy Zhang (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15597031#comment-15597031
 ] 

Andy Zhang commented on CXF-7096:
-

[~sergeyb] Hi Sergey, I will take a look at the implementation. It'll 
definitely be very helpful if someone gives me a brief description of the 
design or a document. Thanks for the response.

> Server side memory leaking if clients do not send CloseSequence
> ---
>
> Key: CXF-7096
> URL: https://issues.apache.org/jira/browse/CXF-7096
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.1.6, 3.1.7, 3.1.8
> Environment: Windows 7, CXF3.1.6, CXF3.1.7 and CXF3.1.8, Visual 
> Studio 12 client, Java 7, JBoss EAP 6
>Reporter: Andy Zhang
>Priority: Blocker
>  Labels: features
> Fix For: 3.1.9
>
>
> I have a dot net client that invokes a RM web service many times. It does not 
> send CloseSequence at the end. The server side tries to terminate the 
> sequence based on inactivityTimeout in the WSDL. But it does not seem to 
> cleanup the sequence completely since the memory usage gets larger and larger 
> and eventually the server will run out of memory. java.lang.OutOfMemoryError: 
> Java heap space



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)