10 Replies Latest reply on Jun 30, 2010 12:50 AM by jim.ma

    Recent changes on CXF integration

    asoldano

      Folks,

      due to the requirements for https://jira.jboss.org/jira/browse/JBWS-2971 , I had to review a bit the current cxf stack integration.

      Basically, we used to depend on CXFServlet triggering the Bus creation and have the servlet's loadBus method overwritten to also load our additional beans from jboss-cxf.xml.

      This recently turned up to be a problem as the CXF Bus creation needs to happen at deploy time for some kind of operation to be possible; JBWS-2971 is an example, but more generally, depending on a servlet only for the bus creation is wrong (think about JMS endpoints, https://jira.jboss.org/jira/browse/JBWS-2987).

      So, first of all I added a deployment aspect in the jbws-cxf stack for eagerly parsing the cxf.xml and our (provided or generated) jboss-cxf.xml into a Bus during deployment (https://jira.jboss.org/jira/browse/JBWS-2974). The Bus is then attached to the endpoint and the CXFServletExt checks it's already available before trying creating it.

      An interesting question now is whether we want this to be the default behaviour or not. Currently there's a system property for choosing when to load the bus, the default is lazy behaviour (load in servlet). Anyway, a decision on this might also be related to how we properly review and fix the jms integration with cxf stack (https://jira.jboss.org/jira/browse/JBWS-2987).

       

      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.

        • 1. Re: Recent changes on CXF integration
          asoldano

          Alessio Soldano wrote:

           


          An interesting question now is whether we want this to be the default behaviour or not. Currently there's a system property for choosing when to load the bus, the default is lazy behaviour (load in servlet).

          I changed the default behaviour, which is now eager load, during deployment.

          The point now is whether we want to support the lazy one, which might be useful on user development environment for speeding up boot with many ws endpooints having http binding.

          • 2. Re: Recent changes on CXF integration
            ropalka

            Good job Alessio. This was real CXF integration improvement we've been missing.

             

            The performance bottleneck during deployment time isn't so significant

            and it can be always solved with using separate worker thread to read

            the CXF configuration file asynchronously when it will became an real issue.

            I'd say we should remove CxfServletExt lazy load of the bus because this is broken

            by design.

            • 3. Re: Recent changes on CXF integration
              jim.ma

              I like your change . It elegently enables other transports support without web.xml.

              There is one use case I can see now to keep the lazy load support : when user specify both the jbossws-cxf.xml and web.xml to create a service  , and there is some configuration item for example "wsdlLocation" in jbossws-cxf.xml needs ServletContextResourceResolver :

              <jaxws:endpoint class="foo.Bar" wsdlLocation="WEB-INF/hello.wsdl"/>

              • 4. Re: Recent changes on CXF integration
                asoldano

                Jim Ma wrote:

                 

                There is one use case I can see now to keep the lazy load support : when user specify both the jbossws-cxf.xml and web.xml to create a service  , and there is some configuration item for example "wsdlLocation" in jbossws-cxf.xml needs ServletContextResourceResolver :

                <jaxws:endpoint class="foo.Bar" wsdlLocation="WEB-INF/hello.wsdl"/>

                This is actually not a problem, as currently the CXFServletExt:

                1) get the bus created during deployment from the endpoint

                2) sets the bus as the thread default

                3) updates the bus with the information coming from the ServletConfig: this includes adding that resource resolver to the resource manager

                4) properly creates and sets the ServletController using the bus

                • 5. Re: Recent changes on CXF integration
                  asoldano

                  Richard Opalka wrote:

                   

                  Good job Alessio. This was real CXF integration improvement we've been missing.

                  Thanks

                   

                  Richard Opalka wrote:

                   

                  The performance bottleneck during deployment time isn't so significant

                  and it can be always solved with using separate worker thread to read

                  the CXF configuration file asynchronously when it will became an real issue.

                  I'd say we should remove CxfServletExt lazy load of the bus because this is broken

                  by design.

                  I'm not that sure regarding the considerations on performances above, anyway I agree on saying the lazy behaviour is broken at least for some usecases. Keeping it is probably going to be a pain and causing confusion with the users.

                  • 6. Re: Recent changes on CXF integration
                    asoldano

                    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.
                    • 7. Re: Recent changes on CXF integration
                      jim.ma
                      Richard Opalka wrote:          The performance bottleneck during deployment time isn't so significant     and it can be always solved with using separate worker thread to read     the CXF configuration file asynchronously when it will became an real issue.     I'd say we should remove CxfServletExt lazy load of the bus because this is broken     by design.

                      I'm not that sure regarding the considerations on performances above, anyway I agree on saying the lazy behaviour is broken at least for some usecases. Keeping it is probably going to be a pain and causing confusion with the users.

                      I found the depends deployment in jboss-web.xml does not work when remove the lazy cxf bus load.  This is because the real deployment work has completely been done in BusDeploymentAspect , and does not count on TomcatDeployer/ServiceDeployer. Do we need to fix this issue?

                      • 8. Re: Recent changes on CXF integration
                        asoldano

                        Jim Ma ha scritto:

                         

                        Richard Opalka wrote:          The performance bottleneck during deployment time isn't so significant     and it can be always solved with using separate worker thread to read     the CXF configuration file asynchronously when it will became an real issue.     I'd say we should remove CxfServletExt lazy load of the bus because this is broken     by design.

                        I'm not that sure regarding the considerations on performances above, anyway I agree on saying the lazy behaviour is broken at least for some usecases. Keeping it is probably going to be a pain and causing confusion with the users.

                        I found the depends deployment in jboss-web.xml does not work when remove the lazy cxf bus load.  This is because the real deployment work has completely been done in BusDeploymentAspect , and does not count on TomcatDeployer/ServiceDeployer. Do we need to fix this issue?

                        You should not need that dependency any more. As discussed on IRC, the need for the JMS destination to be available when building the CXF Bus has to be dealt with either throughproper deployers ordering or dependency using sar/ear.

                        • 9. Re: Recent changes on CXF integration
                          asoldano

                          Another step in improving the integration with Apache CXF comes with JBWS-3038. We're now providing a custom BusFactory that is loaded by default when the jbossws integration is on the classpath. Our bus factory loads the default bus configuration from the jbossws-cxf.xml descriptor in jbossws-cxf-client.jar, allowing us to setup the basic beans loaded in the default bus (both client and server side).

                          The new bus factory also allows us to further remove duplicated cxf descriptors between jbossws jars and apache cxf jars, hence simplifying again the jbossws update when a new version of cxf is available.

                          • 10. Re: Recent changes on CXF integration
                            jim.ma
                            The point now is whether we want to support the lazy one, which might be  useful on user development environment for speeding up boot with many  ws endpooints having http binding.

                            A user ask this question in forum: https://community.jboss.org/message/550294 .  Should we still keep this lazy load  for this use case ?