----------- ----------- References: ----------- ----------- JBossWS Documentation - https://docs.jboss.org/author/display/JBWS/JBoss+Web+Services+Documentation JBossWS 4.0.x & AS 7.x FAQ - http://community.jboss.org/wiki/JBossWS-AS7FAQ Generic JBossWS FAQ - http://community.jboss.org/wiki/JBossWS-FAQ Apache CXF 2.4.x Migration guide - http://cxf.apache.org/docs/24-migration-guide.html ----------- ----------- Dependencies: ----------- ----------- JBossWS 4.0.x main focus is on JBoss AS 7.x and Apache CXF 2.4.x. Since JBossWS 4.0.x is based on Apache CXF 2.4.x series, all user projects that have been heavily using Apache CXF features/extensions have to follow the following migration guide to be 2.4.x series compatible: http://cxf.apache.org/docs/24-migration-guide.html The fundamental change in JBoss AS 7 is its new class loading approach based on JBoss Modules. Since AS 7 is it possible to use e.g. multiple versions of Xalan in different deployments. Because of this feature, all non standard dependencies have to be specified explicitely in user deployments. The following list identifies some Webservices related use cases and provides solutions for them. JAXB --- If user deployment is using JAXB context & impl. classes directly, such deployments need to properly setup a JAXB implementation dependency: Dependencies: com.sun.xml.bind services export JBossWS API & JBossWS SPI --- If user deployment is using JBossWS API or JBossWS SPI classes directly these are always available. There's no need to specify explicit dependency to use them. JBoss Logging --- If user deployment is using JBoss Logging classes directly, such deployment have to define the following dependency: Dependencies: org.jboss.logging JBossWS Common --- If user deployment is using JBossWS common classes directly, such deployment have to define the following dependency: Dependencies: org.jboss.ws.common Apache CXF --- If user deployment is using Apache CXF APIs and implementation classes directly, such deployment have to define the following dependency: Dependencies: org.apache.cxf services JBossWS CXF Client Aggregation module --- If user deployment is using JBossWS CXF client features, such deployment have to define the following dependency: Dependencies: org.jboss.ws.cxf.jbossws-cxf-client services export JBossWS Native --- If user deployment is using legacy JBossWS Native classes directly, such deployment have to define the following dependency: Dependencies: org.jboss.ws.native.jbossws-native-core ----------- ----------- JBossWS API project changes ----------- ----------- JBossWS 4.0.x differs from JBossWS 3.4.x in the following way. JBossWS SPI have been split to JBossWS API, JBossWS SPI and JBossWS Common Tools projects. JBossWS Common have been split to JBossWS Common, JBossWS API and JBossWS Shared Test Suite modules. Part of this process are also the following changes. Package refactoring: [JBossWS SPI] org.jboss.wsf.spi.annotation.* -> [JBossWS API] org.jboss.ws.api.annotation.* [JBossWS SPI] org.jboss.wsf.spi.binding.* -> [JBossWS API] org.jboss.ws.api.binding.* [JBossWS SPI] org.jboss.wsf.spi.management.recording.* -> [JBossWS API] org.jboss.ws.api.monitoring.* [JBossWS SPI] org.jboss.wsf.spi.tools.* -> [JBossWS API] org.jboss.ws.api.tools.* [JBossWS SPI] org.jboss.wsf.spi.tools.ant.* -> [JBossWS Common Tools] org.jboss.ws.tools.ant.* [JBossWS SPI] org.jboss.wsf.spi.tools.cmd.* -> [JBossWS Common Tools] org.jboss.ws.tools.cmd.* [JBossWS SPI] org.jboss.wsf.spi.deployment.Deployment$DeploymentType -> [JBossWS SPI] org.jboss.wsf.spi.deployment.DeploymentType [JBossWS SPI] org.jboss.wsf.spi.deployment.Deployment$DeploymentState -> [JBossWS SPI] org.jboss.wsf.spi.deployment.DeploymentState [JBossWS SPI] org.jboss.wsf.spi.util.ServiceLoader -> [JBossWS API] org.jboss.ws.api.util.ServiceLoader [JBossWS Common] org.jboss.wsf.common.* -> [JBossWS Common] org.jboss.ws.common.* [JBossWS Common] org.jboss.wsf.common.handler.* -> [JBossWS API] org.jboss.ws.api.handler.* [JBossWS Common] org.jboss.wsf.common.addressing.* -> [JBossWS API] org.jboss.ws.api.addressing.* [JBossWS Common] org.jboss.wsf.common.DOMUtils -> [JBossWS API] org.jboss.ws.api.util.DOMUtils [JBossWS Native] org.jboss.ws.annotation.EndpointConfig -> [JBossWS API] org.jboss.ws.api.annotation.EndpointConfig Removed packages (no alternative available to workaround it): -------------------------------------------------- [JBossWS SPI] org.jboss.wsf.spi.ioc.* [JBossWS SPI] org.jboss.wsf.spi.deployment.integration.* [JBossWS SPI] org.jboss.wsf.spi.metadata.injection.* Removed classes (no alternative available to workaround it): -------------------------------------------------- [JBossWS SPI] org.jboss.wsf.spi.deployment.SecurityHandler [JBossWS SPI] org.jboss.wsf.spi.metadata.j2ee.MDBMetaData [JBossWS SPI] org.jboss.wsf.spi.metadata.j2ee.PortComponentMD [JBossWS SPI] org.jboss.wsf.spi.metadata.j2ee.PortComponentSpec [JBossWS SPI] org.jboss.wsf.spi.metadata.j2ee.serviceref.HandlerChainsObjectFactory [JBossWS SPI] org.jboss.wsf.spi.metadata.jms.JMSDescriptorParser [JBossWS SPI] org.jboss.wsf.spi.metadata.jms.JMSDescriptorProcessor [JBossWS SPI] org.jboss.wsf.spi.metadata.jms.JMSEndpointsFactory [JBossWS SPI] org.jboss.wsf.spi.util.Log4jOutputStream [JBossWS SPI] org.jboss.wsf.spi.util.Log4JUtil [JBossWS SPI] org.jboss.wsf.spi.metadata.webservices.WebservicesDescriptorProcessor [JBossWS SPI] org.jboss.wsf.spi.deployment.ServletClassProvider [JBossWS SPI] org.jboss.wsf.spi.metadata.DescriptorProcessor Removed methods (no alternative available to workaround it): -------------------------------------------------- [JBossWS SPI] org.jboss.wsf.spi.deployment.ArchiveDeployment.getMetaDataFileURL(String) [JBossWS SPI] org.jboss.wsf.spi.deployment.DeploymentModelFactory.newEndpoint(String) [JBossWS SPI] org.jboss.wsf.spi.deployment.Endpoint.getURLPattern() [JBossWS SPI] org.jboss.wsf.spi.deployment.Endpoint.setURLPattern(String) [JBossWS SPI] org.jboss.wsf.spi.deployment.Endpoint.getJNDIContext() [JBossWS SPI] org.jboss.wsf.spi.metadata.webservices.PortComponentMetaData.setSecureWSDLAccess(Boolean) [JBossWS SPI] org.jboss.wsf.spi.metadata.webservices.PortComponentMetaData.getSecureWSDLAccess() [JBossWS SPI] org.jboss.wsf.spi.metadata.webservices.PortComponentMetaData.setEnableMtom(boolean) [JBossWS SPI] org.jboss.wsf.spi.metadata.webservices.PortComponentMetaData.isEnableMtom() [JBossWS SPI] org.jboss.wsf.spi.metadata.jms.JMSEndpointsMetaData.JMSEndpointsMetaData(URL) [JBossWS SPI] org.jboss.wsf.spi.metadata.jms.JMSEndpointsMetaData.getDescriptorURL() [JBossWS SPI] org.jboss.wsf.spi.metadata.j2ee.serviceref.UnifiedPortComponentRefMetaData.setAddressingAnnotationSpecified(boolean) [JBossWS SPI] org.jboss.wsf.spi.metadata.j2ee.serviceref.UnifiedPortComponentRefMetaData.isAddressingAnnotationSpecified() [JBossWS SPI] org.jboss.wsf.spi.metadata.j2ee.serviceref.UnifiedPortComponentRefMetaData.setRespectBindingAnnotationSpecified(boolean) [JBossWS SPI] org.jboss.wsf.spi.metadata.j2ee.serviceref.UnifiedPortComponentRefMetaData.isRespectBindingAnnotationSpecified() [JBossWS SPI] org.jboss.wsf.spi.metadata.j2ee.serviceref.UnifiedPortComponentRefMetaData.setEnableMTOM(Boolean) [JBossWS SPI] org.jboss.wsf.spi.metadata.j2ee.serviceref.UnifiedPortComponentRefMetaData.getEnableMTOM() [JBossWS SPI] org.jboss.wsf.spi.invocation.InvocationHandler.getJNDIContext(Endpoint) [JBossWS SPI] org.jboss.wsf.spi.invocation.SecurityAdaptor.pushSubjectContext(Subject,Principal,Object) ----------- ----------- @WebContext annotation ----------- ----------- In JBossWS 3.4.x there used to be org.jboss.wsf.spi.annotation.WebContext annotation in JBossWS SPI project. Since JBossWS 4.0.x this annotation was moved to org.jboss.ws.api.annotation.WebContext in JBossWS API project. Thus user deployments that have been using this feature, need to rename the dependency package in their source code and compile it against new JBossWS API jar. There's also one non backward compatible change in that annotation. The 'String[] virtualHosts' attribute was changed to 'String virtualHost'. In other words since JBoss AS7 it's possible to specify only one virtual host per deployment. If there are multiple webservices using @WebContext annotation and specifying virtualHost there, this virtualHost value must be identical for all endpoints defined in the deployment archive. ----------- ----------- jboss-webservices.xml descriptor ----------- ----------- There was introduced new descriptor in JBossWS 4.0.x series. Its name is jboss-webservices.xml and it's a partial replacement for obsolete jboss.xml. The expected location of this descriptor is: * META-INF/jboss-webservices.xml for EJB webservice deployments * WEB-INF/jboss-webservices.xml for POJO webservice deployments EJB webservice endpoints bundled in .war The structure of that file is the following: ? ? ? * ? ? ? ? * ? element --- Element can be used to customize context root of webservices deployment. It is a replacement for jboss.xml webservices/context-root element. For example: In JBossAS 6.x series users used to provide jboss.xml with the following content: foo Since JBossAS 7.x users have to provide jboss-webservices.xml file instead with the following content: foo and elements --- Elements and can be used to associate legacy JBossWS Native configurations with user deployment. In JBossAS 6.x series users used to provide jboss.xml with the following content: TestService Standard WSSecurity Endpoint META-INF/custom.xml Since JBossAS 7.x users have to provide jboss-webservices.xml file instead with the following content: Standard WSSecurity Endpoint META-INF/custom.xml element --- Element can be used to customize EJB endpoint target URI or to configure security related properties. In JBossAS 6.x series users used to provide jboss.xml with the following content: TestService TestServicePort /* BASIC NONE true Since JBossAS 7.x users have to provide jboss-webservices.xml file instead with the following content: TestService TestServicePort /* BASIC NONE true element --- Element can be used to customize (override) webservice WSDL publish location. In JBossAS 6.x series users used to provide jboss.xml with the following content: TestService file:///bar/foo.wsdl Since JBossAS 7.x users have to provide jboss-webservices.xml file instead with the following content: TestService file:///bar/foo.wsdl