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#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...