July 2014 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3750) Add ability to rewrite path in WSDL URL references

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3750?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-3750: -------------------------------- Added documentation fragments to https://docs.jboss.org/author/display/WFLY8/Web+services+configuration and https://docs.jboss.org/author/display/WFLY9/Web+services+configuration > Add ability to rewrite path in WSDL URL references > -------------------------------------------------- > > Key: JBWS-3750 > URL: https://issues.jboss.org/browse/JBWS-3750 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Kyle Lape > Assignee: R Searls > Fix For: jbossws-cxf-5.0 > > Attachments: feature-doc-fragment.txt > > > Currently JBossWS/CXF have the ability to configure a custom host and/or port to use when populating the soap:address and schemaLocation items in a WSDL. This request is to add the ability to configure a custom URL path in addition to the host and port. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3750) Add ability to rewrite path in WSDL URL references

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3750?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-3750: -------------------------------- Integration of code for cxf.5.0.0. The following repos with commits. https://svn.jboss.org/repos/jbossws/spi/trunk ( Committed revision 18822 ) https://svn.jboss.org/repos/jbossws/common/trunk ( Committed revision 18823 ) https://svn.jboss.org/repos/jbossws/container/wildfly80/branches/jbossws-... ( Committed revision 18824. ) https://github.com/asoldano/wildfly/pull/9 (pull request) > Add ability to rewrite path in WSDL URL references > -------------------------------------------------- > > Key: JBWS-3750 > URL: https://issues.jboss.org/browse/JBWS-3750 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Kyle Lape > Assignee: R Searls > Fix For: jbossws-cxf-5.0 > > Attachments: feature-doc-fragment.txt > > > Currently JBossWS/CXF have the ability to configure a custom host and/or port to use when populating the soap:address and schemaLocation items in a WSDL. This request is to add the ability to configure a custom URL path in addition to the host and port. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3818) Upgrade to Apache CXF 3.0.2

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3818: ------------------------------------- Summary: Upgrade to Apache CXF 3.0.2 Key: JBWS-3818 URL: https://issues.jboss.org/browse/JBWS-3818 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Fix For: jbossws-cxf-5.0 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3817) Avoid globally installing BouncyCastle

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3817: ------------------------------------- Summary: Avoid globally installing BouncyCastle Key: JBWS-3817 URL: https://issues.jboss.org/browse/JBWS-3817 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.0 This is about preventing Apache CXF / WSS4J from installing BouncyCastle globally and actually setting its security provider at message exchange level as described in https://issues.apache.org/jira/browse/CXF-5905 . -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3809) AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3809?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-3809: -------------------------------- added tests to testsuite https://svn.jboss.org/repos/jbossws/stack/cxf/trunk ./modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/jbws3809 (Committed revision 18816.) > AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data > ---------------------------------------------------------------------------- > > Key: JBWS-3809 > URL: https://issues.jboss.org/browse/JBWS-3809 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: R Searls > Fix For: jbossws-cxf-4.3.1, jbossws-cxf-5.0 > > Attachments: JBWS-3809.patch, jbws3809-sample.zip, jbws3809-sample_v2.zip > > > We currently have a check on urlPattern uniqueness in a given deployment unit that is performed in the container integration layer (AbstractDeployment#addEndpoint). The urlPattern there is not the actual urlPatter that will eventually be used for the endpoints in case of ejb3 ws deployments (see WSIntegrationProcessorJAXWS_POJO#processAnnotation which computes the urlPatter using the @WebService annotation only when no ServletMetadata is found & matched). > If the deployment contains multiple endpoints declaring the same serviceName, the deployment fails. Attempts to override the urlPattern (by specifying a port-component-uri in jboss-webservices.xml or by adding @WebContext(urlPattern="...") to the endpoint) do not work, likely because those are considered only later when running the URLPatternDeploymentAspect. > {noformat} > 2014-06-30 14:00:41,434 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "product-dispatch-ejb-4.0.0-SNAPSHOT.jar" of deployment "project-ear-4.0.0-SNAPSHOT-oracle-10g.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05] > Caused by: java.lang.IllegalArgumentException: JBAS015533: Web Service endpoint de.mobilexag.product.dispatch.ws2.QualificationAndAlternativeSynchronizerServiceBean with URL pattern /dispate2Web is already registered. Web service endpoint de.mobilexag.product.dispatch.ws2.basicupdate.BasicUpdateTaskServiceBean is requesting the same URL pattern. > at org.jboss.as.webservices.metadata.model.AbstractDeployment.addEndpoint(AbstractDeployment.java:60) > at org.jboss.as.webservices.metadata.model.JAXWSDeployment.addEndpoint(JAXWSDeployment.java:27) > at org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_POJO.processAnnotation(WSIntegrationProcessorJAXWS_POJO.java:143) > at org.jboss.as.webservices.deployers.AbstractIntegrationProcessorJAXWS.deploy(AbstractIntegrationProcessorJAXWS.java:74) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > ... 5 more > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3816) WSTrustActAsTestCase.testActAs failing with move to cxf 3.0.2-SNAPSHOT

by R Searls (JIRA)

R Searls created JBWS-3816: ------------------------------ Summary: WSTrustActAsTestCase.testActAs failing with move to cxf 3.0.2-SNAPSHOT Key: JBWS-3816 URL: https://issues.jboss.org/browse/JBWS-3816 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Reporter: R Searls Assignee: R Searls Priority: Minor Fix For: jbossws-cxf-5.0 WSTrustActAsTestCase.testActAs is failing with the following error Stacktrace javax.xml.ws.soap.SOAPFaultException: The specified request failed at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:159) at com.sun.proxy.$Proxy203.sayHello(Unknown Source) at org.jboss.test.ws.jaxws.samples.wsse.policy.trust.WSTrustActAsTestCase.testActAs(WSTrustActAsTestCase.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:243) at junit.framework.TestSuite.run(TestSuite.java:238) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at org.jboss.wsf.test.JBossWSTestSetup$1.protect(JBossWSTestSetup.java:141) at junit.framework.TestResult.runProtected(TestResult.java:128) at org.jboss.wsf.test.JBossWSTestSetup.run(JBossWSTestSetup.java:148) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74) Caused by: org.apache.cxf.binding.soap.SoapFault: The specified request failed at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:84) at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:51) at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:40) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:113) at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69) at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1636) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1525) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1330) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) at org.apache.cxf.ws.security.trust.AbstractSTSClient.issue(AbstractSTSClient.java:839) at org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:62) at org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:56) at org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:52) at org.apache.cxf.ws.security.policy.interceptors.IssuedTokenInterceptorProvider$IssuedTokenOutInterceptor.getTokenFromSTS(IssuedTokenInterceptorProvider.java:394) at org.apache.cxf.ws.security.policy.interceptors.IssuedTokenInterceptorProvider$IssuedTokenOutInterceptor.issueToken(IssuedTokenInterceptorProvider.java:523) at org.apache.cxf.ws.security.policy.interceptors.IssuedTokenInterceptorProvider$IssuedTokenOutInterceptor.handleMessage(IssuedTokenInterceptorProvider.java:162) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137) ... 31 more Standard Error Warning: org.apache.xerces.parsers.SAXParser: Property 'http://javax.xml.XMLConstants/property/accessExternalDTD' is not recognized. Warning: org.apache.xerces.parsers.SAXParser: Property 'http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not recognized. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3809) AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3809?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3809: --------------------------------------- Can the sample attached here be converted in an integration testcase in the jbossws-cxf testsuite, so that we're sure no regression happens in the future? Thanks. > AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data > ---------------------------------------------------------------------------- > > Key: JBWS-3809 > URL: https://issues.jboss.org/browse/JBWS-3809 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: R Searls > Fix For: jbossws-cxf-4.3.1, jbossws-cxf-5.0 > > Attachments: JBWS-3809.patch, jbws3809-sample.zip, jbws3809-sample_v2.zip > > > We currently have a check on urlPattern uniqueness in a given deployment unit that is performed in the container integration layer (AbstractDeployment#addEndpoint). The urlPattern there is not the actual urlPatter that will eventually be used for the endpoints in case of ejb3 ws deployments (see WSIntegrationProcessorJAXWS_POJO#processAnnotation which computes the urlPatter using the @WebService annotation only when no ServletMetadata is found & matched). > If the deployment contains multiple endpoints declaring the same serviceName, the deployment fails. Attempts to override the urlPattern (by specifying a port-component-uri in jboss-webservices.xml or by adding @WebContext(urlPattern="...") to the endpoint) do not work, likely because those are considered only later when running the URLPatternDeploymentAspect. > {noformat} > 2014-06-30 14:00:41,434 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "product-dispatch-ejb-4.0.0-SNAPSHOT.jar" of deployment "project-ear-4.0.0-SNAPSHOT-oracle-10g.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05] > Caused by: java.lang.IllegalArgumentException: JBAS015533: Web Service endpoint de.mobilexag.product.dispatch.ws2.QualificationAndAlternativeSynchronizerServiceBean with URL pattern /dispate2Web is already registered. Web service endpoint de.mobilexag.product.dispatch.ws2.basicupdate.BasicUpdateTaskServiceBean is requesting the same URL pattern. > at org.jboss.as.webservices.metadata.model.AbstractDeployment.addEndpoint(AbstractDeployment.java:60) > at org.jboss.as.webservices.metadata.model.JAXWSDeployment.addEndpoint(JAXWSDeployment.java:27) > at org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_POJO.processAnnotation(WSIntegrationProcessorJAXWS_POJO.java:143) > at org.jboss.as.webservices.deployers.AbstractIntegrationProcessorJAXWS.deploy(AbstractIntegrationProcessorJAXWS.java:74) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > ... 5 more > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3809) AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3809?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-3809: -------------------------------- Refactored code checked into https://svn.jboss.org/repos/jbossws/common/trunk (revision 18808) and wfly (https://github.com/asoldano/wildfly/pull/7). In wfly the change to WSIntegrationProcessorJAXWS_POJO.java is dependent on commit (revision 18808) in https://svn.jboss.org/repos/jbossws/common/trunk . > AbstractDeployment#addEndpoint's check on urlPattern performed on wrong data > ---------------------------------------------------------------------------- > > Key: JBWS-3809 > URL: https://issues.jboss.org/browse/JBWS-3809 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: R Searls > Fix For: jbossws-cxf-4.3.1, jbossws-cxf-5.0 > > Attachments: JBWS-3809.patch, jbws3809-sample.zip, jbws3809-sample_v2.zip > > > We currently have a check on urlPattern uniqueness in a given deployment unit that is performed in the container integration layer (AbstractDeployment#addEndpoint). The urlPattern there is not the actual urlPatter that will eventually be used for the endpoints in case of ejb3 ws deployments (see WSIntegrationProcessorJAXWS_POJO#processAnnotation which computes the urlPatter using the @WebService annotation only when no ServletMetadata is found & matched). > If the deployment contains multiple endpoints declaring the same serviceName, the deployment fails. Attempts to override the urlPattern (by specifying a port-component-uri in jboss-webservices.xml or by adding @WebContext(urlPattern="...") to the endpoint) do not work, likely because those are considered only later when running the URLPatternDeploymentAspect. > {noformat} > 2014-06-30 14:00:41,434 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project-ear-4.0.0-SNAPSHOT-oracle-10g.ear"."product-dispatch-ejb-4.0.0-SNAPSHOT.jar".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "product-dispatch-ejb-4.0.0-SNAPSHOT.jar" of deployment "project-ear-4.0.0-SNAPSHOT-oracle-10g.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05] > Caused by: java.lang.IllegalArgumentException: JBAS015533: Web Service endpoint de.mobilexag.product.dispatch.ws2.QualificationAndAlternativeSynchronizerServiceBean with URL pattern /dispate2Web is already registered. Web service endpoint de.mobilexag.product.dispatch.ws2.basicupdate.BasicUpdateTaskServiceBean is requesting the same URL pattern. > at org.jboss.as.webservices.metadata.model.AbstractDeployment.addEndpoint(AbstractDeployment.java:60) > at org.jboss.as.webservices.metadata.model.JAXWSDeployment.addEndpoint(JAXWSDeployment.java:27) > at org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_POJO.processAnnotation(WSIntegrationProcessorJAXWS_POJO.java:143) > at org.jboss.as.webservices.deployers.AbstractIntegrationProcessorJAXWS.deploy(AbstractIntegrationProcessorJAXWS.java:74) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > ... 5 more > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3815) Add mechanism for setting system properties while running JBossWS tests

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3815: ------------------------------------- Summary: Add mechanism for setting system properties while running JBossWS tests Key: JBWS-3815 URL: https://issues.jboss.org/browse/JBWS-3815 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.0 Add setSystemProperty(String name, String value) to org.jboss.wsf.spi.deployer.Deployer -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3812) Incorrect value for ws-security.ut.validator

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3812?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3812: ---------------------------------- Fix Version/s: jbossws-cxf-5.0 > Incorrect value for ws-security.ut.validator > -------------------------------------------- > > Key: JBWS-3812 > URL: https://issues.jboss.org/browse/JBWS-3812 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.2.4 > Reporter: John Ament > Fix For: jbossws-cxf-5.0 > > > I found a forum post indicating that this value should work, in my hunt to make security work in WildFly. https://community.jboss.org/thread/229071 > When you set the parameter ws-security.ut.validator in jaxws-endpoint-config.xml, the value that gets set is in fact the string value, e.g. com.mycompany.cxf.validators.MySpecialValidator > CXF is expecting that this is an instantiated instance of the class, not a classname. It results in a ClassCastException. You can see here for reference: http://cxf.apache.org/docs/ws-securitypolicy.html look under Validator implementations. > To work around this, you can register a custom InInterceptor and set the value in the message context. It's not ideal, but you could read the value from jaxws-endpoint-config.xml and instantiate that class, passing it back to the message context. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 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 2014