November 2017 - jbossws-issues - Jboss List Archives

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

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-4080?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-4080: ---------------------------------- Fix Version/s: jbossws-cxf-5.2.1.Final (was: jbossws-cxf-5.2.0.Final) > 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 > Assignee: R Searls > Fix For: jbossws-cxf-5.2.1.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-4080) Unpublishing WSDL files takes very long (race condition?)

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-4080?page=com.atlassian.jira.plugin.... ] Alessio Soldano reopened JBWS-4080: ----------------------------------- I've reverted the fix as it can lead to security issues. I'm adding details to the PR in few minutes. > 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 > Assignee: R Searls > Fix For: jbossws-cxf-5.2.0.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-4080) Unpublishing WSDL files takes very long (race condition?)

by Stefan Moebius (JIRA)

[ https://issues.jboss.org/browse/JBWS-4080?page=com.atlassian.jira.plugin.... ] Stefan Moebius commented on JBWS-4080: -------------------------------------- The fix by Alessio: https://github.com/jbossws/jbossws-cxf/commit/3a3107d65eb74ea65917009e759... > 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 > Assignee: R Searls > Fix For: jbossws-cxf-5.2.0.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-4075) jaxws-tools-maven-plugin doesn't work on JDK9

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-4075?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-4075: ---------------------------------- Fix Version/s: jbossws-cxf-5.2.1.Final (was: jbossws-cxf-5.2.0.Final) > jaxws-tools-maven-plugin doesn't work on JDK9 > --------------------------------------------- > > Key: JBWS-4075 > URL: https://issues.jboss.org/browse/JBWS-4075 > Project: JBoss Web Services > Issue Type: Task > Components: jaxws-tools-maven-plugin > Affects Versions: jbossws-jaxws-tools-maven-plugin-1.2.0.Beta1 > Reporter: Tomaz Cerar > Assignee: R Searls > Fix For: jbossws-cxf-5.2.1.Final > > > When running on JDK9 plugin fails with CNFE classes from jaxb impl > Maybe fix would be as simple as using jaxb-ri 2.3 dependency explicitly. > {noformat} > Caused by: java.lang.NoClassDefFoundError: com/sun/istack/FinalArrayList > at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:246) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:137) > at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:108) > at javax.xml.bind.ContextFinder.find(ContextFinder.java:286) > at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:412) > at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:375) > at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279) > at org.apache.cxf.tools.wsdlto.core.PluginLoader.init(PluginLoader.java:78) > at org.apache.cxf.tools.wsdlto.core.PluginLoader.<init>(PluginLoader.java:73) > at org.apache.cxf.tools.wsdlto.core.PluginLoader.newInstance(PluginLoader.java:106) > at org.apache.cxf.tools.wsdlto.WSDLToJava.<init>(WSDLToJava.java:48) > at org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl.consume(CXFConsumerImpl.java:308) > at org.jboss.ws.api.tools.WSContractConsumer.consume(WSContractConsumer.java:225) > ... 29 more > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4074) WSDL system property expansion not working on endpoint address

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-4074?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-4074: ---------------------------------- Fix Version/s: jbossws-cxf-5.2.0.Final (was: jbossws-cxf-5.1.10.Final) > WSDL system property expansion not working on endpoint address > -------------------------------------------------------------- > > Key: JBWS-4074 > URL: https://issues.jboss.org/browse/JBWS-4074 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.2.0.Final > > > Deployment of contract first SOAP-over-JMS endpoint with system property references in wsdl soap:address element value fails because the endpoint address is read before the property expansion takes place. -- 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: -------------------------------- 2 more test fall under this category of failure. org.jboss.test.ws.jaxws.samples.serviceref.ServiceRefTestCase.testApplicationClient org.jboss.test.ws.jaxws.samples.webserviceref.WebServiceRefTestCase.testApplicationClient > 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 > > 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-4083) testcases using wsprovide and wsconsume failure with new -secmgr flag

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-4083?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-4083: -------------------------------- adding 2 more tests to jira org.jboss.test.ws.jaxws.jbws2591.JBWS2591TestCase org.jboss.test.ws.jaxws.jbws2593.JBWS2593TestCase > testcases using wsprovide and wsconsume failure with new -secmgr flag > --------------------------------------------------------------------- > > Key: JBWS-4083 > URL: https://issues.jboss.org/browse/JBWS-4083 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-5.2.0.Final > Reporter: R Searls > Assignee: R Searls > > There are 3 tests that use ${WILDFLY_HOME}/bin/wsprovide.sh > * org.jboss.test.ws.jaxws.jbws2528.JBWS2528TestCase > * org.jboss.test.ws.jaxws.jbws2529.JBWS2529TestCase > * org.jboss.test.ws.jaxws.smoke.tools.WSProvideScriptTestCase > and 1 test that uses ${WILDFLY_HOME}/bin/wsconsume.sh > * org.jboss.test.ws.jaxws.smoke.tools.WSConsumeScriptTestCase > When running with wildfly in *secmgr* mode and testing with the *-secmgr *flag the tests fail. > This is because utilities wsprovide and wsconsume in wildfly are broken. They are not handling the (new) -secmgr flag properly. Changes to jboss-module.jar requires this flag. > Jiras have been filed in wildfly 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-4083) testcases using wsprovide and wsconsume failure with new -secmgr flag

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-4083?page=com.atlassian.jira.plugin.... ] R Searls updated JBWS-4083: --------------------------- Assignee: R Searls > testcases using wsprovide and wsconsume failure with new -secmgr flag > --------------------------------------------------------------------- > > Key: JBWS-4083 > URL: https://issues.jboss.org/browse/JBWS-4083 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-5.2.0.Final > Reporter: R Searls > Assignee: R Searls > > There are 3 tests that use ${WILDFLY_HOME}/bin/wsprovide.sh > * org.jboss.test.ws.jaxws.jbws2528.JBWS2528TestCase > * org.jboss.test.ws.jaxws.jbws2529.JBWS2529TestCase > * org.jboss.test.ws.jaxws.smoke.tools.WSProvideScriptTestCase > and 1 test that uses ${WILDFLY_HOME}/bin/wsconsume.sh > * org.jboss.test.ws.jaxws.smoke.tools.WSConsumeScriptTestCase > When running with wildfly in *secmgr* mode and testing with the *-secmgr *flag the tests fail. > This is because utilities wsprovide and wsconsume in wildfly are broken. They are not handling the (new) -secmgr flag properly. Changes to jboss-module.jar requires this flag. > Jiras have been filed in wildfly 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-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 updated JBWS-4084: --------------------------- Assignee: R Searls > 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 > > 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-4084) bug in jboss-module cause of 2 testcase failures

by R Searls (JIRA)

R Searls created JBWS-4084: ------------------------------ Summary: 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 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues November 2017