[JBoss JIRA] (JBWS-4084) bug in jboss-module cause of 2 testcase failures
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-4084?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on JBWS-4084:
---------------------------------------
[~rsearls], what's the status of this jira?
> 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)
5 years, 9 months
[JBoss JIRA] (JBWS-4084) bug in jboss-module cause of 2 testcase failures
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-4084?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on JBWS-4084:
---------------------------------------
[~rsearls], what's the status of this jira?
> 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)
5 years, 9 months
[JBoss JIRA] (JBWS-4129) Can't deploy webservice on JDK11
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-4129?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-4129:
----------------------------------
Assignee: Jim Ma
> Can't deploy webservice on JDK11
> --------------------------------
>
> Key: JBWS-4129
> URL: https://issues.jboss.org/browse/JBWS-4129
> Project: JBoss Web Services
> Issue Type: Bug
> Affects Versions: jbossws-cxf-5.2.1.Final
> Reporter: Jan Blizňák
> Assignee: Jim Ma
> Fix For: jbossws-cxf-5.2.2.Final
>
>
> When you try to deploy webservice (eg. by running the testsuite) on latest Wildfly running on latest JDK11 available [http://jdk.java.net/11/], an error is thrown on server side during the process, ultimately caused by:
> {code:java}
> Caused by: java.lang.NumberFormatException: For input string: "11-ea"
> at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.base/java.lang.Integer.parseInt(Integer.java:652)
> at java.base/java.lang.Integer.valueOf(Integer.java:983)
> at org.apache.cxf(a)3.2.5//org.apache.cxf.helpers.JavaUtils.<clinit>(JavaUtils.java:57)
> ... 31 more{code}
> {code:java}
> [jbliznak@rh cxf]$ java -version
> java version "11-ea" 2018-09-25
> Java(TM) SE Runtime Environment 18.9 (build 11-ea+21)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
> {code}
> The blame goes for naive check at https://github.com/apache/cxf/blob/3.2.x-fixes/core/src/main/java/org/apa... which do not count with "-ea" or any other suffix in version, in other words we need fix on CXF side.
> Inspiration including tests https://github.com/google/gson/commit/a6890bbaba29fb1074388c06bf0c231f8e0...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (JBWS-4129) Can't deploy webservice on JDK11
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-4129?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-4129:
----------------------------------
Fix Version/s: jbossws-cxf-5.2.2.Final
> Can't deploy webservice on JDK11
> --------------------------------
>
> Key: JBWS-4129
> URL: https://issues.jboss.org/browse/JBWS-4129
> Project: JBoss Web Services
> Issue Type: Bug
> Affects Versions: jbossws-cxf-5.2.1.Final
> Reporter: Jan Blizňák
> Fix For: jbossws-cxf-5.2.2.Final
>
>
> When you try to deploy webservice (eg. by running the testsuite) on latest Wildfly running on latest JDK11 available [http://jdk.java.net/11/], an error is thrown on server side during the process, ultimately caused by:
> {code:java}
> Caused by: java.lang.NumberFormatException: For input string: "11-ea"
> at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.base/java.lang.Integer.parseInt(Integer.java:652)
> at java.base/java.lang.Integer.valueOf(Integer.java:983)
> at org.apache.cxf(a)3.2.5//org.apache.cxf.helpers.JavaUtils.<clinit>(JavaUtils.java:57)
> ... 31 more{code}
> {code:java}
> [jbliznak@rh cxf]$ java -version
> java version "11-ea" 2018-09-25
> Java(TM) SE Runtime Environment 18.9 (build 11-ea+21)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
> {code}
> The blame goes for naive check at https://github.com/apache/cxf/blob/3.2.x-fixes/core/src/main/java/org/apa... which do not count with "-ea" or any other suffix in version, in other words we need fix on CXF side.
> Inspiration including tests https://github.com/google/gson/commit/a6890bbaba29fb1074388c06bf0c231f8e0...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (JBWS-4129) Can't deploy webservice on JDK11
by Jan Blizňák (JIRA)
Jan Blizňák created JBWS-4129:
---------------------------------
Summary: Can't deploy webservice on JDK11
Key: JBWS-4129
URL: https://issues.jboss.org/browse/JBWS-4129
Project: JBoss Web Services
Issue Type: Bug
Affects Versions: jbossws-cxf-5.2.1.Final
Reporter: Jan Blizňák
When you try to deploy webservice (eg. by running the testsuite) on latest Wildfly running on latest JDK11 available [http://jdk.java.net/11/], an error is thrown on server side during the process, ultimately caused by:
{code:java}
Caused by: java.lang.NumberFormatException: For input string: "11-ea"
at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.base/java.lang.Integer.parseInt(Integer.java:652)
at java.base/java.lang.Integer.valueOf(Integer.java:983)
at org.apache.cxf(a)3.2.5//org.apache.cxf.helpers.JavaUtils.<clinit>(JavaUtils.java:57)
... 31 more{code}
{code:java}
[jbliznak@rh cxf]$ java -version
java version "11-ea" 2018-09-25
Java(TM) SE Runtime Environment 18.9 (build 11-ea+21)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
{code}
The blame goes for naive check at https://github.com/apache/cxf/blob/3.2.x-fixes/core/src/main/java/org/apa... which do not count with "-ea" or any other suffix in version, in other words we need fix on CXF side.
Inspiration including tests https://github.com/google/gson/commit/a6890bbaba29fb1074388c06bf0c231f8e0...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (JBWS-4095) Cannot register web service, fails with NullPointerException in DelegateClassLoader
by R Searls (JIRA)
[ https://issues.jboss.org/browse/JBWS-4095?page=com.atlassian.jira.plugin.... ]
R Searls commented on JBWS-4095:
--------------------------------
I see it in tagged version EAP_7.2.0.CD13-dev
> Cannot register web service, fails with NullPointerException in DelegateClassLoader
> -----------------------------------------------------------------------------------
>
> Key: JBWS-4095
> URL: https://issues.jboss.org/browse/JBWS-4095
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Reporter: Antonio Chirizzi
> Assignee: R Searls
> Fix For: jbossws-cxf-5.2.1.Final
>
>
> While deploying a EAR application, which contains a WAR which is trying to register a web service, I get the follwing exception:
> {code}
> 13:53:34,624 INFO [org.jboss.ws.cxf.deployment] (MSC service thread 1-7) JBWS024074: WSDL published to: file:/home/achirizzi/sandbox/dev/wildfly/wildfly-11.0.0.Final/standalone/data/wsdl/dms-new-ear-services-0.0.8.1.ear/dms-new-war-0.0.7.1.war/BusinessWebServiceService.wsdl
> 13:53:34,658 WARNING [org.apache.cxf.catalog.OASISCatalogManager] (MSC service thread 1-7) Catalog found at jar:file:/home/achirizzi/sandbox/dev/wildfly/wildfly-11.0.0.Final/modules/system/layers/base/org/jboss/ws/jaxws-client/main/jbossws-cxf-client-5.1.9.Final.jar!/META-INF/jax-ws-catalog.xml but no org.apache.xml.resolver.CatalogManager was found. Check the classpatch for an xmlresolver jar.
> 13:53:34,659 WARNING [org.apache.cxf.catalog.OASISCatalogManager] (MSC service thread 1-7) Catalog found at jar:file:/home/achirizzi/sandbox/dev/wildfly/wildfly-11.0.0.Final/modules/system/layers/base/org/apache/cxf/impl/main/cxf-tools-wsdlto-frontend-jaxws-3.1.12.jar!/META-INF/jax-ws-catalog.xml but no org.apache.xml.resolver.CatalogManager was found. Check the classpatch for an xmlresolver jar.
> 13:53:34,659 WARNING [org.apache.cxf.catalog.OASISCatalogManager] (MSC service thread 1-7) Catalog found at jar:file:/home/achirizzi/sandbox/dev/wildfly/wildfly-11.0.0.Final/modules/system/layers/base/org/apache/cxf/impl/main/cxf-services-ws-discovery-api-3.1.12.jar!/META-INF/jax-ws-catalog.xml but no org.apache.xml.resolver.CatalogManager was found. Check the classpatch for an xmlresolver jar.
> 13:53:34,773 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."dms-new-ear-services-0.0.8.1.ear"."dms-new-war-0.0.7.1.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."dms-new-ear-services-0.0.8.1.ear"."dms-new-war-0.0.7.1.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "dms-new-war-0.0.7.1.war" of deployment "dms-new-ear-services-0.0.8.1.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.xml.parsers.FactoryConfigurationError: Provider __redirected.__DocumentBuilderFactory could not be instantiated: java.lang.NullPointerException
> at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:204)
> at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:152)
> at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:232)
> at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:120)
> at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(WSDLReaderImpl.java:2180)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2390)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2422)
> at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:238)
> at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:163)
> at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:85)
> at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:217)
> at org.apache.cxf.jaxws.ServiceImpl.initialize(ServiceImpl.java:160)
> at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:129)
> at org.jboss.wsf.stack.cxf.client.ProviderImpl$JBossWSServiceImpl.<init>(ProviderImpl.java:574)
> at org.jboss.wsf.stack.cxf.client.ProviderImpl.createServiceDelegate(ProviderImpl.java:258)
> at javax.xml.ws.Service.<init>(Service.java:57)
> at com.tullettprebon.dms.tmmalternativeaddress.ws.TMMMarkitWireService.<init>(TMMMarkitWireService.java:60)
> at com.tullettprebon.dms.webservices.ReferenceWebService.<init>(ReferenceWebService.java:232)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at org.jboss.wsf.stack.cxf.configuration.BusHolder.newInstance(BusHolder.java:322)
> at org.jboss.wsf.stack.cxf.configuration.BusHolder.configure(BusHolder.java:212)
> at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:97)
> at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:59)
> at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:73)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> Caused by: java.lang.NullPointerException
> at org.jboss.ws.common.utils.DelegateClassLoader.getResourceAsStream(DelegateClassLoader.java:132)
> at __redirected.__RedirectedUtils.findProviderClassNames(__RedirectedUtils.java:147)
> at __redirected.__RedirectedUtils.loadProvider(__RedirectedUtils.java:102)
> at __redirected.__RedirectedUtils.loadProvider(__RedirectedUtils.java:98)
> at __redirected.__DocumentBuilderFactory.<init>(__DocumentBuilderFactory.java:103)
> at sun.reflect.GeneratedConstructorAccessor62.newInstance(Unknown Source)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:192)
> ... 33 more
> {code}
> I wasted 3 days trying to find a solution thinking that the problem was in my dependencies with xerces or any other xml resolver.
> Then I decided to checkout the code near the root cause:
> {code}
> Caused by: java.lang.NullPointerException
> at org.jboss.ws.common.utils.DelegateClassLoader.getResourceAsStream(DelegateClassLoader.java:132)
> at __redirected.__RedirectedUtils.findProviderClassNames(__RedirectedUtils.java:147)
> at __redirected.__RedirectedUtils.loadProvider(__RedirectedUtils.java:102)
> at __redirected.__RedirectedUtils.loadProvider(__RedirectedUtils.java:98)
> at __redirected.__DocumentBuilderFactory.<init>(__DocumentBuilderFactory.java:103)
> at sun.reflect.GeneratedConstructorAccessor62.newInstance(Unknown Source)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:192)
> ... 33 more
> {code}
> and I think I have fixed a bug in {{jbossws-common-3.1.5}}.
> I have downloaded the latest version of {{jbossws-common-master}} from github (with which the problem was still showing).
> Then I fixed the class {{org/jboss/ws/common/utils/DelegateClassLoader.java}} changing this:
> {code}
> /** {@inheritDoc} */
> @Override
> public InputStream getResourceAsStream(final String name)
> {
> InputStream is = parent.getResourceAsStream(name);
> return (is == null) ? delegate.getResourceAsStream(name) : is;
> }
> {code}
> to this:
> {code}
> /** {@inheritDoc} */
> @Override
> public InputStream getResourceAsStream(final String name)
> {
> InputStream is = null;
> if (parent != null)
> {
> is = parent.getResourceAsStream(name);
> }
> return (is == null) ? delegate.getResourceAsStream(name) : is;
> }
> {code}
> and then built again the jbossws-common jar and replaced the (suspected) faulty one under the WildFly modules. With the new jar the webservice can be registered.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months