August 2014 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3821) WebServiceRef injection not working with TCCL and NEW client Bus selection strategies

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3821: ------------------------------------- Summary: WebServiceRef injection not working with TCCL and NEW client Bus selection strategies Key: JBWS-3821 URL: https://issues.jboss.org/browse/JBWS-3821 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.0 The WebServiceRef injection assumes the server is running with the THREAD bus strategy globally configured. If that's not the case, the server can end up using unexpected bus instances for webserviceref injected clients. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3820) JAXWS 2.1 / 2.0 clients and WebServiceRef using JAXWS features cause NoSuchMethodException

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3820?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3820: ---------------------------------- Description: When specifying a webserviceref whose metadata require MTOM or addressing as a consequence of @MTOM / @Addressing usage, an exception is thrown if the user Service class does not implement JAXWS 2.2 feature-enabled constructor. An example of a scenario reproducing the issue is a webserviceref as follows: {code} @WebServiceRef(name="service/jbws2307service") @MTOM HelloService service; {code} ... referencing a service class as follows: {code} @WebServiceClient(name = "HelloService", targetNamespace = "http://helloservice.org/wsdl", wsdlLocation = "WEB-INF/wsdl/HelloService.wsdl") public class HelloService extends Service { public HelloService(URL wsdlLocation, QName serviceName) { super(wsdlLocation, serviceName); } public HelloService() { super(HELLOSERVICE_WSDL_LOCATION, new QName("http://helloservice.org/wsdl", "HelloService")); } @WebEndpoint(name = "HelloPort") public Hello getHelloPort() { return ((Hello)super.getPort(new QName("http://helloservice.org/wsdl", "HelloPort"), Hello.class)); } // no constructors accepting JAX-WS WebServiceFeature //... } {code} was: When specifying a webserviceref whose metadata require MTOM or addressing as a consequence of @MTOM / @Addressing usage, an exception is thrown if the user Service class does not implement JAXWS 2.2 feature-enabled constructor. An example of a scenario reproducing the issue is a webserviceref as follows: {code} @WebServiceRef(name="service/jbws2307service") @MTOM HelloService service; {code} ... referencing a service class as follows: {code} @WebServiceClient(name = "HelloService", targetNamespace = "http://helloservice.org/wsdl", wsdlLocation = "WEB-INF/wsdl/HelloService.wsdl") public class HelloService extends Service { public HelloService(URL wsdlLocation, QName serviceName) { super(wsdlLocation, serviceName); } public HelloService() { super(HELLOSERVICE_WSDL_LOCATION, new QName("http://helloservice.org/wsdl", "HelloService")); } @WebEndpoint(name = "HelloPort") public Hello getHelloPort() { return ((Hello)super.getPort(new QName("http://helloservice.org/wsdl", "HelloPort"), Hello.class)); } // no constructors accepting JAX-WS WebServiceFeature //... } {code} > JAXWS 2.1 / 2.0 clients and WebServiceRef using JAXWS features cause NoSuchMethodException > ------------------------------------------------------------------------------------------ > > Key: JBWS-3820 > URL: https://issues.jboss.org/browse/JBWS-3820 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > When specifying a webserviceref whose metadata require MTOM or addressing as a consequence of @MTOM / @Addressing usage, an exception is thrown if the user Service class does not implement JAXWS 2.2 feature-enabled constructor. > An example of a scenario reproducing the issue is a webserviceref as follows: > {code} > @WebServiceRef(name="service/jbws2307service") > @MTOM > HelloService service; > {code} > ... referencing a service class as follows: > {code} > @WebServiceClient(name = "HelloService", targetNamespace = "http://helloservice.org/wsdl", wsdlLocation = "WEB-INF/wsdl/HelloService.wsdl") > public class HelloService extends Service { > public HelloService(URL wsdlLocation, QName serviceName) { > super(wsdlLocation, serviceName); > } > public HelloService() { > super(HELLOSERVICE_WSDL_LOCATION, new QName("http://helloservice.org/wsdl", "HelloService")); > } > @WebEndpoint(name = "HelloPort") > public Hello getHelloPort() { > return ((Hello)super.getPort(new QName("http://helloservice.org/wsdl", "HelloPort"), Hello.class)); > } > // no constructors accepting JAX-WS WebServiceFeature > //... > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3820) JAXWS 2.1 / 2.0 clients and WebServiceRef using JAXWS features cause NoSuchMethodException

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3820?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3820: ---------------------------------- Description: When specifying a webserviceref whose metadata require MTOM or addressing as a consequence of @MTOM / @Addressing usage, an exception is thrown if the user Service class does not implement JAXWS 2.2 feature-enabled constructor. An example of a scenario reproducing the issue is a webserviceref as follows: {code} @WebServiceRef(name="service/jbws2307service") @MTOM HelloService service; {code} ... referencing a service class as follows: {code} @WebServiceClient(name = "HelloService", targetNamespace = "http://helloservice.org/wsdl", wsdlLocation = "WEB-INF/wsdl/HelloService.wsdl") public class HelloService extends Service { public HelloService(URL wsdlLocation, QName serviceName) { super(wsdlLocation, serviceName); } public HelloService() { super(HELLOSERVICE_WSDL_LOCATION, new QName("http://helloservice.org/wsdl", "HelloService")); } @WebEndpoint(name = "HelloPort") public Hello getHelloPort() { return ((Hello)super.getPort(new QName("http://helloservice.org/wsdl", "HelloPort"), Hello.class)); } // no constructors accepting JAX-WS WebServiceFeature //... } {code} was:When specifying a webserviceref whose metadata require MTOM or addressing as a consequence of @MTOM / @Addressing usage, an exception is thrown if the user Service class does not implement JAXWS 2.2 feature-enabled constructor. > JAXWS 2.1 / 2.0 clients and WebServiceRef using JAXWS features cause NoSuchMethodException > ------------------------------------------------------------------------------------------ > > Key: JBWS-3820 > URL: https://issues.jboss.org/browse/JBWS-3820 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > When specifying a webserviceref whose metadata require MTOM or addressing as a consequence of @MTOM / @Addressing usage, an exception is thrown if the user Service class does not implement JAXWS 2.2 feature-enabled constructor. > An example of a scenario reproducing the issue is a webserviceref as follows: > {code} > @WebServiceRef(name="service/jbws2307service") > @MTOM > HelloService service; > {code} > ... referencing a service class as follows: > {code} > @WebServiceClient(name = "HelloService", targetNamespace = "http://helloservice.org/wsdl", wsdlLocation = "WEB-INF/wsdl/HelloService.wsdl") > public class HelloService extends Service > { > public HelloService(URL wsdlLocation, QName serviceName) > { > super(wsdlLocation, serviceName); > } > public HelloService() > { > super(HELLOSERVICE_WSDL_LOCATION, new QName("http://helloservice.org/wsdl", "HelloService")); > } > @WebEndpoint(name = "HelloPort") > public Hello getHelloPort() > { > return ((Hello)super.getPort(new QName("http://helloservice.org/wsdl", "HelloPort"), Hello.class)); > } > // no constructors accepting JAX-WS WebServiceFeature > //... > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3820) JAXWS 2.1 / 2.0 clients and WebServiceRef using JAXWS features cause NoSuchMethodException

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3820: ------------------------------------- Summary: JAXWS 2.1 / 2.0 clients and WebServiceRef using JAXWS features cause NoSuchMethodException Key: JBWS-3820 URL: https://issues.jboss.org/browse/JBWS-3820 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.0 When specifying a webserviceref whose metadata require MTOM or addressing as a consequence of @MTOM / @Addressing usage, an exception is thrown if the user Service class does not implement JAXWS 2.2 feature-enabled constructor. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 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: -------------------------------- Back ported fix into 810. https://svn.jboss.org/repos/jbossws/container/wildfly81/branches/jbossws-... Committed revision 18859. Files sent: Sending server-integration/src/main/java/org/jboss/as/webservices/deployers/WSIntegrationProcessorJAXWS_POJO.java Adding server-integration/src/main/java/org/jboss/as/webservices/deployers/WebContextAnnotationInfo.java Adding server-integration/src/main/java/org/jboss/as/webservices/deployers/WebContextAnnotationInformationFactory.java Sending server-integration/src/main/java/org/jboss/as/webservices/deployers/WebServiceAnnotationProcessor.java Sending server-integration/src/main/java/org/jboss/as/webservices/metadata/model/AbstractDeployment.java Sending server-integration/src/main/java/org/jboss/as/webservices/util/ASHelper.java Test case JBWS3809TestCase in https://svn.jboss.org/repos/jbossws/stack/cxf/trunk not yet enabled. > 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.3.1#6329)

10 years, 3 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: -------------------------------- Added test for wsdl-path-rewrite-rule test to (wfly) ./testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/ws/WSAttributesChangesTestCase.java Submitted https://github.com/asoldano/wildfly/pull/14 > 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.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3785) Add option for forcing https protocol when rewriting soap:addres in WSDL

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3785?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3785: --------------------------------------- Documentation updated at https://docs.jboss.org/author/display/WFLY9/Web+services+configuration > Add option for forcing https protocol when rewriting soap:addres in WSDL > ------------------------------------------------------------------------ > > Key: JBWS-3785 > URL: https://issues.jboss.org/browse/JBWS-3785 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > In some cases it might be useful having an option in the ServerConfig for forcing the use of https protocol when rewriting the WSDL soap:address. > That would basically override the current protocol selection mechanism in SoapAddressRewriteHelper#getRewrittenPublishedEndpointUrl method, which looks at the protocol in the provided wsdl (if any) and the one for the endpoint address (which is computed considering the transport guarantee specified through either annotations or descriptors). The new option would add a server-wide configuration overriding anything (if set to true, all soap:address location attributes for any endpoint deployed on the server will use https protocol). > This jira implies also adding a new element to the webservices subsystem of the application server. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3785) Add option for forcing https protocol when rewriting soap:addres in WSDL

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3785?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3785: --------------------------------------- Reopened for fixing the JMX integration and enriching JBWS2150TestCase > Add option for forcing https protocol when rewriting soap:addres in WSDL > ------------------------------------------------------------------------ > > Key: JBWS-3785 > URL: https://issues.jboss.org/browse/JBWS-3785 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > In some cases it might be useful having an option in the ServerConfig for forcing the use of https protocol when rewriting the WSDL soap:address. > That would basically override the current protocol selection mechanism in SoapAddressRewriteHelper#getRewrittenPublishedEndpointUrl method, which looks at the protocol in the provided wsdl (if any) and the one for the endpoint address (which is computed considering the transport guarantee specified through either annotations or descriptors). The new option would add a server-wide configuration overriding anything (if set to true, all soap:address location attributes for any endpoint deployed on the server will use https protocol). > This jira implies also adding a new element to the webservices subsystem of the application server. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3785) Add option for forcing https protocol when rewriting soap:addres in WSDL

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3785?page=com.atlassian.jira.plugin.... ] Alessio Soldano reopened JBWS-3785: ----------------------------------- Assignee: Alessio Soldano (was: Jim Ma) > Add option for forcing https protocol when rewriting soap:addres in WSDL > ------------------------------------------------------------------------ > > Key: JBWS-3785 > URL: https://issues.jboss.org/browse/JBWS-3785 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > In some cases it might be useful having an option in the ServerConfig for forcing the use of https protocol when rewriting the WSDL soap:address. > That would basically override the current protocol selection mechanism in SoapAddressRewriteHelper#getRewrittenPublishedEndpointUrl method, which looks at the protocol in the provided wsdl (if any) and the one for the endpoint address (which is computed considering the transport guarantee specified through either annotations or descriptors). The new option would add a server-wide configuration overriding anything (if set to true, all soap:address location attributes for any endpoint deployed on the server will use https protocol). > This jira implies also adding a new element to the webservices subsystem of the application server. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 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: --------------------------------------- Rebecca, are you working on porting the container changes to the 810 container integration layer, so that we can eventually remove JBWS3809TestCase from the 810 exclusions and mark this jira as solved? 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.3.1#6329)

10 years, 3 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 August 2014