JBossWS Deployers Integration

[ropalka]

This is a first brain dump regarding the following issues (feel free to comment/discuss):

JBWS-2332
JBWS-2333
JBWS-2338
JBWS-2370
JBWS-2382

[ropalka]

First our current deployers architecture:

We have three deployers in place, namely:
* WebServiceDeployerEJB
* WebServiceDeployerPreJSE
* WebServiceDeployerPostJSE

These are ordered in the following way:
ordering1) EJBDeployer < WebServiceDeployerEJB < WarDeployer
ordering2) WebServiceDeployerPreJSE < WarDeployer < WebServiceDeployerPostJSE

ordering1) is followed when EJB as WS is deployed (only one WS deployer does all the WS magic)
ordering2) is followed in case POJO as WS is deployed (two WS deployers do all the WS magic)

Each WS deployer has two deployer hooks registered (JAX-RPC and JAX-WS):

+--- WebServiceDeployerEJB ( holds WSDeploymentAspectManagerEJB )
| |
| +--- JAXRPCDeployerHookEJB21
| |
| +--- JAXWSDeployerHookEJB3
|
+--- WebServiceDeployerPreJSE ( holds WSDeploymentAspectManagerPreJSE )
| |
| +--- JAXRPCDeployerHookPreJSE
| |
| +--- JAXWSDeployerHookPreJSE
|
+--- WebServiceDeployerPostJSE ( holds WSDeploymentAspectManagerPostJSE )
|
+--- JAXRPCDeployerHookPostJSE
|
+--- JAXWSDeployerHookPostJSE

Deployer hook represents JBossAS 4 style deployer that does almost all the WS processing stuff.
It usually does the following things:
* determines the WS deployment type (JAX-WS or JAX-RPC)
* constructs initial JBossWS Metadata model that is later used by JBossWS deployment aspects
* calls WS deployment aspect manager to build/process WS Metadata model using registered WS deployment aspects

The following deployment aspects are registered with particular deployment aspect managers:
(AS guys can imagine them like AS deployers, they are following the same chain-of-responsibility pattern
and are also kind of ordered set of processors like AS deployers are).

WSDeploymentAspectManagerEJB
|
+--- AS
| |- WSContainerMetaDataDeploymentAspect = org.jboss.wsf.container.jboss50.deployment.metadata.ContainerMetaDataDeploymentAspect
| |- WSInjectionMetaDataDeploymentAspect = org.jboss.wsf.container.jboss50.deployment.metadata.InjectionMetaDataDeploymentAspect
| |- WSContextRootDeploymentAspect = org.jboss.wsf.framework.deployment.BackwardCompatibleContextRootDeploymentAspect
| |- WSVirtualHostDeploymentAspect = org.jboss.wsf.framework.deployment.VirtualHostDeploymentAspect
| |- WSEndpointAddressDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointAddressDeploymentAspect
| |- WSEndpointHandlerDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointHandlerDeploymentAspect
| |- WSEndpointLifecycleDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointLifecycleDeploymentAspect
| |- WSEndpointMetricsDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointMetricsDeploymentAspect
| |- WSEndpointNameDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointNameDeploymentAspect
| |- WSEndpointRegistryDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointRegistryDeploymentAspect
| |- WSURLPatternDeploymentAspect = org.jboss.wsf.framework.deployment.BackwardCompatibleURLPatternDeploymentAspect
| |- WSRuntimeLoaderDeploymentAspect = org.jboss.wsf.container.jboss50.deployment.RuntimeLoaderDeploymentAspect
| |- WSWebAppDeploymentAspect = org.jboss.wsf.container.jboss50.transport.WebAppDeploymentAspect
| +- WSWebAppGeneratorDeploymentAspect = org.jboss.wsf.container.jboss50.transport.WebAppGeneratorDeploymentAspect
|
+--- Native
|- WSNativeContextPropertiesDeploymentAspect = org.jboss.wsf.framework.deployment.ContextPropertiesDeploymentAspect
|- WSNativeEagerInitializeDeploymentAspect = org.jboss.wsf.stack.jbws.EagerInitializeDeploymentAspect
|- WSNativeEndpointHandlerDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointHandlerDeploymentAspect
|- WSNativeEndpointRecordProcessorDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointRecordProcessorDeploymentAspect
|- WSNativeEventingDeploymentAspect = org.jboss.wsf.stack.jbws.EventingDeploymentAspect
|- WSNativePublishContractDeploymentAspect = org.jboss.wsf.stack.jbws.PublishContractDeploymentAspect
|- WSNativeServiceEndpointInvokerDeploymentAspect = org.jboss.wsf.stack.jbws.ServiceEndpointInvokerDeploymentAspect
|- WSNativeRMDeploymentAspect = org.jboss.ws.extensions.wsrm.server.RMDeploymentAspect
|- WSNativeUnifiedMetaDataDeploymentAspect = org.jboss.wsf.stack.jbws.UnifiedMetaDataDeploymentAspect
+- WSJAXBIntroDeploymentAspect = org.jboss.wsf.stack.jbws.JAXBIntroDeploymentAspect

WSDeploymentAspectManagerPreJSE
|
+--- AS
| |- WSContainerMetaDataDeploymentAspect = org.jboss.wsf.container.jboss50.deployment.metadata.ContainerMetaDataDeploymentAspect
| |- WSInjectionMetaDataDeploymentAspect = org.jboss.wsf.container.jboss50.deployment.metadata.InjectionMetaDataDeploymentAspect
| |- WSContextRootDeploymentAspect = org.jboss.wsf.framework.deployment.BackwardCompatibleContextRootDeploymentAspect
| |- WSEndpointAddressDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointAddressDeploymentAspect
| |- WSEndpointHandlerDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointHandlerDeploymentAspect
| |- WSEndpointMetricsDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointMetricsDeploymentAspect
| |- WSEndpointNameDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointNameDeploymentAspect
| |- WSEndpointRegistryDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointRegistryDeploymentAspect
| |- WSModifyWebMetaDataDeploymentAspect = org.jboss.wsf.container.jboss50.deployment.tomcat.ModifyWebMetaDataDeploymentAspect
| +- WSURLPatternDeploymentAspect = org.jboss.wsf.framework.deployment.BackwardCompatibleURLPatternDeploymentAspect
|
+--- Native
+- WSNativeContextPropertiesDeploymentAspect = org.jboss.wsf.framework.deployment.ContextPropertiesDeploymentAspect

WSDeploymentAspectManagerPostJSE
|
+--- AS
| |- WSEndpointLifecycleDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointLifecycleDeploymentAspect
| +- WSRuntimeLoaderDeploymentAspect = org.jboss.wsf.container.jboss50.deployment.RuntimeLoaderDeploymentAspect
|
+--- Native
|- WSNativeEndpointHandlerDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointHandlerDeploymentAspect
|- WSNativeEndpointRecordProcessorDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointRecordProcessorDeploymentAspect
|- WSNativeEventingDeploymentAspect = org.jboss.wsf.stack.jbws.EventingDeploymentAspect
|- WSNativePublishContractDeploymentAspect = org.jboss.wsf.stack.jbws.PublishContractDeploymentAspect
|- WSNativeServiceEndpointInvokerDeploymentAspect = org.jboss.wsf.stack.jbws.ServiceEndpointInvokerDeploymentAspect
|- WSNativeRMDeploymentAspect = org.jboss.ws.extensions.wsrm.server.RMDeploymentAspect
|- WSNativeUnifiedMetaDataDeploymentAspect = org.jboss.wsf.stack.jbws.UnifiedMetaDataDeploymentAspect
|- WSNativeEagerInitializeDeploymentAspect = org.jboss.wsf.stack.jbws.EagerInitializeDeploymentAspect
+- WSJAXBIntroDeploymentAspect = org.jboss.wsf.stack.jbws.JAXBIntroDeploymentAspect

[ropalka]

Current JBossWS + AS5 integration isn't implemented properly.
There are two main issues with it:

ad1) We're not reusing provided AS deployers architecture/concept.
Instead of reusing it we're reimplementing the same architecture
pattern on our own. It made sense to do it in the past
when we were supporting AS 40, AS 42 and AS 50 but now when AS 5x is
supported only it doesn't make sense any more.
Correcting JBossWS integration with AS deployers architecture will
also allow other AS projects to better integrate with JBossWS seamlessly
(see JBAS-5935).

ad2) Second problem is we're doing not just metadata processing stuff
in deployers processing layer. Many of the current deployment aspects
have to be executed in Servlet lifecycle methods to prevent
"chicken and egg" problem we're facing at the present
(see JBWS-2370).
These deployment aspects that will be moved to servlet lifecycle methods
will also be executed per endpoint not per deployment like is it now.

The following JBossWS deployment aspects will be removed from deployers chain (will be moved to servlet lifecycle methods):
* EndpointLifecycleDeploymentAspect
* EndpointHandlerDeploymentAspect
* EndpointRecordProcessorDeploymentAspect
* EventingDeploymentAspect
* ServiceEndpointInvokerDeploymentAspect
* RMDeploymentAspect
* EagerInitializeDeploymentAspect
* EndpointMetricsDeploymentAspect
* EndpointAddressDeploymentAspect

The following JBossWS deployment aspects will stay in deployers processing chain (but will be reimplemented to use AS deployers approach instead):
* RuntimeLoaderDeploymentAspect
* PublishContractDeploymentAspect
* JAXBIntroDeploymentAspect
* UnifiedMetaDataDeploymentAspect
* ContextPropertiesDeploymentAspect
* ModifyWebMetaDataDeploymentAspect
* BackwardCompatibleContextRootDeploymentAspect
* BackwardCompatibleURLPatternDeploymentAspect
* EndpointRegistryDeploymentAspect
* EndpointNameDeploymentAspect
* InjectionMetaDataDeploymentAspect
* ContainerMetaDataDeploymentAspect
* WebAppGeneratorDeploymentAspect
* WebAppDeploymentAspect
* VirtualHostDeploymentAspect

WS deployer hooks will be reimplemented too (will become AS deployers)

[anil.saldhana]

Because of WS deployer framework, I had to create the JACC web permissions for the WS deployments in the WS deployers rather than the security deployers.

I am referring to the transient tomcat deployment WS uses to deal with WS invocations.

When JBossWS starts using AS deployers, I guess we can clean up the JACC permissions creation. If metadata is used by WS, then I think we just have to remove the jacc perm creation from the as/webservice project.

[asoldano]

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)

[ropalka]

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.

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).

[asoldano]

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 <a href="http://www.jboss.org/index.html?module=bb&op=viewtopic&t=142029#4175187">this</a>.

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)

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 ;)
<pre>
<!-- [JBDEPLOY-201] workaround -->
</pre>
In short about <a href="https://jira.jboss.org/jira/browse/JBDEPLOY-201">JBDEPLOY-201</a>.
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

[ropalka]

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 would 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)

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

[ropalka]

Considering the WSDeploymentDeployer seems to me just something like a wrapper of the DAs.

Yes, this is our current solution. We're wrapping each JBossWS DA in WSDeploymentAspectDeployer. WSDeployersFactory does the deployers registration job dynamically - this ensures AS IL abstraction will not be broken.

[asoldano]

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:
<ul>
<li>we can't replace DAs with Deployers, otherwise our stacks would be tightly coupled with AS internals. To separate all supported SOAP stacks from different AS versions we have <b>AS IL (JBoss AS Integration Layer)</b> that does that abstraction job.</li>

OK... there's actually not much of that abstraction left, anyway I see your point of view of keeping the DA concept for generic deployment (see point below).
Btw, would it still be possible (if reasonable of course) for a non-ws deployer to be plugged in between two instances of WSDeploymentDeployer without touching anything of the current architecture?
Is the case Anil mentioned here before addressed by the current architecture? (just to be sure)

<li>we will need to implement <b>Endpoint.publish()</b> in near future (this will use DAs via DAManager - DAManager will be used as the replacement of deployers chain on Java client side)</li>
</ul>

OK, I agree on this.

IMHO the <a href="https://jira.jboss.org/jira/browse/JBDEPLOY-201">JBDEPLOY-201</a> title is self descriptive. Regarding that issue Ales Justin just wrote me:
<cite>
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.
</cite>

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

Thanks for the update.

[ropalka]

Btw, would it still be possible (if reasonable of course) for a non-ws deployer to be plugged in between two instances of WSDeploymentDeployer without touching anything of the current architecture?
Is the case Anil mentioned here before addressed by the current architecture? (just to be sure)

I bet you mean WSDeploymentAspectDeployer ;)
Sure, this was one of the requirements that affected our current AS IL implementation.
So to answer your question: Yes Anil usecase is supported now
(although I din't fix it in JBossAS Branch_5_x and trunk yet).

[asoldano]

Btw, would it still be possible (if reasonable of course) for a non-ws deployer to be plugged in between two instances of WSDeploymentDeployer without touching anything of the current architecture?
Is the case Anil mentioned here before addressed by the current architecture? (just to be sure)

I bet you mean <b>WSDeploymentAspectDeployer</b> ;)

Exactly, sorry for the typo.

Sure, this was one of the requirements that affected our current <b>AS IL</b> implementation.
So to answer your question: <b>Yes Anil usecase is supported now</b>
(although I din't fix it in JBossAS Branch_5_x and trunk yet).

Good (I assume your answers are positive for both questions) :-)
Regarding Anil's issue, please see if you can fix that on trunk/branch_5_x by the 3.2.0 ws release date. Thanks!

[ropalka]

Regarding Anil's issue, please see if you can fix that on trunk/branch_5_x by the 3.2.0 ws release date. Thanks!

Sure, it's in my TODO list.

[ropalka]

This is the brain dump of current JBossWS AS integration architecture.

We completely rewrote/reviewed our JBossWS AS integration layer.
However there are still some TODOs. We need to review our SPI and our EJB integration in the future. Also our current injection impl isn't ideal. We'll deal with these issues in near future.

Regarding the current state of AS IL (JBossWS AS integration layer) here are some notes:

We removed the notion of WS EJB deployer, WS PRE JSE deployer and WS POST JSE Deployer. All three deployers were alligned to one processing pipeline.

We also removed the notion of WS deployer hooks.

There are 5 deployers now in AS IL:
* WSDescriptorDeployer - Object model based webservice.xml files parsing deployer (PARSE stage deployer)
* WSEJBAdapterDeployer - WS deployer adapting EJB classes to provide EJB agnostic meta/data fasade for the rest of JBossWS code base (REAL stage deployer)
* WSTypeDeployer - detects webservice deployment type (can be JAXWS JSE, JAXRPC JSE, JAXWS EJB3 and JAXRPC EJB21) (REAL stage deployer)
* WSDeploymentDeployer - builds AS agnostic WS metadata (creates API abstraction over AS IL) (REAL stage deployer)
* WSDeploymentAspectDeployer - wrapper for all JBossWS deployment aspects (replacement for old JBossWS DeploymentAspectManager) (REAL stage deployer)

WSAspectizedDeployersFactory provides mechanism for un/registering JBossWS aspectized deployers

We also completely removed support for AS 4.x series from our AS IL
and updated the codebase to leverage AS 5.x architecture.

The previous suggestion to move some DAs to servlet lifecycle methods showed to be wrong (i.e. all JBossWS deployment aspects reside in deployers processing pipeline).