April 2019 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-4064) Non-URL encoded Content-Id href does not seem be serialized by CXF's AttachmentSerializer

by Dennis Kieselhorst (Jira)

[ https://issues.jboss.org/browse/JBWS-4064?page=com.atlassian.jira.plugin.... ] Dennis Kieselhorst commented on JBWS-4064: ------------------------------------------ Well it was fixed for 3.2.5 but we had to revert it for 3.2.7 as commented above. See also https://issues.apache.org/jira/browse/CXF-7857 > Non-URL encoded Content-Id href does not seem be serialized by CXF's AttachmentSerializer > ----------------------------------------------------------------------------------------- > > Key: JBWS-4064 > URL: https://issues.jboss.org/browse/JBWS-4064 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-5.1.8.Final > Reporter: Viral Gohel > Assignee: Petr Jurak > Priority: Major > Fix For: jbossws-cxf-5.2.2.Final > > Attachments: mtomExample.war, mtomLog.txt > > > Check issue, https://issues.apache.org/jira/browse/CXF-7317 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4088) Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF

by Jim Ma (Jira)

[ https://issues.jboss.org/browse/JBWS-4088?page=com.atlassian.jira.plugin.... ] Jim Ma edited comment on JBWS-4088 at 4/18/19 10:34 PM: -------------------------------------------------------- >From Alessio, we only need add some case for this jira. was (Author: jim.ma): >From Alessio, we only need to add some case for this jira. > Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF > --------------------------------------------------------------------------------------------- > > Key: JBWS-4088 > URL: https://issues.jboss.org/browse/JBWS-4088 > Project: JBoss Web Services > Issue Type: Enhancement > Reporter: David Boeren > Priority: Minor > > I think the explanation comes from the way the response context is kept within the ClientImpl. The ClientImpl has the following: > protected Map<Thread, Map<String, Object>> responseContext = Collections.synchronizedMap(new WeakHashMap<Thread, Map<String, Object>>()); > and the getResponseContext() is implemented this way: > public Map<String, Object> getResponseContext() { > if (!responseContext.containsKey(Thread.currentThread())) { > responseContext.put(Thread.currentThread(), new HashMap<String, Object>()); > } > return responseContext.get(Thread.currentThread()); > } > Now, in the customer case, I believe the threads that serve as keys to the weak hashmap are never GCed (perhaps because they simply come from a thread pool that reuses them) and I don't see the response context being explicitly cleaned up in cxf except when the clientimpl is destroyed (which does not happen often in customer case as the clients are pooled). > I would suggest to try explicitly cleaning up the response message context contents. > The customer has successfully done this using this on their client side: > dispatcher.getResponseContext().remove("org.apache.cxf.staxutils.W3CDOMStreamWriter"); > Is it possible to have this fix added to JBossWS as an enhancement? Full details are on the case link. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4088) Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF

by Jim Ma (Jira)

[ https://issues.jboss.org/browse/JBWS-4088?page=com.atlassian.jira.plugin.... ] Jim Ma commented on JBWS-4088: ------------------------------ >From Alessio, we only need to add some case for this jira. > Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF > --------------------------------------------------------------------------------------------- > > Key: JBWS-4088 > URL: https://issues.jboss.org/browse/JBWS-4088 > Project: JBoss Web Services > Issue Type: Enhancement > Reporter: David Boeren > Priority: Minor > > I think the explanation comes from the way the response context is kept within the ClientImpl. The ClientImpl has the following: > protected Map<Thread, Map<String, Object>> responseContext = Collections.synchronizedMap(new WeakHashMap<Thread, Map<String, Object>>()); > and the getResponseContext() is implemented this way: > public Map<String, Object> getResponseContext() { > if (!responseContext.containsKey(Thread.currentThread())) { > responseContext.put(Thread.currentThread(), new HashMap<String, Object>()); > } > return responseContext.get(Thread.currentThread()); > } > Now, in the customer case, I believe the threads that serve as keys to the weak hashmap are never GCed (perhaps because they simply come from a thread pool that reuses them) and I don't see the response context being explicitly cleaned up in cxf except when the clientimpl is destroyed (which does not happen often in customer case as the clients are pooled). > I would suggest to try explicitly cleaning up the response message context contents. > The customer has successfully done this using this on their client side: > dispatcher.getResponseContext().remove("org.apache.cxf.staxutils.W3CDOMStreamWriter"); > Is it possible to have this fix added to JBossWS as an enhancement? Full details are on the case link. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4088) Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF

by Jim Ma (Jira)

[ https://issues.jboss.org/browse/JBWS-4088?page=com.atlassian.jira.plugin.... ] Jim Ma updated JBWS-4088: ------------------------- Fix Version/s: (was: jbossws-cxf-5.3.0.Final) > Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF > --------------------------------------------------------------------------------------------- > > Key: JBWS-4088 > URL: https://issues.jboss.org/browse/JBWS-4088 > Project: JBoss Web Services > Issue Type: Enhancement > Reporter: David Boeren > Priority: Minor > > I think the explanation comes from the way the response context is kept within the ClientImpl. The ClientImpl has the following: > protected Map<Thread, Map<String, Object>> responseContext = Collections.synchronizedMap(new WeakHashMap<Thread, Map<String, Object>>()); > and the getResponseContext() is implemented this way: > public Map<String, Object> getResponseContext() { > if (!responseContext.containsKey(Thread.currentThread())) { > responseContext.put(Thread.currentThread(), new HashMap<String, Object>()); > } > return responseContext.get(Thread.currentThread()); > } > Now, in the customer case, I believe the threads that serve as keys to the weak hashmap are never GCed (perhaps because they simply come from a thread pool that reuses them) and I don't see the response context being explicitly cleaned up in cxf except when the clientimpl is destroyed (which does not happen often in customer case as the clients are pooled). > I would suggest to try explicitly cleaning up the response message context contents. > The customer has successfully done this using this on their client side: > dispatcher.getResponseContext().remove("org.apache.cxf.staxutils.W3CDOMStreamWriter"); > Is it possible to have this fix added to JBossWS as an enhancement? Full details are on the case link. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4167) jdk-11 updates required to project jaxws-undertow-httpspi

by Jim Ma (Jira)

[ https://issues.jboss.org/browse/JBWS-4167?page=com.atlassian.jira.plugin.... ] Jim Ma updated JBWS-4167: ------------------------- Fix Version/s: jbossws-cxf-5.3.0.Final > jdk-11 updates required to project jaxws-undertow-httpspi > --------------------------------------------------------- > > Key: JBWS-4167 > URL: https://issues.jboss.org/browse/JBWS-4167 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jaxws-undertow-httpspi-1.0.2.final > Reporter: r searls > Assignee: r searls > Priority: Major > Fix For: jbossws-cxf-5.3.0.Final > > > Maven dependences need to be added to support build with jdk-11 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4047) Enable / disable WS statistics does not reset counters

by Jim Ma (Jira)

[ https://issues.jboss.org/browse/JBWS-4047?page=com.atlassian.jira.plugin.... ] Jim Ma updated JBWS-4047: ------------------------- Fix Version/s: (was: jbossws-cxf-5.3.0.Final) > Enable / disable WS statistics does not reset counters > ------------------------------------------------------ > > Key: JBWS-4047 > URL: https://issues.jboss.org/browse/JBWS-4047 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-5.1.5.Final > Reporter: Romain Pelisse > Assignee: Alessio Soldano > Priority: Major > > Enable / disable statistics does not reset counters. > Right now when I enable stats - do some soap requests - disable stats - enable stats again - counters are not on 0 but continue when they were before disabling stats. > I think reset of counters should be done once stats are disabled. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4154) jbossws-cxf-client depends on both jboss-jaxws-api_2.2_spec and jboss-jaxws-api_2.3_spec

by r searls (Jira)

[ https://issues.jboss.org/browse/JBWS-4154?page=com.atlassian.jira.plugin.... ] r searls commented on JBWS-4154: -------------------------------- Yes this is resolved. > jbossws-cxf-client depends on both jboss-jaxws-api_2.2_spec and jboss-jaxws-api_2.3_spec > ---------------------------------------------------------------------------------------- > > Key: JBWS-4154 > URL: https://issues.jboss.org/browse/JBWS-4154 > Project: JBoss Web Services > Issue Type: Bug > Affects Versions: jbossws-cxf-5.2.4.Final > Reporter: Jan Blizňák > Assignee: r searls > Priority: Major > Fix For: jbossws-cxf-5.3.0.Final > > > dependency:tree goal output shows that jbossws-cxf-client (and transitively other modules too) depends on two versions of JBoss JAX-WS API: > org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:compile > org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.3_spec:jar:1.0.0.Final:compile > The former is brought in by: > {code:java} > +- org.jboss.ws.cxf:jbossws-cxf-transports-undertow:jar:5.2.5-SNAPSHOT:compile > | \- org.jboss.ws.projects:jaxws-undertow-httpspi:jar:1.0.1.Final:compile > | +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:compile > {code} > I guess we should stick to the newer one which would mean add some dependency exclude or update jaxws-undertow-httpspi to new API version stream (I vote for this) > Whole dependency tree at https://github.com/jbliznak/jbws-dependency-trees/blob/jdk11-after/jbossw... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4138) JDK11 illegal reflective access warnings in gmavenplus-plugin

by r searls (Jira)

[ https://issues.jboss.org/browse/JBWS-4138?page=com.atlassian.jira.plugin.... ] r searls commented on JBWS-4138: -------------------------------- Yes this can be rejected > JDK11 illegal reflective access warnings in gmavenplus-plugin > ------------------------------------------------------------- > > Key: JBWS-4138 > URL: https://issues.jboss.org/browse/JBWS-4138 > Project: JBoss Web Services > Issue Type: Bug > Affects Versions: jbossws-cxf-5.2.3.Final > Reporter: Jan Blizňák > Priority: Major > Fix For: jbossws-cxf-5.3.0.Final > > > When running build with JDK11, the execution of gmavenplus-plugin during testsuite prints illegal reflective access warnings > {code:java} > [INFO] --- gmavenplus-plugin:1.5:execute (testsuite-default) @ jbossws-cxf-specific-tests --- > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by org.codehaus.groovy.reflection.CachedClass (file:/home/jbliznak/.m2/repository/org/codehaus/groovy/groovy-all/2.4.15/groovy-all-2.4.15.jar) to method java.lang.Object.finalize() > WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.CachedClass > WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations > WARNING: All illegal access operations will be denied in a future release > {code} > This will become problem in JDK 12 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4087) SOAP address rewrite for wsdl-uri-scheme=https for nested XML schema documents (XSD) referenced by the WSDL behind reverse proxy

by r searls (Jira)

[ https://issues.jboss.org/browse/JBWS-4087?page=com.atlassian.jira.plugin.... ] r searls commented on JBWS-4087: -------------------------------- This can be rejected. > SOAP address rewrite for wsdl-uri-scheme=https for nested XML schema documents (XSD) referenced by the WSDL behind reverse proxy > -------------------------------------------------------------------------------------------------------------------------------- > > Key: JBWS-4087 > URL: https://issues.jboss.org/browse/JBWS-4087 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-5.1.5.Final > Environment: Wildfly 10 > JBossWS 5.1.5-Final > Reporter: Nico Schlebusch > Priority: Major > Labels: JBossWS > Fix For: jbossws-cxf-5.3.0.Final > > > We have Wildfly 10 configured behind NGINX as a reverse proxy for handling the SSL requirements of the web service. Wildfly serves everything as plain HTTP and NGINX handles the HTTPS side of the request. The webservices subsystem is configured to rewrite the uri using https schema. The XSD schema location referenced inside the WSDL is rewritten to use https. However, any other XSD's scheme location that is referenced by the first XSD is not changed to use https. > The URI rewriting for the SOAP address and the schema location of the XSD included in the WSDL works correctly. > {code:xml} > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" > xmlns:tns="http://example.systems/webservices/" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" > xmlns:ns1="http://example.co.za/claim/zmf" attributeFormDefault="unqualified" elementFormDefault="unqualified" > targetNamespace="http://example.systems/webservices/"> > > <xs:import namespace="http://example.co.za/claim/zmf" schemaLocation="https://dev.example.ws:8081/webservices/Claim?xsd=ZietoClaim_2_1.xsd"/> >  > > <wsdl:service name="ClaimService"> > <wsdl:port binding="tns:ClaimServiceSoapBinding" name="ClaimWSPort"> > <soap12:address location="https://dev.example.ws:8081/webservices/ZMF"/> > </wsdl:port> > </wsdl:service> > {code} > The XSD referenced inside the WSDL contains 2 more import statements to import 2 more XSD's. This is however where the problem starts. In the extract below you will notice that the schema location uses http and not https for the other 2 XSD's. > {code:xml} > <?xml version='1.0' encoding='UTF-8'?> > <xsd:schema xmlns:zdt="http://example.co.za/claim/zmf/datatypes" xmlns:zcdt="http://example.co.za/common/datatypes" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://example.co.za/claim/zmf" elementFormDefault="qualified" > targetNamespace="http://example.co.za/claim/zmf"> > > <xsd:import namespace="http://example.co.za/claim/zmf/datatypes" schemaLocation="http://dev.example.ws:8081/webservices/Claim?xsd=zmf_dt_2_1.xsd"/> > <xsd:import namespace="http://example.co.za/common/datatypes" schemaLocation="http://dev.example.ws:8081/webservices/Claim?xsd=zdt_1_2.xsd"/> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4154) jbossws-cxf-client depends on both jboss-jaxws-api_2.2_spec and jboss-jaxws-api_2.3_spec

by Jim Ma (Jira)

[ https://issues.jboss.org/browse/JBWS-4154?page=com.atlassian.jira.plugin.... ] Jim Ma commented on JBWS-4154: ------------------------------ [~rsearls] Can I update it to resolved now ? > jbossws-cxf-client depends on both jboss-jaxws-api_2.2_spec and jboss-jaxws-api_2.3_spec > ---------------------------------------------------------------------------------------- > > Key: JBWS-4154 > URL: https://issues.jboss.org/browse/JBWS-4154 > Project: JBoss Web Services > Issue Type: Bug > Affects Versions: jbossws-cxf-5.2.4.Final > Reporter: Jan Blizňák > Assignee: r searls > Priority: Major > Fix For: jbossws-cxf-5.3.0.Final > > > dependency:tree goal output shows that jbossws-cxf-client (and transitively other modules too) depends on two versions of JBoss JAX-WS API: > org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:compile > org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.3_spec:jar:1.0.0.Final:compile > The former is brought in by: > {code:java} > +- org.jboss.ws.cxf:jbossws-cxf-transports-undertow:jar:5.2.5-SNAPSHOT:compile > | \- org.jboss.ws.projects:jaxws-undertow-httpspi:jar:1.0.1.Final:compile > | +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:compile > {code} > I guess we should stick to the newer one which would mean add some dependency exclude or update jaxws-undertow-httpspi to new API version stream (I vote for this) > Whole dependency tree at https://github.com/jbliznak/jbws-dependency-trees/blob/jdk11-after/jbossw... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues April 2019