Usage of the new jboss50 new deployer architecture

[adrian.brock]

To update jbossws to the new deployers, I must have had to modify
at least three files that organise thirdparty dependencies.

But even having done that, it didn't build the jboss50 integeration.
So I went to that directory and did a build there, and I got this:

[ejort@warjort jboss50]$ ant
Buildfile: build.xml

prepare:

thirdparty-init:

thirdparty-get:

thirdparty-classpath:

thirdparty:

init:

BUILD FAILED
/home/ejort/jbossws/integration/jboss50/build.xml:41: Not available: ${jboss50.home}/client/jboss-ejb3-client.jar

Why is it compiling over non-versioned jars??????!!!!!!!

This makes the whole build unreproducable.

How do I know which version of jboss-ejb3-client.jar I need to reproduce a
customer problem from source?

[adrian.brock]

Anyway, back to the reason why I want to modify the jbossws project.

I'm trying to integrate the new deployer updates:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112181

I started to copy the code into varia as a temporary measure so at least
I know what versions I'm compiling over and the integration gets maintained
in step with the JBossAS code, like EJB3.

What do I find, you've reinvented the wheel again (the deployers framework)
with something called DeployerHooks. Why??????

I also started commenting a number of other stupidities like using the
Thread Context Classloader instead of the DeploymentUnit.getClassLoader()
and the ever handling is the usual mess.
e.g. aop has the same problem:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058739#4058739

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

Not only that it is referenced inside JBossWS itself, so I can't even just rewrite
the 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 deployment
that is a good thing. But not when you are just munging
http://en.wikipedia.org/wiki/Munging
somebody else's api and exposing implementation details that should never
have been exposed.

[thomas.diesler]

I already updated to the new deployer architecture

http://jbws.dyndns.org:8280/hudson/job/Core-Tests-AS-5.0/57/changes

[adrian.brock]

I'm going to go back to the jbossws codebase instead of the varia strategy
and 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 be
depending on things like ejb3 at all. It should certainly have access to its metadata for
deployment 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 the
ObjectModelParsing deployer.

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

[adrian.brock]

I already updated to the new deployer architecture

http://jbws.dyndns.org:8280/hudson/job/Core-Tests-AS-5.0/57/changes

:-)

Ok, but my other concerns still stand.

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.

[adrian.brock]

One other point. You shouldn't be using the main deployer to create webcontexts.
You should just be adding WebMetaData to your deployment.

That was one of the main reasons for the Deployers changes.
A single deployment can be both a web deployment and an ejb deployment,
exactly because this occurs in webservices.

The hack to create a new deployment for the web-app is a hangover from the JBoss4
limitiations.

[thomas.diesler]

1) Fix the build so it is reproducable

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

No comment.

[adrian.brock]

3) Fix the error handling

Please be more specific

You've got the same bugs as AOP,
to repeat what I said on that post, except with your code e.g.

AbstractWebServiceDeployer

 @Override
 public void deploy(DeploymentUnit unit) throws DeploymentException
 {
 for (DeployerHook deployer : deployerHooks)
 deployer.deploy(unit);
 }

So when the second hook fails, the stuff the first hook did, is not rolled back.

 @Override
 public void undeploy(DeploymentUnit unit)
 {
 for (DeployerHook deployer : deployerHooks)
 deployer.undeploy(unit);
 }

So an error on the first hook means nothing else gets undeployed.
And the order should be reversed for undeployment.

[thomas.diesler]

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.

 // start the deployment
 for (int i = 0; i < getDeploymentAspects().size(); i++)
 {
 DeploymentAspect aspect = getDeploymentAspects().get(i);
 try
 {
 logInvocation(aspect, "Start");
 aspect.start(dep);
 }
 catch (RuntimeException rte)
 {
 while (i-- >= 0)
 {
 // destroy the deployment
 failsafeDestroy(aspect, dep);
 }
 throw rte;
 }
 }