But more importantly, the DeploymentContext is used everywhere!Even though this has been deprecated method from the start with a comment ongetDeploymentContext() saying "think about it before using this method".

Not only that it is referenced inside JBossWS itself, so I can't even just rewritethe deployers inside JBossAS (as a temporary measure)because the api is broken in jbossws-spi.jar

I can understand you having your own abstraction for deploymentthat is a good thing. But not when you are just munginghttp://en.wikipedia.org/wiki/Mungingsomebody else's api and exposing implementation details that should neverhave been exposed.

I'm going to go back to the jbossws codebase instead of the varia strategyand try to fix the build so at least it becomes reproducable.

Once that is done, I'll do the updates for the new deployers.Then we can finally do a release and get webservices working again in the appserver.

Even after this, there are lots of issues about whether webservices should bedepending on things like ejb3 at all. It should certainly have access to its metadata fordeployment purposes, which is one of the reasons we have started a"metadata" project so projects can share each others models.

Webservices seems to have one (WebservicesMetaData) which should be moved there.

I don't understand why you wrote your own parsing routines instead of using theObjectModelParsing deployer.

Well, actually I do, its because you're doing some stupid double parsewhere you first parse to DOM to check the namespace then parse againusing JBossXB?????

1) Fix the build so it is reproducable 2) Don't reinvent the deployers framework 3) Fix the error handling 4) Reuse the already developed code instead of re-inventing it and introducing alternate bugs. If it is doesn't quite do do what you want then add some new callbacks like the accepts() I added to the parsing deployers so EJB3 can do its hacks. :-)

One example of (2) is how do I modify the webserivices metadata with a new deployer? I can't. I have to use a different api, the DeployersHook to do this. This is just stupid.

yes, this is an outstanding issue which is caused by dependencies of our integration layers on projects that have no tagged release. It definitely needs to be done.

2) Don't reinvent the deployers framework

We are taking the concepts of the deployer architecture and make them available accross AS50, AS42, AS40

3) Fix the error handling

Please be more specific

4) Reuse the already developed code instead of re-inventing it and introducingalternate bugs. If it is doesn't quite do do what you want then add some new callbackslike the accepts() I added to the parsing deployers so EJB3 can do its hacks. :-)

The hooks work mutually exclusive. i.e. there is one hook for every type of deployment. The hooks themselves delegate to a DeloymentAspectManager, which excecutes the DeploymentAspects - the work of those aspects are rolled back on failure.