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/540977#540977 -------------------------------------------------------------- > 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 (http://www.jboss.org/file-access/default/members/jbossws/images/wsf.png) dependency) * implement ASIL DA that will create JMS MD from our UMDM (ensures http://www.jboss.org/file-access/default/members/jbossws/images/wsf.png ASIL -> SPI dependency) * implement CXF DA that will register plain JMS endpoints with CXF (ensures http://www.jboss.org/file-access/default/members/jbossws/images/wsf.png 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 > > 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. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/540977#540977] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2047]
_______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
