Re: [jboss-user] [JBoss Web Services Development] - CXF jms integration

Alessio Soldano [http://community.jboss.org/people/alessio.soldano%40jboss.com] replied to the discussion "CXF jms integration" To view the discussion, visit: http://community.jboss.org/message/540180#540180 -------------------------------------------------------------- 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 http://cxf.apache.org/docs/soap-over-jms-10-support.html)? Thanks -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/540180#540180] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]