1 2 Previous Next 15 Replies Latest reply on May 5, 2010 7:22 AM by Richard Opalka

    CXF jms integration

    Jim Ma Apprentice

      After looked at Alessio's work about cxf descriptor deployment and lazy bus load removal , I'd like to discuss with you about my thoughts about jms integration. Here is what in my mind so far .As we talked before , we need to introduce other deployer or deployerAspect to make cxf stack directly deploy/load jbossws-cxf.xml. IMO, the easy approach to implement this is adding several real stage deployers to the current deployer chain to take care of the jms deployment without web.xml:

       

      `--org.jboss.webservices.integration.deployers.WSEJBAdapterDeployer@4007f4
      `--org.jboss.webservices.integration.deployers.WSTypeDeployer@d6f833
      `--org.jboss.webservices.integration.deployers.WSDeploymentDeployer@103ddfd
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1279d82(org.jboss.wsf.framework.deployment.EndpointMetricsDeploymentAspect@b77801)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1fa6e43(org.jboss.webservices.integration.metadata.ContainerMetaDataDeploymentAspect@1e7c7fb)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@fcc66a(org.jboss.wsf.framework.deployment.EndpointHandlerDeploymentAspect@18b3f9a)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@124a94(org.jboss.wsf.framework.deployment.BackwardCompatibleContextRootDeploymentAspect@6fcd57)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@4aba6a(org.jboss.wsf.framework.deployment.URLPatternDeploymentAspect@fb39f6)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@8d69f8(org.jboss.wsf.framework.deployment.EndpointAddressDeploymentAspect@13bf9ce)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1f99aa6(org.jboss.wsf.framework.deployment.EndpointNameDeploymentAspect@929ed4)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1f8a03f(org.jboss.wsf.framework.deployment.VirtualHostDeploymentAspect@4a9acb)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@e9635a(org.jboss.wsf.framework.deployment.JAXBIntroDeploymentAspect@12cebd2)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1744996(org.jboss.wsf.stack.cxf.deployment.aspect.DescriptorDeploymentAspect@1e890b4)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@864ae7(org.jboss.wsf.stack.cxf.deployment.aspect.ResourceResolverDeploymentAspect@1214a13)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@4fdf56(org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect@79bca4)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@6e1cbf(org.jboss.wsf.framework.deployment.ContextPropertiesDeploymentAspect@827b51)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@786a44(org.jboss.webservices.integration.tomcat.WebMetaDataCreatingDeploymentAspect@c9f31e)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1850507(org.jboss.webservices.integration.tomcat.WebMetaDataModifyingDeploymentAspect@b6cddb)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1ee86f2(org.jboss.webservices.integration.security.JACCPermissionsDeploymentAspect@1ec0b9d)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@31613(org.jboss.webservices.integration.injection.InjectionMetaDataDeploymentAspect@182ac61)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1d61032(org.jboss.wsf.framework.deployment.EndpointRegistryDeploymentAspect@d91c60)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1d37602(org.jboss.wsf.framework.deployment.EndpointRecordProcessorDeploymentAspect@9f987a)
      `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1a30367(org.jboss.wsf.framework.deployment.EndpointLifecycleDeploymentAspect@1bb1dd2

      + org.jboss.wsf.stack.cxf.deployment.JBossWSCXFMetaDataDeployer(to parse the jbossws-cxf.xml and create JBossWSCXFMetaData)
      + org.jboss.wsf.stack.cxf.deployment.JBossWSCXFJAXBIntroDeploymentDeployer(to do the jaxb databinding customization)
      + org.jboss.wsf.stack.cxf.deployment.JBossWSCXFDeploymentBuilderDeployer(to create deployment, service and endpoint etc)
      + org.jboss.wsf.stack.cxf.deployment.JBossWSCXFDeploymentDeployer(to let the cxf bus load the jbossws-cxf.xml)
      + org.jboss.wsf.stack.cxf.deployment.JBossWSCXFEndpointRegistryDeployer(to register the endpoint)

       

      I marked the new add deployer with "+" prefix and these new add deployers will be put the end of the DeploymentAspect deplyers.    As you can see ,there will be some duplicate work/code in the these deployers with above DeploymentAspects. But it makes the deployer structure  more clear and these new added deployers are dedicated to handle the jms deployment and other stack specific deployment without web.xml.

       

      The another option is we handle it both in integration layer and cxf stack : 1. Create a unified MetaData/holder to reprsent or place the stack specific deployment :jbossws-cxf.xml.  2. Modify the WSDeploymentDeployer to handle the deployment without JBossWebMetaData  3. Add the code in the current DepoymentAspects ,for example EndpointHandlerDeploymentAspect, DescriptorDeploymentAspect and BusDeploymentAspectin to process the stack specific deployment (without web.xml).   We can put the code to process the cxf jms deployment in each DeploymentAspect, so this approach will reuse the function in each deployment aspect.This will change a lot in current integration layer and deployers framework and it's a little bit complex. 

       

      After the comparison, I prefer to the first approach. Because at the moment, only cxf has this requirement to deploy stack specific deployment. And it is also simple :only adding some new additional deployers for cxf stack can make it work . It will not impact the other components : integration layer , spi and framework codebase.

       

      You thoughts ?

        • 1. Re: CXF jms integration
          Richard Opalka Master

          Abbreviations:

          * CXF - CXF integration layer

          * ASIL - JBossWS Application Server Integration Layer

          * SPI - JBossWS SPI - the only dependency reused cross different JBossWS abstractions

          * DA - JBossWS Deployment Aspect

          * UMDM - JBossWS Universal Meta Data Model

          * JMS MD - AS JMS Meta Data

          * AS API - compilation dependency on AS API classes

          * IAC - in any case

           

          Hi Jim,

           

             first approach is fundamentally wrong because:

          * it would violate our abstractions

          * it wouldn't reuse existing code/architecture

           

          We cannot introduce JBossWSCXF*Deployers because we would introduce CXF -> AS API dependency. Only allowed dependency

          is CXF -> SPI. This is because AS architecture can/will change over time and we want to be AS agnostic IAC.

           

          Yes, the solution 2 is little bit more complex one but we should always follow the golden programmers rule:

          Either do it properly or don't do it at all (otherwise our code would become unmaintanable in the future).


          Here are my suggestions how we should proceed with approach 2

          (ensures proper abstractions, dependencies and code/architecture reuse):

          * extend our UMDM (located in SPI) to provide JMS endpoint abstractions

          * extend our DA framework to distinguish DA aspects intended to create web based endpoints and jms based endpoints

          * update our ASIL (concretely WSDeploymentAspectDeployer) to distinguish between Web DAs and JMS DAs

          * implement CXF DA that will map jboss-cxf.xml MD to our UMDM (ensures CXF -> SPI dependency)

          * implement ASIL DA that will create JMS MD from our UMDM (ensures ASIL -> SPI dependency)

          * implement CXF DA that will register plain JMS endpoints with CXF (ensures CXF -> SPI dependency)

          • 2. Re: CXF jms integration
            Alessio Soldano Master

            Right, we need proper integration through SPI here. The point is that we need to trigger destination (queue) creation during deployment. That is done using the API a given AS container provides; for instance on AS trunk, right now we'd probably end up creating a configuration for HornetQ to be used by HornetQ deployers (HornetQCoreConfigRealDeployer ?).

            As Richard's correctly saying, we should not use those AS API directly in JBWS CXF in order to maintain proper abstraction, so we need to enrich the JBossWS SPI (few additions in org.jboss.wsf.spi.deployment might be enough) for having those info (it's probably just the name of the destinations) available in a container independent way. That part of the SPI could be populated by CXF specific deployment aspect that parses the provided or generated jboss-cxf.xml.

            Later in the chain, we'd have another deployment aspect (coming from the container integration) that uses the new SPI info to create the JMS medatadata (HornetQ conf, for isntance) and provides the requirements for the JMS deployers to run.

             

            All this assumes we review the current WSDeploymentAspectDeployer that forces every deployment aspect to be bound to the web deployers, given the JBossWebMetaData input/ouput. I imagine some minor changes might also be required a bit earlier in the deployer chain.

             

            Jim, I'd encourage you to create branches like a did when working on cxf/jaxrpc issue and start doing changes there. Either Richard or me can help you step by step there, till we have something working that can be merged to trunk. This way you can also start now that 3.3.0 is not released yet (this work is targeted for 4.x)

            • 3. Re: CXF jms integration
              Alessio Soldano Master

              A possible additional issue I can see is that the when the BusDeploymentAspect kicks in, the Bus creation process requires the jms destinations to be already available (did not look at the CXF internals here yet), so the deployers ordering might need additional reasoning changes. It's probably worth checking this early.

              • 4. Re: CXF jms integration
                Jim Ma Apprentice

                Right, we need proper integration through SPI here. The point is that  we need to trigger destination (queue) creation during deployment. That  is done using the API a given AS container provides; for instance on AS  trunk, right now we'd probably end up creating a configuration for  HornetQ to be used by HornetQ deployers (HornetQCoreConfigRealDeployer  ?).

                As Richard's correctly saying, we should not use those AS API  directly in JBWS CXF in order to maintain proper abstraction, so we need  to enrich the JBossWS SPI (few additions in  org.jboss.wsf.spi.deployment might be enough) for having those info  (it's probably just the name of the destinations) available in a  container independent way. That part of the SPI could be populated by  CXF specific deployment aspect that parses the provided or generated  jboss-cxf.xml.

                Later in the chain, we'd have another deployment  aspect (coming from the container integration) that uses the new SPI  info to create the JMS medatadata (HornetQ conf, for isntance) and  provides the requirements for the JMS deployers to run.

                IMHO, we do not need to provide the function to trigger the desination creation. We always assume that user already have this Queue/Topic deployed before webservice jms endpoint deployment or the jms deployment is deployed with jms endpoint, like how the  MDB is deployed.

                 

                All this assumes we review the current WSDeploymentAspectDeployer that  forces every deployment aspect to be bound to the web deployers, given  the JBossWebMetaData input/ouput. I imagine some minor changes might  also be required a bit earlier in the deployer chain.

                Agreed. The WSDeploymentAspectDeployer is one of the key class we need to think about how to change its behavior and handle other deployment without  JBossWebMetaData input/output.

                At the moment , I think parsing the jms endpoint deployment descirptor (like jbossws-endpoint.xml) and creating the service and endpoint work should be put in front of   WSDeploymentAspectDeployer chain.  I am analysing it more to see what else we need to change .

                 

                Jim, I'd encourage you to create branches like a did when working on  cxf/jaxrpc issue and start doing changes there. Either Richard or me can  help you step by step there, till we have something working that can be  merged to trunk. This way you can also start now that 3.3.0 is not  released yet (this work is targeted for 4.x)

                Will do.

                 

                Thanks.

                • 5. Re: CXF jms integration
                  Jim Ma Apprentice
                  A possible additional issue I can see is that the when the BusDeploymentAspect kicks in, the Bus creation process requires the jms destinations to be already available (did not look at the CXF internals here yet), so the deployers ordering might need additional reasoning changes. It's probably worth checking this early.

                  Yes. CXF needs the jms destination is available when the endpoint is published. That's another point we need to take into account when order these deployers.

                  • 6. Re: CXF jms integration
                    Richard Opalka Master

                    jim.ma wrote

                     

                    IMHO, we do not need to provide the function to trigger the desination creation. We always assume that user already have this Queue/Topic deployed before webservice jms endpoint deployment or the jms deployment is deployed with jms endpoint, like how the  MDB is deployed.

                     

                    Yes, you can provide initial test cases without this Queue/Topic abstraction in our SPI

                    • 7. Re: CXF jms integration
                      Alessio Soldano Master

                      Hi Jim,
                      I've taken a look at what you did in your jms-integration branches and have some questions / concers I'd like to discuss here. First of all let me summarize what you've done, so we're sure that we're all on the same page.
                      You basically added a deployment descriptor (jbossws-endpoints.xml) parsing that produces some new metadata in SPI (org.jboss.wsf.spi.metadata.endpoints.EndpointsMetaData). Those are later attached to the Deployment and used by EndpointsDescriptorsDeploymentAspect (cxf stack) to produce an instance of org.jboss.wsf.spi.metadata.endpoints.AbstractEndpointsDeployment (namely org.jboss.wsf.stack.cxf.deployment.CXFEndpointsDeployment), with a spring configuration file generated from the metadata. CXFEndpointsDeployment is later deployed by the KernelDeploymentDeployer and is responsible for generating the CXF Bus through the BusHolder, creating a new spi endpoint and adding it to the registry. Before handing over to the KernelDeploymentDeployer, the WSEndpointsRealDeployer (container integration) sets the proper depedencies for ensuring the bean is deployed after any JMS destination bean attached to the current deployment unit.

                       

                      This said, here are my comments:
                      * jbossws-endpoints.xml: generally speaking, I would allow users to avoid providing that in most cases. AFAICS, the reason for that file is just in getting the information on which jms destinations are to be used for the endpoints included in the deployment. I think this can also be specified through a user provided jboss-cxf.xml, hence we need to allow for that too. Moreover, something else we should probably evaluate implementing (perhaps in CXF?) is an annotation for setting those destinations on the endpoint class (@JMSTransport or something like that). That said, yes, a user might still want to use xml for providing that info, in which case a configuration file like jbossws-endpoints.xml is fine. But I'd make that more JMS specific, as there's no need for it being generally for every endpoints, given http endpoints already have all the means of configuration in jbossws. So probably something like jms-endpoints.xml should be ok. Also the metadata naming should probably be reviewed
                      * new SPI metadata: besides the naming not completely convincing me, I think the few info we need (jms destination addresses currently) should live at the Endpoint level, not higher than that and separated from that as they currently are in jms-integration branch. Jim, did you evaluate having a hierarchy for the SPI Endpoint (with the current one becoming HttpEndpoint and a new JMSEndpoint having the destinations' info)? Still on this topic, we might probably create the SPI JMSEndpoint at the same time as the Http one (currently the WSDeploymentBuilder::build seems to me to be creating the Deployment only, while the Endpoint is actually created later by the CXFEndpointsDeployment). The CXFEndpointsDeployment should probably just do the endpoint registration (perhaps even that can unified..?), with already existing spi endpoints
                      * WSEndpointsReadDeployer: while I was not able to think about this solution before for the destinations dependency management, what I don't like here is that it's not part of our DA group. Where does it run in the deployers' chain? can we unify things here (make it a DA)?
                      * do you already know whether the proposed architecture is going to work with CXF 2.3 SOAP-over-JMS-1.0 support too (http://cxf.apache.org/docs/soap-over-jms-10-support.html)?
                      Thanks

                      • 8. Re: CXF jms integration
                        Jim Ma Apprentice
                        Hi Jim, I've taken a look at what you did in your jms-integration branches and have some questions / concers I'd like to discuss here. First of all let me summarize what you've done, so we're sure that we're all on the same page. You basically added a deployment descriptor (jbossws-endpoints.xml) parsing that produces some new metadata in SPI (org.jboss.wsf.spi.metadata.endpoints.EndpointsMetaData). Those are later attached to the Deployment and used by EndpointsDescriptorsDeploymentAspect (cxf stack) to produce an instance of org.jboss.wsf.spi.metadata.endpoints.AbstractEndpointsDeployment (namely org.jboss.wsf.stack.cxf.deployment.CXFEndpointsDeployment), with a spring configuration file generated from the metadata. CXFEndpointsDeployment is later deployed by the KernelDeploymentDeployer and is responsible for generating the CXF Bus through the BusHolder, creating a new spi endpoint and adding it to the registry. Before handing over to the KernelDeploymentDeployer, the WSEndpointsRealDeployer (container integration) sets the proper depedencies for ensuring the bean is deployed after any JMS destination bean attached to the current deployment unit.

                        Thanks for the comments and ideas. Yes.  We are in the same page .


                        * jbossws-endpoints.xml: generally  speaking, I would allow users to avoid providing that in most cases.  AFAICS, the reason for that file is just in getting the information on  which jms destinations are to be used for the endpoints included in the  deployment. I think this can also be specified through a user provided  jboss-cxf.xml, hence we need to allow for that too.

                        There are following reasons I named it to general jbossws-endpoint.xml and not jms-endpoints.xml:

                        a) Considering our spi framework and IL architecture, we can only creat the deployer in IL . That means the deployer is stack neutral and it should not only parse/deploy the stack specific deployment descriptor : for example jboss-cxf.xml.

                         

                        b) There are other transports supported in CXF : invm, jbi.  We can extend this file to support them .  So it is only for jms transport .

                         

                        c) Combine our features (eg, jaxbintro configuration xml) and  jbossws-endpoint.xml to generated CXF deployment configuraiton.  

                         

                        Moreover, something  else we should probably evaluate implementing (perhaps in CXF?) is an  annotation for setting those destinations on the endpoint class  (@JMSTransport or something like that). That said, yes, a user might  still want to use xml for providing that info, in which case a  configuration file like jbossws-endpoints.xml is fine.

                        Good point . This is my fourth reason to name it jbossws-endpoints.xml.  The jms configuration can be defined in wsdl file, so user only need to specify the endpoint class name to deploy jms endpoints in CXF.   We also need use this to enable the soap over jms in CXF .

                         

                        * new SPI metadata: besides the naming not completely convincing me, I  think the few info we need (jms destination addresses currently) should  live at the Endpoint level, not higher than that and separated from that  as they currently are in jms-integration branch. Jim, did you evaluate  having a hierarchy for the SPI Endpoint (with the current one becoming  HttpEndpoint and a new JMSEndpoint having the destinations' info)?

                         

                        I evaluated to make new SPI metadata to extend the current SPI Endpoint.  But I did not find benifit from it, as our DeploymentAspects was intended to process the SPI HttpEndpoint. It can

                        not be reused to process JMSEndpoint too.  Now I took the new SPI metadata as flag to dispatch the jms endpoint deployment . New created DeploymentAspect to deploy the jms endpoint  and old DeploymentAspects to deploy  http endpoint .

                        Still  on this topic, we might probably create the SPI JMSEndpoint at the same  time as the Http one (currently the WSDeploymentBuilder::build seems to  me to be creating the Deployment only, while the Endpoint is actually  created later by the CXFEndpointsDeployment). The CXFEndpointsDeployment  should probably just do the endpoint registration (perhaps even that  can unified..?), with already existing spi endpoints

                        This is because the jms SPI Endpoint does not need the exsiting DeploymentAspect to process, and jms SPI Endpoint is created just for registry, and it's in different deploy flow.  Do you see any other points we need to unify  and reuse DeploymentAspect ?

                        * WSEndpointsReadDeployer: while I was not able to think about this  solution before for the destinations dependency management, what I don't  like here is that it's not part of our DA group. Where does it run in  the deployers' chain? can we unify things here (make it a DA)?

                        It is running after the last  DeploymentAspectDeployer and before KernelDeploymentDeployer. It's not possible to unify it to a DA.  It needs the As dependency to create a BeanMetaData. 

                        * do you already know whether the proposed architecture is going  to work with CXF 2.3 SOAP-over-JMS-1.0 support too (http://cxf.apache.org/docs/soap-over-jms-10-support.html)?

                        Yes. It supports the soap-over-jms. The current deployer architcture supports to deploy the endpoint class with wsdl file .

                        I also uses the "soap-over-jms spec" style jms address to reprents the endpoint address for spec "alignment" .

                        • 9. Re: CXF jms integration
                          Alessio Soldano Master

                          Jim Ma wrote:


                          * jbossws-endpoints.xml: generally  speaking, I would allow users to avoid providing that in most cases.  AFAICS, the reason for that file is just in getting the information on  which jms destinations are to be used for the endpoints included in the  deployment. I think this can also be specified through a user provided  jboss-cxf.xml, hence we need to allow for that too.

                          There are following reasons I named it to general jbossws-endpoint.xml and not jms-endpoints.xml:

                          a) Considering our spi framework and IL architecture, we can only creat the deployer in IL . That means the deployer is stack neutral and it should not only parse/deploy the stack specific deployment descriptor : for example jboss-cxf.xml.

                          OK, I see what you mean regarding the parsing deployer having to be in IL, you can just have DA in JBWS-CXF and those can't access container specific stuff. That's fine. I'm saying, however, that a user can just deploy his jboss-cxf.xml with jms endpoints and expect the information there to be picked up, regardless of the jbossws-endpoints.xml which he can of course avoid providing (why having multiple descriptors when we can just use the cxf one? do we *really* need that?). So, one of my points is, why don't we just avoid using that jbossws-endpoints.xml and parse the jboss-cxf.xml in a DA, populating the extended SPI metadata? What I'm missing here?

                           

                          I think what Richard wrote was a good starting point, perhaps I'm missing some issues?

                           

                          * extend our UMDM (located in SPI) to provide JMS endpoint abstractions

                          * extend our DA framework to distinguish DA aspects intended to create web based endpoints and jms based endpoints

                          * update our ASIL (concretely WSDeploymentAspectDeployer) to distinguish between Web DAs and JMS DAs

                          * implement CXF DA that will map jboss-cxf.xml MD to our UMDM (ensures CXF -> SPI dependency)

                          * implement ASIL DA that will create JMS MD from our UMDM (ensures ASIL -> SPI dependency)

                          * implement CXF DA that will register plain JMS endpoints with CXF (ensures CXF -> SPI dependency)

                           

                          b) There are other transports supported in CXF : invm, jbi.  We can extend this file to support them .  So it is only for jms transport .

                          Yes, right. The problem is that http transport is not going to be configured in that jbossws-endpoints.xml as that's completely done with the already existing jboss/javaee descriptors + (optional and just if you're using cxf) jboss-cxf.xml. So it's a kind of overlap.

                          While, in the long term, I agree with you it most probably makes sense to have a jbossws common way of configuring the jms transport even if that can already be done with cxf stack through jboss-cxf.xml, I still believe that:

                          - we don't need that for http transport, as we already have full means of configuration; moreover we need to keep things simple (in terms of user configuration)

                          - support for jms endpoint definition in jboss-cxf.xml is required

                          - we're not probably going to have invm and/or jbi transport with other stacks, so supporting them through cxf specific configuration only might be reasonable as far as we know today

                          c) Combine our features (eg, jaxbintro configuration xml) and  jbossws-endpoint.xml to generated CXF deployment configuraiton.  

                          OK, I agree we need to have features like jaxbintro available with jms endpoints too. Good.

                          What I don't like is the need to configuring this in another descriptor (jbossws-endoints.xml), while that configuration already goes to jaxbintros.xml (which is stack neutral and used in other projects external to jbossws) and is already integrated in jbossws. Being able to simply go on using the already existing JaxbIntro DA for that should be the way to go here. We have to minimize the need of duplicated configuration and implementation of features for different transport.

                          Moreover, something  else we should probably evaluate implementing (perhaps in CXF?) is an  annotation for setting those destinations on the endpoint class  (@JMSTransport or something like that). That said, yes, a user might  still want to use xml for providing that info, in which case a  configuration file like jbossws-endpoints.xml is fine.

                          Good point . This is my fourth reason to name it jbossws-endpoints.xml.  The jms configuration can be defined in wsdl file, so user only need to specify the endpoint class name to deploy jms endpoints in CXF.   We also need use this to enable the soap over jms in CXF .

                          I probably need to see a testcase with this usecase first, before commenting here.

                           

                          * new SPI metadata: besides the naming not completely convincing me, I  think the few info we need (jms destination addresses currently) should  live at the Endpoint level, not higher than that and separated from that  as they currently are in jms-integration branch. Jim, did you evaluate  having a hierarchy for the SPI Endpoint (with the current one becoming  HttpEndpoint and a new JMSEndpoint having the destinations' info)?

                           

                          I evaluated to make new SPI metadata to extend the current SPI Endpoint.  But I did not find benifit from it, as our DeploymentAspects was intended to process the SPI HttpEndpoint. It can

                          not be reused to process JMSEndpoint too.  Now I took the new SPI metadata as flag to dispatch the jms endpoint deployment . New created DeploymentAspect to deploy the jms endpoint  and old DeploymentAspects to deploy  http endpoint .

                          Well, the benefits is in a cleaner SPI. The existing DA meant for http endpoint will start requiring http endpoints, I think that's fine. We might also introduce a concept of http DA and jms DA, as Richard mentioned before.

                          Regarding that being used as a flag for dispatching to the JMS DA/deployers, sure, I agree you need some kind of flags, but nothing prevents you from basing the check on the endpoint's type.

                           

                          Still  on this topic, we might probably create the SPI JMSEndpoint at the same  time as the Http one (currently the WSDeploymentBuilder::build seems to  me to be creating the Deployment only, while the Endpoint is actually  created later by the CXFEndpointsDeployment). The CXFEndpointsDeployment  should probably just do the endpoint registration (perhaps even that  can unified..?), with already existing spi endpoints

                          This is because the jms SPI Endpoint does not need the exsiting DeploymentAspect to process, and jms SPI Endpoint is created just for registry, and it's in different deploy flow.  Do you see any other points we need to unify  and reuse DeploymentAspect ?

                          No, at least not now. But as I mentioned above, we need to try minimizing the duplication, hence make possible to use the same DA when they're not specific to a given transport.

                          Generally speaking, deployment aspect could be modified so that they do actuall processing on the endpoint type they're meant for.

                           

                          * WSEndpointsReadDeployer: while I was not able to think about this  solution before for the destinations dependency management, what I don't  like here is that it's not part of our DA group. Where does it run in  the deployers' chain? can we unify things here (make it a DA)?

                          It is running after the last  DeploymentAspectDeployer and before KernelDeploymentDeployer. It's not possible to unify it to a DA.  It needs the As dependency to create a BeanMetaData.

                          OK, understood, thanks. We can probably investigate and deal with this as a further optimization step later.

                           

                          * do you already know whether the proposed architecture is going  to work with CXF 2.3 SOAP-over-JMS-1.0 support too (http://cxf.apache.org/docs/soap-over-jms-10-support.html)?

                          Yes. It supports the soap-over-jms. The current deployer architcture supports to deploy the endpoint class with wsdl file .

                          I also uses the "soap-over-jms spec" style jms address to reprents the endpoint address for spec "alignment" .

                          Excellent, thanks. I think this might fall in the point above where I said I'd need to see a testcase... in that case we'll get back to this topic.

                          • 10. Re: CXF jms integration
                            Richard Opalka Master

                            Hi Jim,

                             

                                let me agree with Alessio. We really don't need to introduce
                            another DD (jbossws-endpoints.xml namely). There are two reasons for that:
                            * XML configuration duplicity (as Alessio properly said users can just provide jbossws-cxf.xml with all the configuration)
                            * simplicity (our current SPI facade should be enough for you to do the job).

                             

                            What you're doing (providing jbossws-endpoints.xml) is just creating WS stack agnostic configuration.
                            But our SPI is intended exactly for that purpose.
                            Providing additional DD is the same thing like our SPI (just different XML-ized form of it).

                             

                            If you will follow my suggestions I wrote few days before you shoudn't face "real" problems.

                             

                            Another thing/issue is our SPI is not perfect (and we know that).
                            We will improve/rewrite our SPI once we'll be done with all the
                            highier priority tasks we have these days.

                             

                            Jim Ma wrote:
                                I evaluated to make new SPI metadata to extend the current SPI Endpoint.  But I did not find benifit from it, as our DeploymentAspects was intended to process the SPI HttpEndpoint. It can not be reused to process JMSEndpoint too.

                             

                            Let me disagree. This is the way you had to go IMHO

                             

                            We need these abstractions in our SPI:
                            * Endpoint
                               - ServletEndpoint -> url address
                               - JMSEndpoint -> jms address
                            * DA
                               - ServletDA
                               - JMSDA

                             

                            Our ASIL deployers will accept DA abstraction
                            and will be able to distinguish between HTTP and JMS.
                            In deployer, before specifying inputs/outputs,
                            you should have code like this:

                             

                            // pseudocode ensuring proper deployers ordering
                            if (DA instanceof ServletDA) {
                              this.addInput(WebMetaData.class);
                              ...
                            } else if (DA instanceof JMSDA) {
                              this.addInput(JMSMetaData.class);
                              ...
                            }

                             

                            Both HTTP and JMS endpoints should use the same deployers flow.
                            Don't create another deployer flow just for JMS endpoints.
                            but reuse our current architeture.

                            • 11. Re: CXF jms integration
                              Jim Ma Apprentice

                              Thanks Alessio and Richard's comments again . Let me summarize our discussion points first , then I will give the issues I can see from my previous experimental work on cxf/jms integration in past two weeks, then you and Richard can continue to add your thoughts and comments:

                               

                              1)  Use jbossws-cxf.xml (cxf style configuration file) not the new introduced jbossws-endpoints.xml   .


                              Looks like my previous 4 reasons are not the problems at all .  To simplify the things , we can use jbossws-cxf.xml to deploy jms transport web service.  I agreed for this direction.The one problem I can see if we use jbossws-cxf.xml to deploy jms endpoint so far : jbossws-cxf.xml is now used to customize the default generated cxf deployment descriptor by http endpoint , it will be mixed up with jms endpoint when user specifies the jbossws-cxf.xml for http endpoint ,and also want to deploy the jms endpoint with the same jbossws-cxf.xml. Let's take a example :

                               

                              ////////////////<web.xml>//////////////////
                                <servlet>
                                  <servlet-name>HelloService</servlet-name>
                                  <servlet-class>org.jboss.test.ws.jaxws.samples.HelloImpl</servlet-class>
                                </servlet>

                               

                                <servlet-mapping>
                                  <servlet-name>HelloService</servlet-name>
                                  <url-pattern>/*</url-pattern>
                                </servlet-mapping>

                               

                              /////////////////<jbossws-cxf.xml>//////////////////////
                                  <jaxws:endpoint id='HttpHelloService'
                                      implementor='org.jboss.test.ws.jaxws.samples.HelloImpl>
                                  </jaxws:endpoint>
                                    
                                      <!--jms endpoint->
                                         <jaxws:endpoint id='JMSHelloService'
                                         wsdlLocation="./wsdl/jms-samples.wsdl"   
                                             implementor='org.jboss.test.ws.jaxws.samples.HelloImpl>
                                  </jaxws:endpoint>

                               

                              We name the configuration file to only deploy jms endpoint to something like jbossws-cxf-jms.xml ?  or we do not support deploy the jms endpoint and http endpoin in one deployment archive ?

                               

                              2)  the approach Richard suggested to do jms integration :
                                  * extend our UMDM (located in SPI) to provide JMS endpoint abstractions
                                  * extend our DA framework to distinguish DA aspects intended to create web based endpoints and jms based endpoints
                                  * update our ASIL (concretely WSDeploymentAspectDeployer) to distinguish between Web DAs and JMS DAs
                                  * implement CXF DA that will map jboss-cxf.xml MD to our UMDM (ensures CXF -> SPI dependency)
                                  * implement ASIL DA that will create JMS MD from our UMDM (ensures ASIL -> SPI dependency)
                                  * implement CXF DA that will register plain JMS endpoints with CXF (ensures CXF -> SPI dependency)

                               

                              If you look at my cxf integration work two weeks ago, you can find what I did except the jbossws-endpoints are mainly follow this suggested approach.  But after I realized the jms endpoints needs the jms queue/topic deployment dependencies, I created the BeanMataData and deliever the KernalDeploymentDeployer to deploy the jms endpoints . At present , we can not resolve the deployment dependency in the DA.

                               

                              Add also distinguish the http endpoint and jms endpoint in  jbossws-cxf.xml is difficult, for some configuration file (like the example in 1) you need to parse the wsdl , then you can figour out. 

                               

                              3) The Endpoint and ASIL dispatch
                                 * Endpoint
                                  - ServletEndpoint -> url address
                                  - JMSEndpoint -> jms address
                                 * DA
                                 - ServletDA
                                 - JMSDA


                                OK. You convinced me to create JMSEndpoint for jms transport endpoint .  It's ideal to use ServletDA to deploy the ServletEndpoint and JMSDA to handle jms endpoint. But again, DA can not handle the dependency deployment which is required by jms transport endpoints deployment in CXF.  Do you have some ideas to change the DA api and eable the dependency in DA ?

                               


                              4) jms endpoint from wsdl (soap over jms support) sample

                               

                              I've created a test case for this : https://svn.jboss.org/repos/jbossws/stack/cxf/branches/jms-integration/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/samples/endpointsdd/jmstransport/EndpointsDDFromWsdlJMSTransportTestCase.java

                              • 12. Re: CXF jms integration
                                Richard Opalka Master

                                1)

                                 

                                AFAIK jbossws-cxf.xml is generated only in case there isn't one provided.

                                The scenario of deploying both JMS and Servlet endpoints in one war

                                using one jbossws-cxf.xml DD should be supported.

                                I don't expect any real issues with this scenario.

                                 

                                2) & 3)

                                Jim Ma wrote:

                                If you look at my cxf integration work two weeks ago, you can find what I did except the jbossws-endpoints are mainly follow this suggested approach.  But after I realized the jms endpoints needs the jms queue/topic deployment dependencies, I created the BeanMataData and deliever the KernalDeploymentDeployer to deploy the jms endpoints . At present , we can not resolve the deployment dependency in the DA.

                                True, you cannot resolve dependency on JMS deployers in DA code. This can be done only in deployers.

                                But you're able to detect if particular DA is JMS DA or Servlet DA. See my suggestion (the pseudocode)

                                in my previous post how to resolve this issue in our WSDeploymentAspectDeployer constructor.

                                IOW you shouldn't introduce additional deployers in AS IL. You should do everything in DAs

                                and just leverage the AS IL integration code.

                                   This said I suggest you to delete both BeaMetaData and KernalDeploymentDeployer in our SPI

                                and rewrite your solution to follow my suggestions

                                • 13. Re: CXF jms integration
                                  Jim Ma Apprentice

                                  1)  AFAIK  jbossws-cxf.xml is generated only in case there isn't one provided.

                                  The  scenario of deploying both JMS and Servlet endpoints in one war

                                  using  one jbossws-cxf.xml DD should be supported.

                                  I don't expect any  real issues with this scenario.

                                  Sorry , I may do not explain this problem well . We now create SPI endpoint from ServletMetaData in web.xml . How to distinguish the jms tranport endpoint and create jms endpoint/MD from the user provided jbossws-cxf.xml like :

                                   

                                    <jaxws:endpoint id='HttpHelloService'
                                           implementor='org.jboss.test.ws.jaxws.samples.HelloImpl>
                                       </jaxws:endpoint>
                                        
                                          <!--jms endpoint->
                                              <jaxws:endpoint id='JMSHelloService'
                                              wsdlLocation="./wsdl/jms-samples.wsdl"   
                                                  implementor='org.jboss.test.ws.jaxws.samples.HelloImpl>
                                       </jaxws:endpoint>

                                   

                                  True, you cannot resolve dependency on JMS deployers in DA code. This  can be done only in deployers.

                                  But you're able to detect if  particular DA is JMS DA or Servlet DA. See my suggestion (the  pseudocode)

                                  in my previous post how to resolve this issue in our  WSDeploymentAspectDeployer constructor.

                                  IOW you shouldn't  introduce additional deployers in AS IL. You should do  everything in DAs and just leverage the AS IL  integration code.

                                  AFAIK, the hornetq deployers create BeanMetaData for queue/topic deployment descriptor

                                  and KernalDeploymentDeployer will start/stop these BeanMetaData represents queue/topic created by hornetq deployers.

                                  I understood your suggestion : use deployer input to put the JMS DA after the deployer deployed jms destination.  In AS5 , we should put JMSDA after the last real stage deployer ServiceDeployer . AS6, we put JMSDA after KernalDeploymentDeployer. IOW, we do not rely on AS deployer frameworks' deployment dependency mechinism , we rely on the deployer order to resolve the deployment dependency. If this is acceptable and if you do not see any other problems , I will follow your suggestion (as your pseudocode shows) to rewrite .

                                  • 14. Re: CXF jms integration
                                    Richard Opalka Master

                                    Hi Jim, I just reviewed your SPI and ASIL prototypes and here are my 2 cents:

                                     

                                    SPI:

                                     

                                    Remove org.jboss.wsf.spi.metadata.endpoints.EndpointsFactory (proprietary DD xml JBXB parsing)
                                    Remove org.jboss.wsf.spi.metadata.endpoints.AbstractEndpointsDeployment (to don't publish proprietary DD)
                                    I like org.jboss.wsf.spi.metadata.endpoints.jms.JMDDestinationMetaData
                                    I like org.jboss.wsf.spi.metadata.endpoints.jms.JMDDestinationMetaData but remove static fields from it  (proprietary DD xml JBXB parsing)
                                    I like org.jboss.wsf.spi.metadata.endpoints.AddressMetaData (but it's name should be AbstractAddressMetaData because it's abstract class)
                                    I like org.jboss.wsf.spi.metadata.endpoints.EndpointsMetaData (but remove URL related methods & fields)
                                    I like org.jboss.wsf.spi.metadata.endpoints.EndpointMetaData (but here's some overlap with org.jboss.wsf.spi.deployment.Endpoint you should investigate/fix)

                                     

                                    ASIL:

                                     

                                    Remove org.jboss.webservices.integration.deployers.WSEndpointsDescriptorParserDeployer (proprietary DD xml parsing deployer)
                                    Rewrite org.jboss.webservices.integration.deployers.WSEndpointsRealDeployer
                                    - it have to be DA
                                    - I would name it MetaDataBuilderJMS
                                    - I would place it in package org.jboss.webservices.integration.metadata (because it provides JMS metadata)
                                    Update WSDeploymentAspectDeployer to specify proper inputs/outputs according to passed DeploymentAspect type (JMS/Servlet)
                                    Provide another DeploymentType (DeploymentType.JAXWS_JMS)
                                    Update org.jboss.webservices.integration.deployers.deployment.WSDeploymentBuilder
                                    - remove hacky code
                                    - and provide proper DeploymentModelBuilderJAXWS_JMS integration
                                    Implement org.jboss.webservices.integration.deployers.deployment.DeploymentModelBuilderJAXWS_JMS
                                    - so it properly integrates with SPIEndpoint
                                    - it handles new DeploymentType.JAXWS_JMS

                                    1 2 Previous Next