July 2018 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-4120) SOAP logging stopped working with WildFly 12 / JBossWS 5.2.0.Final (Apache CXF 3.2.2)

by George Turner (JIRA)

[ https://issues.jboss.org/browse/JBWS-4120?page=com.atlassian.jira.plugin.... ] George Turner commented on JBWS-4120: ------------------------------------- Nevermind, I figured it out from looking at nightly build of WF 14 > SOAP logging stopped working with WildFly 12 / JBossWS 5.2.0.Final (Apache CXF 3.2.2) > ------------------------------------------------------------------------------------- > > Key: JBWS-4120 > URL: https://issues.jboss.org/browse/JBWS-4120 > Project: JBoss Web Services > Issue Type: Bug > Affects Versions: jbossws-cxf-5.2.0.Final > Reporter: Rostislav Svoboda > Assignee: Petr Jurak > Priority: Critical > Fix For: jbossws-cxf-5.2.2.Final > > > SOAP logging stopped working with WildFly 12 / JBossWS 5.2.0.Final (Apache CXF 3.2.2) > This is working with WildFly 11 / JBossWS 5.1.9.Final (Apache CXF 3.1.12) > {code} > wildfly-11.0.0.Final/bin/standalone.sh -Dorg.apache.cxf.logging.enabled=pretty > wildfly-12.0.0.Final/bin/standalone.sh -Dorg.apache.cxf.logging.enabled=pretty > {code} > Seems that logging feature is not activated, I tried also {{org.apache.cxf.logging.enabled=true}}. > It can be related to https://github.com/apache/cxf/commit/54e7c58d5449d5f91879674598fe1b1ee339... changes where logging was refactored and new LoggingBusLifecycleListener was introduced. > I used https://github.com/wildfly/quickstart/tree/master/helloworld-ws app ++ SoapUI for quick check. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4120) SOAP logging stopped working with WildFly 12 / JBossWS 5.2.0.Final (Apache CXF 3.2.2)

by George Turner (JIRA)

[ https://issues.jboss.org/browse/JBWS-4120?page=com.atlassian.jira.plugin.... ] George Turner commented on JBWS-4120: ------------------------------------- I am looking for HOW to patch this in a current system, this is a critical loss of functionality. We upgraded to WF13 and just found this problem. Is there a patch or configuration change to get the system property functional again? > SOAP logging stopped working with WildFly 12 / JBossWS 5.2.0.Final (Apache CXF 3.2.2) > ------------------------------------------------------------------------------------- > > Key: JBWS-4120 > URL: https://issues.jboss.org/browse/JBWS-4120 > Project: JBoss Web Services > Issue Type: Bug > Affects Versions: jbossws-cxf-5.2.0.Final > Reporter: Rostislav Svoboda > Assignee: Petr Jurak > Priority: Critical > Fix For: jbossws-cxf-5.2.2.Final > > > SOAP logging stopped working with WildFly 12 / JBossWS 5.2.0.Final (Apache CXF 3.2.2) > This is working with WildFly 11 / JBossWS 5.1.9.Final (Apache CXF 3.1.12) > {code} > wildfly-11.0.0.Final/bin/standalone.sh -Dorg.apache.cxf.logging.enabled=pretty > wildfly-12.0.0.Final/bin/standalone.sh -Dorg.apache.cxf.logging.enabled=pretty > {code} > Seems that logging feature is not activated, I tried also {{org.apache.cxf.logging.enabled=true}}. > It can be related to https://github.com/apache/cxf/commit/54e7c58d5449d5f91879674598fe1b1ee339... changes where logging was refactored and new LoggingBusLifecycleListener was introduced. > I used https://github.com/wildfly/quickstart/tree/master/helloworld-ws app ++ SoapUI for quick check. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4019) Multiple reads of SOAP message through the context

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-4019?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-4019: ---------------------------------- Fix Version/s: (was: jbossws-cxf-5.2.2.Final) > Multiple reads of SOAP message through the context > -------------------------------------------------- > > Key: JBWS-4019 > URL: https://issues.jboss.org/browse/JBWS-4019 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: R Searls > > See https://developer.jboss.org/message/961026#961026 > Question is if this is because of a CXF impl choice and if there's any actual requirement about this in JAX-WS spec. Also note there're attachments involved here, so the problem could only be related to that (and to streaming...) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4019) Multiple reads of SOAP message through the context

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-4019?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-4019: -------------------------------- This is not a bug. It is the user's miss definition of a lambda. User code {code:java} DataHandler dh = (DataHandler) attachments .values() .iterator() .next(); {code} The use of .iterator() and .next(); is incorrect. The code should be something like this {code:java} attachments.values() .foreach(new Consumer<DataHandler>() { public void accept(DataHandler s) { System.out.println(s); } }); {code} > Multiple reads of SOAP message through the context > -------------------------------------------------- > > Key: JBWS-4019 > URL: https://issues.jboss.org/browse/JBWS-4019 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: R Searls > Fix For: jbossws-cxf-5.2.2.Final > > > See https://developer.jboss.org/message/961026#961026 > Question is if this is because of a CXF impl choice and if there's any actual requirement about this in JAX-WS spec. Also note there're attachments involved here, so the problem could only be related to that (and to streaming...) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4080) Unpublishing WSDL files takes very long (race condition?)

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-4080?page=com.atlassian.jira.plugin.... ] R Searls updated JBWS-4080: --------------------------- Assignee: (was: R Searls) > Unpublishing WSDL files takes very long (race condition?) > --------------------------------------------------------- > > Key: JBWS-4080 > URL: https://issues.jboss.org/browse/JBWS-4080 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-5.1.5.Final, jbossws-cxf-5.1.6.Final, jbossws-cxf-5.1.7.Final, jbossws-cxf-5.1.8.Final, jbossws-cxf-5.1.9.Final > Environment: Windows, Java 8, Wildfly 10.1 > Reporter: Stefan Moebius > Fix For: jbossws-cxf-5.2.2.Final > > > The change done for JBWS-3992 causes shutdown of Wildfly 10.1 to take much longer, causing timeouts in the Windows service manager. > The problem appears to be this: > There is a pool of “MSC service threads”. These threads are responsible among other things for the publishing and also the unpublishing of web services, which involves the creation and also the deletion of WSDL files, using WSDLFilePublisher. These threads operate on deployment units, which means the JARs inside an EAR. > The WSDL files are published in this structure: > data/wsdl/Bar.ear/<Foo>.jar/, with one folder for each JAR that has WS. > In jbossws-cxf-5.1.4, each of these threads would delete the files and the folder for one deployment unit, i.e. one JAR. The impact was that the root folder data/wsdl/Bar.ear/ would remain, which was reported as a JBWS-3992 and fixed in 5.1.5. > The fixed, however, causes each thread to now traverse to the root deployment unit (Bar.ear) and recursively delete all files under data/wsdl/Bar.ear and the folder itself. The problem is that this causes multiple threads to attempt to delete the same tree of files in parallel, at least on Windows causing this to take ages. > The change: > [https://github.com/jbossws/jbossws-cxf/commit/162c9e4d44f9832de6b6147b3b9...] > As a workaround, we've downgraded to 5.1.4, which made the issue go away. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 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 updated JBWS-4087: --------------------------- Assignee: (was: R Searls) > 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 > Labels: JBossWS > Fix For: jbossws-cxf-5.2.2.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.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4105) Move to latest CXF message logging mechanism

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-4105?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-4105: -------------------------------- This has been completed. > Move to latest CXF message logging mechanism > -------------------------------------------- > > Key: JBWS-4105 > URL: https://issues.jboss.org/browse/JBWS-4105 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: R Searls > Fix For: jbossws-cxf-5.2.2.Final > > > Apache CXF 3.2 has deprecated the message logging mechanism used so far, in favor of a new one. See https://github.com/apache/cxf/commit/428bbe90e4189e70df9a6a450a10320c8be6... and http://cxf.apache.org/docs/message-logging.html . > We should start relying on the new mechanism. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4084) bug in jboss-module cause of 2 testcase failures

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-4084?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-4084: -------------------------------- This is resolved. > bug in jboss-module cause of 2 testcase failures > ------------------------------------------------ > > Key: JBWS-4084 > URL: https://issues.jboss.org/browse/JBWS-4084 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-5.2.0.Final > Reporter: R Searls > Assignee: R Searls > Fix For: jbossws-cxf-5.2.2.Final > > > Running 2 existing test cases in wildlfy-10.0.0+ with security fails do to a bug in > jboss-module. Our 2 test cases uncovered this issue. > tests > * org.jboss.test.ws.jaxws.cxf.jbws3713.ClientBusStrategyTestCase > * org.jboss.test.ws.jaxws.jbws1666.JBWS1666TestCase > Both of these test generate a cmd that uses jboss-module to execuate a client jar. > The generated command looks like this. > {code:java} > /usr/java/jdk1.8.0_72/jre/bin/java \ > -Djavax.xml.ws.spi.Provider=org.jboss.wsf.stack.cxf.client.ProviderImpl \ > -Dlog4j.output.dir=/home/rsearls/j1/jbws/jbossws-cxf/modules/testsuite/cxf-tests/target \ > -Dorg.jboss.ws.cxf.jaxws-client.bus.strategy=NEW_BUS \ > -Djava.security.policy=/home/rsearls/j1/jbws/jbossws-cxf/modules/testsuite/cxf-tests/target/test-resources/jaxws/cxf/jbws3713/WEB-INF/jbws3713-client-security.policy \ > -jar /home/rsearls/j1/wfly10/wildfly/build/target/wildfly-10.0.0.Final/jboss-modules.jar \ > -mp /home/rsearls/j1/wfly10/wildfly/build/target/wildfly-10.0.0.Final/modules \ > -secmgr \ > -jar /home/rsearls/j1/jbws/jbossws-cxf/modules/testsuite/cxf-tests/target/test-libs/jaxws-cxf-jbws3713-client.jar \ > http://127.0.0.1:8080/jaxws-cxf-jbws3713//HelloService?wsdl 4 5 > {code} > In addition to the fix in jboss-module our code needs 2 changes. One a security.policy > file must be passed on the cmd-line. Two the -secmgr flag must be provided just after the > jboss-module.jar declaration. > A bug has been filed against jboss-module and linked here. > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4123) SAMLTokenPrincipal is not propagated to EJB

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-4123?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-4123: ---------------------------------- Assignee: Jim Ma > SAMLTokenPrincipal is not propagated to EJB > -------------------------------------------- > > Key: JBWS-4123 > URL: https://issues.jboss.org/browse/JBWS-4123 > Project: JBoss Web Services > Issue Type: Feature Request > Components: jbossws-cxf > Affects Versions: jbossws-cxf-5.2.1.Final > Reporter: Viral Gohel > Assignee: Jim Ma > Priority: Critical > Fix For: jbossws-cxf-5.2.2.Final > > Attachments: redhat-saml-interceptor.zip, redhat.zip > > > SAML Token Principal can be propagated to the EJB layer, which right now we are not seeing. > Here are the results we see, > 16:23:43,521 INFO [stdout] (default task-9) class org.apache.wss4j.common.principal.SAMLTokenPrincipalImpl > 16:23:43,522 INFO [stdout] (default task-9) subjectName > 16:23:58,617 INFO [stdout] (default task-9) class org.jboss.security.SimplePrincipal > 16:24:15,751 INFO [stdout] (default task-9) anonymous > CXF code isn't creating the Subject for the security context in a way that the EAP, or JEE containers, can understand. For UsernameToken type authentication this is done through org.jboss.wsf.stack.cxf.security.authentication.SubjectCreatingInterceptor, but I'm unsure if this applies to SAML tokens. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

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

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-4064?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-4064: --------------------------------------- [~rnetuka], the fix seems to have been included in cxf 3.2.5, which is pulled by current jbossws, so I guess this can be marked as solved, right? > 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: Radovan Netuka > Fix For: jbossws-cxf-5.2.2.Final > > Attachments: mtomExample.war > > > Check issue, https://issues.apache.org/jira/browse/CXF-7317 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 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 July 2018