Alessio Soldano wrote:
Besides this, it's probably interesting to note that for fixing JBWS-2971 I started using another integration hook, ie. the Spring NamespaceHandlerSupport configuration. As you know, we're generating the jboss-cxf.xml file at deploy time and basically leveraging the spring configuration of CXF (in order to allow both stack agnostic deployments and cxf specific deployments to work seamlessly).
CXF has spring.handler configuration files that map namespaces for elements in the spring xml to default beans. We're now using a custom mapping for the jaxws.endpoint elements, which in the end allows us to overwrite the CXF org.apache.cxf.jaxws.EndpointImpl giving us control over the endpoint start/stop/publish/etc. while still delegating to the CXF one for the core processing.
Generally speaking, customizing the spring namespace handler configuration for loading different bean parsers is a powerful integration hook, to be considered in addition to the already used setup of CXF Configurer in the Bus.
On this topic, please note the changes for JBWS-2995:
- we now have a custom NamespaceHandlerResolver that is installed in the XmlBeanDefinitionReader used for parsing the jboss-cxf.xml file and controls the way Spring maps namespaces to beans. That basically makes sure our NamespaceHandler customizations are considered first, falling back to the default Spring/CXF resolution when there's nothing JBossWS specific. Before this change, the resolution (spring.handler check oreder) was erroneously depending on classloader internals
- we provide a spring.handler configuration file having our customizations only, no need to merge all the single configurations coming from the CXF component jars. As a side effect, this simplifies the upgrade process when a new Apache CXF release is available.