[prev in list] [next in list] [prev in thread] [next in thread]
List: jboss-user
Subject: Re: [jboss-user] [JBoss Web Services Development] - CXF jms
From: Jim Ma <do-not-reply () jboss ! com>
Date: 2010-04-30 6:31:54
Message-ID: 1694022048.124331272609117742.JavaMail.jive () clearspace02 ! app ! mwc ! hst ! phx2 ! redhat ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Jim Ma [http://community.jboss.org/people/jim.ma] replied to the discussion
"CXF jms integration"
To view the discussion, visit: http://community.jboss.org/message/540295#540295
--------------------------------------------------------------
> 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 \
> 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" .
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540295#540295]
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]
[Attachment #5 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<body link="#355491" alink="#4262a1" vlink="#355491" style="background: #e2e2e2; \
margin: 0; padding: 20px;">
<div>
<table cellpadding="0" bgcolor="#FFFFFF" border="0" cellspacing="0" style="border: \
1px solid #dadada; margin-bottom: 30px; width: 100%; -moz-border-radius: 6px; \
-webkit-border-radius: 6px;"> <tbody>
<tr>
<td>
<table border="0" cellpadding="0" cellspacing="0" bgcolor="#FFFFFF" \
style="border: solid 2px #ccc; background: #dadada; width: 100%; -moz-border-radius: \
6px; -webkit-border-radius: 6px;"> <tbody>
<tr>
<td bgcolor="#000000" valign="middle" height="58px" style="border-bottom: 1px \
solid #ccc; padding: 20px; -moz-border-radius-topleft: 3px; \
-moz-border-radius-topright: 3px; -webkit-border-top-right-radius: 5px; \
-webkit-border-top-left-radius: 5px;">
<h1 style="color: #333333; font: bold 22px Arial, Helvetica, sans-serif; \
margin: 0; display: block !important;">
<!-- To have a header image/logo replace the name below with your img tag \
-->
<!-- Email clients will render the images when the message is read so any \
image -->
<!-- must be made available on a public server, so that all recipients can \
load the image. -->
<a href="http://community.jboss.org/index.jspa" style="text-decoration: \
none; color: #E1E1E1">Community</a></h1> </td>
</tr>
<tr>
<td bgcolor="#FFFFFF" style="font: normal 12px Arial, Helvetica, sans-serif; \
color:#333333; padding: 20px; -moz-border-radius-bottomleft: 4px; \
-moz-border-radius-bottomright: 4px; -webkit-border-bottom-right-radius: 5px; \
-webkit-border-bottom-left-radius: 5px;"><h3 style="margin: 10px 0 5px; font-size: \
17px; font-weight: normal;"> CXF jms integration
</h3>
<span style="margin-bottom: 10px;">
reply from <a href="http://community.jboss.org/people/jim.ma">Jim Ma</a> in \
<i>JBoss Web Services Development</i> - <a \
href="http://community.jboss.org/message/540295#540295">View the full discussion</a> \
</span> <hr style="margin: 20px 0; border: none; background-color: #dadada; height: \
1px;">
<div class="jive-rendered-content"><blockquote class="jive-quote">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.<br/></blockquote><p>Thanks for the comments and ideas. Yes.  We are in the \
same page .</p><blockquote class="jive-quote"><br/>* 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. \
<br/></blockquote><p>There are following reasons I named it to general \
jbossws-endpoint.xml and not jms-endpoints.xml:</p><p>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.</p><p style="min-height: 8pt; \
height: 8pt; padding: 0px;"> </p><p>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 .</p><p style="min-height: 8pt; height: 8pt; padding: \
0px;"> </p><p>c) Combine our features (eg, jaxbintro configuration xml) \
and  jbossws-endpoint.xml to generated CXF deployment configuraiton.   \
</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><blockquote \
class="jive-quote">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. <br/></blockquote><p>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 . </p><p style="min-height: 8pt; height: 8pt; \
padding: 0px;"> </p><blockquote class="jive-quote">* 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)? <br/></blockquote><p style="min-height: 8pt; height: 8pt; \
padding: 0px;"> </p><p>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</p><p>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 \
.</p><blockquote class="jive-quote">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<br/></blockquote><p>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 ?</p><blockquote class="jive-quote">* \
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)?</blockquote><p>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.  </p><blockquote class="jive-quote">* do you already know whether \
the proposed architecture is going  to work with CXF 2.3 SOAP-over-JMS-1.0 \
support too (<a class="jive-link-external-small" \
href="http://cxf.apache.org/docs/soap-over-jms-10-support.html">http://cxf.apache.org/docs/soap-over-jms-10-support.html</a>)?</blockquote><p>Yes. \
It supports the soap-over-jms. The current deployer architcture supports to deploy \
the endpoint class with wsdl file .</p><p> I also uses the "soap-over-jms spec" style \
jms address to reprents the endpoint address for spec "alignment" .</p></div>
<div style="background-color: #f4f4f4; padding: 10px; margin-top: 20px;">
<p style="margin: 0;">Reply to this message by <a \
href="http://community.jboss.org/message/540295#540295">going to Community</a></p> \
<p style="margin: 0;">Start a new discussion in JBoss Web Services Development at <a \
href="http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2047">Community</a></p>
</div></td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</div>
</body>
</html>
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic