February 2018 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-4095) Cannot register web service, fails with NullPointerException in DelegateClassLoader

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-4095?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-4095: ---------------------------------- Fix Version/s: jbossws-cxf-5.2.1.Final > 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: Alessio Soldano > 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)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4095) Cannot register web service, fails with NullPointerException in DelegateClassLoader

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-4095?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-4095: ---------------------------------- Project: JBoss Web Services (was: WildFly) Key: JBWS-4095 (was: WFLY-9837) Workflow: classic default workflow (was: GIT Pull Request workflow ) Component/s: jbossws-cxf (was: Web Services) Affects Version/s: (was: 11.0.0.Final) > 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: Alessio Soldano > > 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)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4094) Update target containers (include WFLY 12)

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-4094: ------------------------------------- Summary: Update target containers (include WFLY 12) Key: JBWS-4094 URL: https://issues.jboss.org/browse/JBWS-4094 Project: JBoss Web Services Issue Type: Task Components: jbossws-cxf, jbossws-integration Reporter: Alessio Soldano Fix For: jbossws-cxf-5.2.1.Final We need to update the target container adding wildfly 12 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4093) Upgrade to Apache CXF 3.2.2

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-4093: ------------------------------------- Summary: Upgrade to Apache CXF 3.2.2 Key: JBWS-4093 URL: https://issues.jboss.org/browse/JBWS-4093 Project: JBoss Web Services Issue Type: Task Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.2.1.Final -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4092) jaxws-tools-maven-plugin, Update version of archive dependencies

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-4092?page=com.atlassian.jira.plugin.... ] Alessio Soldano reopened JBWS-4092: ----------------------------------- > jaxws-tools-maven-plugin, Update version of archive dependencies > ---------------------------------------------------------------- > > Key: JBWS-4092 > URL: https://issues.jboss.org/browse/JBWS-4092 > Project: JBoss Web Services > Issue Type: Task > Components: jaxws-tools-maven-plugin > Reporter: R Searls > Assignee: R Searls > > The testcases no longer run because some of the dependency archives are out of date. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4075) jaxws-tools-maven-plugin doesn't work on JDK9

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-4075?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-4075: -------------------------------- The specific exception described in this jira was more related to the code having old versions of dependency archives. Fixing that addressed an issue with the testcases failing and exceptions given by the tool. Jira https://issues.jboss.org/browse/JBWS-4092 was created to checkin these changes. It is unclear if the JBWS-4092 changes are sufficient for this tool to be used with jdk9. This is because this tool requires archive org.jboss.ws.cxf:jbossws-cxf-client. I have not been able to successfully run my test app with the version changes, org.jboss.ws.cxf:jbossws-cxf-client:5.2.0.Final and JDK9. I have not been able to build jbossws-cxf branch jdk9 with any version of JDK9. jbossws-cxf-client references classes javax.tools.JavaFileManager, javax/tools/DiagnosticListener. These are exported from module java.compile. My test app reports NoClassDefFoundError expections for classes. I have not found a way to address this issue. > 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, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4091) Travis CI jobs

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-4091?page=com.atlassian.jira.plugin.... ] R Searls edited comment on JBWS-4091 at 2/1/18 1:51 PM: -------------------------------------------------------- jbossws-cxf:5.2.1-SNAPSHOT had dependencies on several archives that only reside in repository, https://repository.jboss.org/nexus/content/groups/developer/. com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.16-jbossorg-1 org.apache.activemq:artemis-commons:jar:1.1.0.wildfly-011 Travis CI does not appear to be able to get access to this repository. Travis CI appears to have access only to maven central. saaj-impl:jar:1.3.16-jbossorg-1 can be resolved by moving to saaj-impl:jar:1.3.18 because that version resides in maven central. It does not appear artemis-commons:jar:1.1.0.wildfly-011 can be resolved because no "wildfly-0*" releases resides in maven central. In the project I have provided a custom maven settings.xml file that enables access to https://repository.jboss.org/nexus/content/groups/developer/. I tested the customer file in my local builds; it works there. This settings file does not work in Travis CI Travis.yml is as follows, line 2 directs maven to use the custom settings.xml file {code:java} install: - mvn -s tarvis-settings.xml clean install script: - mvn -B -fae -P$SERVER_VERSION integration-test language: java jdk: - oraclejdk8 - oraclejdk9 env: - SERVER_VERSION=wildfly1010 # - SERVER_VERSION=wildfly1000 # - SERVER_VERSION=wildfly1100 # - SERVER_VERSION=wildfly1110 matrix: exclude: - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1010 - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1000 - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1100 - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1110 cache: directories: - $HOME/.m2 addons: apt: packages: - oracle-java8-installer before_install: - "if [ -d \"$JAVA_HOME/jre\" ]; then SEC_LIB=$JAVA_HOME/jre; else SEC_LIB=$JAVA_HOME; fi; sudo unzip -j -o travis-libs/jce_policy-8.zip *.jar -d $SEC_LIB/lib/security;" {code} was (Author: rsearls): jbossws-cxf:5.2.1-SNAPSHOT had dependencies on several archives that only reside in repository, https://repository.jboss.org/nexus/content/groups/developer/. com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.16-jbossorg-1 org.apache.activemq:artemis-commons:jar:1.1.0.wildfly-011 Travis CI does not appear to be able to get access to this repository. Travis CI appears to have access only to maven central. saaj-impl:jar:1.3.16-jbossorg-1 can be resolved by moving to saaj-impl:jar:1.3.18. It does not appear artemis-commons:jar:1.1.0.wildfly-011 can be resolved because no "wildfly-0*" releases resides in maven central. In the project I have provided a custom maven settings.xml file that enables access to https://repository.jboss.org/nexus/content/groups/developer/. I tested the customer file in my local builds; it works there. This settings file does not work in Travis CI Travis.yml is as follows, line 2 directs maven to use the custom settings.xml file {code:java} install: - mvn -s tarvis-settings.xml clean install script: - mvn -B -fae -P$SERVER_VERSION integration-test language: java jdk: - oraclejdk8 - oraclejdk9 env: - SERVER_VERSION=wildfly1010 # - SERVER_VERSION=wildfly1000 # - SERVER_VERSION=wildfly1100 # - SERVER_VERSION=wildfly1110 matrix: exclude: - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1010 - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1000 - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1100 - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1110 cache: directories: - $HOME/.m2 addons: apt: packages: - oracle-java8-installer before_install: - "if [ -d \"$JAVA_HOME/jre\" ]; then SEC_LIB=$JAVA_HOME/jre; else SEC_LIB=$JAVA_HOME; fi; sudo unzip -j -o travis-libs/jce_policy-8.zip *.jar -d $SEC_LIB/lib/security;" {code} > Travis CI jobs > -------------- > > Key: JBWS-4091 > URL: https://issues.jboss.org/browse/JBWS-4091 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf, productization > Reporter: Alessio Soldano > Assignee: R Searls > Fix For: jbossws-cxf-5.2.1.Final > > > This is about having travis ci job(s) run automatically for each commit & opened PR on github. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4091) Travis CI jobs

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-4091?page=com.atlassian.jira.plugin.... ] R Searls edited comment on JBWS-4091 at 2/1/18 1:50 PM: -------------------------------------------------------- jbossws-cxf:5.2.1-SNAPSHOT had dependencies on several archives that only reside in repository, https://repository.jboss.org/nexus/content/groups/developer/. com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.16-jbossorg-1 org.apache.activemq:artemis-commons:jar:1.1.0.wildfly-011 Travis CI does not appear to be able to get access to this repository. Travis CI appears to have access only to maven central. saaj-impl:jar:1.3.16-jbossorg-1 can be resolved by moving to saaj-impl:jar:1.3.18. It does not appear artemis-commons:jar:1.1.0.wildfly-011 can be resolved because no "wildfly-0*" releases resides in maven central. In the project I have provided a custom maven settings.xml file that enables access to https://repository.jboss.org/nexus/content/groups/developer/. I tested the customer file in my local builds; it works there. This settings file does not work in Travis CI Travis.yml is as follows, line 2 directs maven to use the custom settings.xml file {code:java} install: - mvn -s tarvis-settings.xml clean install script: - mvn -B -fae -P$SERVER_VERSION integration-test language: java jdk: - oraclejdk8 - oraclejdk9 env: - SERVER_VERSION=wildfly1010 # - SERVER_VERSION=wildfly1000 # - SERVER_VERSION=wildfly1100 # - SERVER_VERSION=wildfly1110 matrix: exclude: - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1010 - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1000 - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1100 - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1110 cache: directories: - $HOME/.m2 addons: apt: packages: - oracle-java8-installer before_install: - "if [ -d \"$JAVA_HOME/jre\" ]; then SEC_LIB=$JAVA_HOME/jre; else SEC_LIB=$JAVA_HOME; fi; sudo unzip -j -o travis-libs/jce_policy-8.zip *.jar -d $SEC_LIB/lib/security;" {code} was (Author: rsearls): jbossws-cxf:5.2.1-SNAPSHOT had dependencies on several archives that only reside in repository, https://repository.jboss.org/nexus/content/groups/developer/. com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.16-jbossorg-1 org.apache.activemq:artemis-commons:jar:1.1.0.wildfly-011 Travis CI does not appear to be able to get access to this repository. Travis CI appears to have access only to maven central. saaj-impl:jar:1.3.16-jbossorg-1 can be resolved by moving to saaj-impl:jar:1.3.18. It does not appear artemis-commons:jar:1.1.0.wildfly-011 can be resolved because no "wildfly-0*" releases resides in maven central. In the project I have provided a custom maven settings.xml file that enables access to https://repository.jboss.org/nexus/content/groups/developer/. I tested the customer file in my local builds; it works there. This settings file does not work in Travis CI Travis.yml is as follows, line 2 directs maven to use the custom settings.xml file install: - mvn -s tarvis-settings.xml clean install script: - mvn -B -fae -P$SERVER_VERSION integration-test language: java jdk: - oraclejdk8 - oraclejdk9 env: - SERVER_VERSION=wildfly1010 # - SERVER_VERSION=wildfly1000 # - SERVER_VERSION=wildfly1100 # - SERVER_VERSION=wildfly1110 matrix: exclude: - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1010 - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1000 - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1100 - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1110 cache: directories: - $HOME/.m2 addons: apt: packages: - oracle-java8-installer before_install: - "if [ -d \"$JAVA_HOME/jre\" ]; then SEC_LIB=$JAVA_HOME/jre; else SEC_LIB=$JAVA_HOME; fi; sudo unzip -j -o travis-libs/jce_policy-8.zip *.jar -d $SEC_LIB/lib/security;" > Travis CI jobs > -------------- > > Key: JBWS-4091 > URL: https://issues.jboss.org/browse/JBWS-4091 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf, productization > Reporter: Alessio Soldano > Assignee: R Searls > Fix For: jbossws-cxf-5.2.1.Final > > > This is about having travis ci job(s) run automatically for each commit & opened PR on github. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4091) Travis CI jobs

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-4091?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-4091: -------------------------------- jbossws-cxf:5.2.1-SNAPSHOT had dependencies on several archives that only reside in repository, https://repository.jboss.org/nexus/content/groups/developer/. com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.16-jbossorg-1 org.apache.activemq:artemis-commons:jar:1.1.0.wildfly-011 Travis CI does not appear to be able to get access to this repository. Travis CI appears to have access only to maven central. saaj-impl:jar:1.3.16-jbossorg-1 can be resolved by moving to saaj-impl:jar:1.3.18. It does not appear artemis-commons:jar:1.1.0.wildfly-011 can be resolved because no "wildfly-0*" releases resides in maven central. In the project I have provided a custom maven settings.xml file that enables access to https://repository.jboss.org/nexus/content/groups/developer/. I tested the customer file in my local builds; it works there. This settings file does not work in Travis CI Travis.yml is as follows, line 2 directs maven to use the custom settings.xml file install: - mvn -s tarvis-settings.xml clean install script: - mvn -B -fae -P$SERVER_VERSION integration-test language: java jdk: - oraclejdk8 - oraclejdk9 env: - SERVER_VERSION=wildfly1010 # - SERVER_VERSION=wildfly1000 # - SERVER_VERSION=wildfly1100 # - SERVER_VERSION=wildfly1110 matrix: exclude: - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1010 - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1000 - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1100 - jdk: oraclejdk9 env: SERVER_VERSION=wildfly1110 cache: directories: - $HOME/.m2 addons: apt: packages: - oracle-java8-installer before_install: - "if [ -d \"$JAVA_HOME/jre\" ]; then SEC_LIB=$JAVA_HOME/jre; else SEC_LIB=$JAVA_HOME; fi; sudo unzip -j -o travis-libs/jce_policy-8.zip *.jar -d $SEC_LIB/lib/security;" > Travis CI jobs > -------------- > > Key: JBWS-4091 > URL: https://issues.jboss.org/browse/JBWS-4091 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf, productization > Reporter: Alessio Soldano > Assignee: R Searls > Fix For: jbossws-cxf-5.2.1.Final > > > This is about having travis ci job(s) run automatically for each commit & opened PR on github. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4092) jaxws-tools-maven-plugin, Update version of archive dependencies

by R Searls (JIRA)

R Searls created JBWS-4092: ------------------------------ Summary: jaxws-tools-maven-plugin, Update version of archive dependencies Key: JBWS-4092 URL: https://issues.jboss.org/browse/JBWS-4092 Project: JBoss Web Services Issue Type: Task Components: jaxws-tools-maven-plugin Reporter: R Searls Assignee: R Searls The testcases no longer run because some of the dependency archives are out of date. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 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 February 2018