[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:
--------------------------------
Solution: Added to WSIntegrationProcessorJAXWS_POJO checking of the WebContext
annotation's urlPattern and the jbossws-webservices.xml file's port-component/port-component-uri.
This class was changed to use the same urlPattern generation algorithms as
URLPatternDeploymentAspect.
> 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)
9 years, 9 months
[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 updated JBWS-3809:
---------------------------
Attachment: JBWS-3809.patch
Patch file for Alessio's wildFly jbossws5 branch.
> 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)
9 years, 9 months
[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 updated JBWS-3809:
---------------------------
Attachment: jbws3809-sample_v2.zip
revised sample app
> 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: 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)
9 years, 9 months
[JBoss JIRA] (JBWS-3777) CXF-5645: wsp:Optional isn't adhered to for WS-RM policy in WSDL
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWS-3777?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWS-3777:
-----------------------------------------------
Rostislav Svoboda <rsvoboda(a)redhat.com> changed the Status of [bug 1080321|https://bugzilla.redhat.com/show_bug.cgi?id=1080321] from ON_QA to VERIFIED
> CXF-5645: wsp:Optional isn't adhered to for WS-RM policy in WSDL
> ----------------------------------------------------------------
>
> Key: JBWS-3777
> URL: https://issues.jboss.org/browse/JBWS-3777
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.2.3
> Environment: Red Hat JBoss EAP 6.2.0
> Reporter: Tadayoshi Sato
> Assignee: Jim Ma
> Fix For: jbossws-cxf-5.0
>
> Attachments: ws-rm.zip
>
>
> Please port the fix for [CXF-5645|https://issues.apache.org/jira/browse/CXF-5645] to JBoss WS CXF.
> Here is the original issue description:
> The {{wsp:Optional}} attribute doesn't work for WS-RM in JBoss WS CXF. As far as the specs tell both WS-Addressing 1.0 and WS-RM 1.1 should support {{wsp:Optional}}, that is, if {{wsp:Optional}} is set to {{true}} on a WS-RM policy the WS-RM policy should become optional -- the endpoint should allow both messages with and without WS-RM \[1\]. However, my experimentation showed that it actually doesn't.
> What I did is as follows (see the attached reproducer for details):
> # Configured in WSDL ({{greeting.wsdl}}) an endpoint as optionally WS-RM enabled like the following:
> {code:xml}
> <wsdl:binding name="GreetingServiceSoapBinding" type="tns:GreetingService">
> <wsp:Policy xmlns:wsp="http://www.w3.org/2006/07/ws-policy">
> <wsam:Addressing xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata"
> wsp:Optional="true" />
> <wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"
> wsp:Optional="true" />
> </wsp:Policy>
> ...
> {code}
> # Sent a WS-RM unaware (= no SOAP header) SOAP request from the client but got the following SOAP Fault:
> {code:xml}
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body>
> <soap:Fault>
> <faultcode>soap:Server</faultcode>
> <faultstring>WS-Addressing is required by this endpoint.</faultstring>
> </soap:Fault>
> </soap:Body>
> </soap:Envelope>
> {code}
> [1] In WS-RM Policy 1.1 p.8:
> {quote}
> /wsrmp:RMAssertion/@wsp:Optional="true"
> Per WS-Policy, this is compact notation for two policy alternatives, one with and one without the assertion. The intuition is that the behavior indicated by the assertion is optional, or in this case, that WS-ReliableMessaging MAY be used.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (JBWS-3777) CXF-5645: wsp:Optional isn't adhered to for WS-RM policy in WSDL
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWS-3777?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWS-3777:
-----------------------------------------------
Alessio Soldano <asoldano(a)redhat.com> changed the Status of [bug 1080321|https://bugzilla.redhat.com/show_bug.cgi?id=1080321] from NEW to ON_QA
> CXF-5645: wsp:Optional isn't adhered to for WS-RM policy in WSDL
> ----------------------------------------------------------------
>
> Key: JBWS-3777
> URL: https://issues.jboss.org/browse/JBWS-3777
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.2.3
> Environment: Red Hat JBoss EAP 6.2.0
> Reporter: Tadayoshi Sato
> Assignee: Jim Ma
> Fix For: jbossws-cxf-5.0
>
> Attachments: ws-rm.zip
>
>
> Please port the fix for [CXF-5645|https://issues.apache.org/jira/browse/CXF-5645] to JBoss WS CXF.
> Here is the original issue description:
> The {{wsp:Optional}} attribute doesn't work for WS-RM in JBoss WS CXF. As far as the specs tell both WS-Addressing 1.0 and WS-RM 1.1 should support {{wsp:Optional}}, that is, if {{wsp:Optional}} is set to {{true}} on a WS-RM policy the WS-RM policy should become optional -- the endpoint should allow both messages with and without WS-RM \[1\]. However, my experimentation showed that it actually doesn't.
> What I did is as follows (see the attached reproducer for details):
> # Configured in WSDL ({{greeting.wsdl}}) an endpoint as optionally WS-RM enabled like the following:
> {code:xml}
> <wsdl:binding name="GreetingServiceSoapBinding" type="tns:GreetingService">
> <wsp:Policy xmlns:wsp="http://www.w3.org/2006/07/ws-policy">
> <wsam:Addressing xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata"
> wsp:Optional="true" />
> <wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"
> wsp:Optional="true" />
> </wsp:Policy>
> ...
> {code}
> # Sent a WS-RM unaware (= no SOAP header) SOAP request from the client but got the following SOAP Fault:
> {code:xml}
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body>
> <soap:Fault>
> <faultcode>soap:Server</faultcode>
> <faultstring>WS-Addressing is required by this endpoint.</faultstring>
> </soap:Fault>
> </soap:Body>
> </soap:Envelope>
> {code}
> [1] In WS-RM Policy 1.1 p.8:
> {quote}
> /wsrmp:RMAssertion/@wsp:Optional="true"
> Per WS-Policy, this is compact notation for two policy alternatives, one with and one without the assertion. The intuition is that the behavior indicated by the assertion is optional, or in this case, that WS-ReliableMessaging MAY be used.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[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:
--------------------------------
The JSR-109, JSR-181 and JSR-318 were reviewed for directives in handling
annotation WebService attribute serviceName. These expert groups provide
no specific direction in managing WS endpoint service names.
JSR-109, section 5.3.2.1, states,
"serviceName attribute of javax.jws.WebService annotation prefixed with "/" maps to <url-pattern>
element in web.xml. If the serviceName attribute in javax.jws.WebService annotation is not
specified, then the default value as specified in JSR-181 specification is used."
JSR-181:, section 4.1.1 states, if "serviceName" is not specified the default value is,
"The simple name of the Java class + "Service" ".
JSR-318 makes no mention of annotation WebService or attribute serviceName.
> 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: jbws3809-sample.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)
9 years, 9 months
[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 updated JBWS-3809:
---------------------------
Attachment: jbws3809-sample.zip
This sample generates the server error ref above.
The sample zip contains maven (ear) project. Src code is included.
An ANT build.xml is provided for deploy and undeploy. ex use
ant -Djboss.home=/tmp/projects/wildfly/build/target/wildfly-8.1.0.CR1 deploy
> 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: jbws3809-sample.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)
9 years, 9 months
[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:
---------------------------------------
See discussion on this at http://www.webmail.echelog.com/logs/browse/wildfly/1404079200
> 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
>
>
> 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)
9 years, 9 months
[JBoss JIRA] (JBWS-3788) Add catalog testcase
by R Searls (JIRA)
[ https://issues.jboss.org/browse/JBWS-3788?page=com.atlassian.jira.plugin.... ]
R Searls commented on JBWS-3788:
--------------------------------
Added test for server side (cxf) catalog usage.
> Add catalog testcase
> --------------------
>
> Key: JBWS-3788
> URL: https://issues.jboss.org/browse/JBWS-3788
> Project: JBoss Web Services
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf
> Reporter: Alessio Soldano
> Assignee: R Searls
> Fix For: jbossws-cxf-5.0
>
>
> We need a testcase that explicitly verifies usage of jaxws catalog both in the jbossws-cxf-client jar / jaxws-client module and in a user deployment.
> As a consequence of having moved to Apache CXF 3.0.0 (JBWS-3686), I'm seeing warnings like the following because of the change at [1]:
> {noformat}
> 10:48:16,235 WARNING [org.apache.cxf.catalog.OASISCatalogManager] (MSC service thread 1-4) Catalog found at jar:file:/dati/jboss-as-7.2.0.Final/build/target/jboss-as-7.2.0.Final/modules/system/layers/base/org/jboss/ws/jaxws-client/main/jbossws-cxf-client.jar!/META-INF/jax-ws-catalog.xml but no org.apache.xml.resolver.CatalogManager was found. Check the classpatch for an xmlresolver jar.
> 10:48:16,235 WARNING [org.apache.cxf.catalog.OASISCatalogManager] (MSC service thread 1-4) Catalog found at jar:file:/dati/jboss-as-7.2.0.Final/build/target/jboss-as-7.2.0.Final/modules/system/layers/base/org/apache/cxf/impl/main/cxf-tools-wsdlto-frontend-jaxws.jar!/META-INF/jax-ws-catalog.xml but no org.apache.xml.resolver.CatalogManager was found. Check the classpatch for an xmlresolver jar.
> {noformat}
> We need to clarify this a bit.
> [1] https://github.com/apache/cxf/commit/7823e995
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months