[Design of JBoss Web Services] - Re: JBossWS Deployers Integration
by richard.opalka＠jboss.com
"alessio.soldano(a)jboss.com" wrote :
| Basically, we had a abstraction to support AS4.2 deployment in a similar way to AS 5.x, now most of that additional abstraction is gone, why DA are still there? Can't we simply move each of them in a different deployer? (considering the WSDeploymentDeployer seems to me just something like a wrapper of the DAs)
|
Yes, DA abstraction is still there and will probably stay there ;)
There are two main reasons why we're wrapping JBossWS DAs:
we can't replace DAs with Deployers, otherwise our stacks will be tightly coupled with AS internals. To separate all supported SOAP stacks from different AS versions we have AS IL (JBoss AS Integration Layer) that does that abstraction job. Note that there are DAs specified in stack config files, and we want to keep them AS agnostic.
we will need to implement Endpoint.publish() in near future (this will use DAs via DAManager - DAManager will be used as the replacement of deployers chain on Java client side)
"alessio.soldano(a)jboss.com" wrote :
| I saw the comment, perhaps a brief summary of the infinite discussion with Ales should be added to the jira description :-) It's not that clear otherwise. Btw, what's the status of JBDEPLOY-201? I see it's marked as in progress, but it doesn't seem to me somebody is working on it...
| Thanks
IMHO the JBDEPLOY-201 title is self descriptive. Regarding that issue Ales Justin just wrote me:
Currently there is no rush for it.
Hence I don't see the point of cutting new release,
as I have already done them too many.
I rather wait and get any additional fixes in (e.g. recent 208, 209).
I'll at least try to port the changes to Branch_2_0 asap,
so you can easily run a 2.0.9-SNAPSHOT version to test your stuff.
I just asked him to port the changes to JBDeploy Branch_2_0 branch so we can test the fix using 2.0.9-SNAPSHOT
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4248386#4248386
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4248386
15 years, 5 months
[Design of JBoss Web Services] - Re: JBossWS Deployers Integration
by alessio.soldano＠jboss.com
"richard.opalka(a)jboss.com" wrote : "alessio.soldano(a)jboss.com" wrote :
| | So, what's actually the reason for doing this, instead of having an actual separate deployer for each of the current deployment aspect, instead of doing the wrap process into WSDeploymentAspectDeployer? Wouldn't it be clearer?
| |
| The main reason is to enable other AS deployers to hook into WS deployers pipeline, see this.
Perhaps you're not getting me right, what I propose would make that even easier (as we'll end up with N real deployers instead of 4 deployers + 1 being instanciated multiple times according to the DeploymentAspect provided in the configuration).
Basically, we had a abstraction to support AS4.2 deployment in a similar way to AS 5.x, now most of that additional abstraction is gone, why DA are still there? Can't we simply move each of them in a different deployer? (considering the WSDeploymentDeployer seems to me just something like a wrapper of the DAs)
anonymous wrote :
| "alessio.soldano(a)jboss.com" wrote :
| | So my question is, why is relativeOrder required for all the deployment aspects turning into WSDeploymentAspectDeployer instances?
| Comment in jboss-beans config files is self descriptive ;)
|
| <!-- [JBDEPLOY-201] workaround -->
|
| In short about JBDEPLOY-201.
| There's a bug in domino ordering (deployers ordeing AS implementation) we have to workaround until fix is available in AS. This bug appears if there are multiple inputs/outputs specified on deployers (this affects all WS deployers, except WSDescriptorDeployer).
|
I saw the comment, perhaps a brief summary of the infinite discussion with Ales should be added to the jira description :-) It's not that clear otherwise. Btw, what's the status of JBDEPLOY-201? I see it's marked as in progress, but it doesn't seem to me somebody is working on it...
Thanks
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4248365#4248365
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4248365
15 years, 5 months
[Design of JBoss Web Services] - Re: JBossWS Deployers Integration
by richard.opalka＠jboss.com
"alessio.soldano(a)jboss.com" wrote :
| So, what's actually the reason for doing this, instead of having an actual separate deployer for each of the current deployment aspect, instead of doing the wrap process into WSDeploymentAspectDeployer? Wouldn't it be clearer?
|
The main reason is to enable other AS deployers to hook into WS deployers pipeline, see this.
"alessio.soldano(a)jboss.com" wrote :
| So my question is, why is relativeOrder required for all the deployment aspects turning into WSDeploymentAspectDeployer instances?
Comment in jboss-beans config files is self descriptive ;)
<!-- [JBDEPLOY-201] workaround -->
In short about JBDEPLOY-201.
There's a bug in domino ordering (deployers ordeing AS implementation) we have to workaround until fix is available in AS. This bug appears if there are multiple inputs/outputs specified on deployers (this affects all WS deployers, except WSDescriptorDeployer).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4248338#4248338
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4248338
15 years, 5 months
[Design of JBoss Web Services] - Re: JBossWS Deployers Integration
by alessio.soldano＠jboss.com
Hi Richard,
I've taken a look at the current state of ws deployers, here are 2 questions:
- I see there're now 5 deployers: WSDescriptorDeployer, WSEJBAdapterDeployer, WSTypeDeployer, WSDeploymentDeployer and WSDeploymentAspectDeployer. AFAICS we get an instance of the latter for each DeploymentAspect (the deployment aspect concept is still there). So, what's actually the reason for doing this, instead of having an actual separate deployer for each of the current deployment aspect, instead of doing the wrap process into WSDeploymentAspectDeployer? Wouldn't it be clearer?
- the ws DeploymentAspect ordering is still there, so far so good. It's actually used to provide additional input/output to the created WSDeploymentAspectDeployer instances. AFAIK the requires/provides attributes there define a correct ordering (and if they do not, we can fix that as that's all our stuff). So my question is, why is relativeOrder required for all the deployment aspects turning into WSDeploymentAspectDeployer instances? I though the relativeOrder is needed only when dealing with "filters" (deployers with the same input and output, whose processing order is not established otherwise), but here we'd probably need the relativeOrder prop just for the first and last WSDeploymentAspectDeployer. Of course if we do what I wrote in the previous point, we'd have different deployers, with just two of then having the relativeOrder prop. (excluding the other 4 real deployers we already have)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4248194#4248194
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4248194
15 years, 5 months