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