.sar showing up multiple times

[bill.burke]

FYI: My EJB Deployer receives request to deploy a .sar multiple times. Not sure why this is...

[bill.burke]

I think the deployment request is for each jar within the SAR. The DeploymentContext.getVirtualFile().getName() returns the .sar file though.

[bill.burke]

actually, what i mean is DeploymentContext.getRoot().getName() returns the .sar file. Maybe the sub DeploymentUnit.getDeploymentContext().getRoot() is returning the .sar VirtualFile instead of the actual .jar nested within the .sar? Not sure what the behavior is supposed to be...

I'm using du.getDeploymentContext().getRoot() to get a VirtualFile I can scan for classes with annotations.

[bill.burke]

I guess what I"m saying is should du.getDeploymentContext().getRoot() return the top level archive? or the actual archive that makes up the context?

[bill.burke]

Yeah, in looking at the code, it looks like a bug here.

[starksm64]

Yes, the DC.getRoot() should be the VirtualFile for the root of the deployment. For subdeployments it should be the subdeployment VirtualFile.

[bill.burke]

So, have you guys fixed any bugs here recently?

[starksm64]

I have not.

[bill.burke]

Ok, here's what I found. It seems that for every jboss-server.xml mbean entry a new DeploymentUnit is created with the same exact DeploymentContext (or VirtualFile Root, not sure yet).

I'm not sure what the thinking is here guys...Is this a bug or a feature?

Maybe its that my EJBDeployer extends AbstractSimpleDeployer? Maybe I'm hooking it up wrong?

[adrian.brock]

These are components of the deployment.
e.g.
a sar contains many mbeans
an ejb-jar contains many ejbs

The idea is that you can write a deployer that deals with
one component at a time rather than having to do the complicated error handling (of rolling back previous components) if it fails part way through
in every deployer.
In the JBoss4 deployers, this is mostly broken and where it even exists
it is often inconsistent and contains different bugs in different deployers.

Depending on what you want to process there is an
isTopLevel() and isComponent() available on the DeploymentContext
which need to be exposed as part of the strucure query stuff that
needs adding for the DeploymentUnit.

[adrian.brock]

Eventually, I want to turn this on its head
so that each deployer describes what metadata objects and component
types it wants to process.
See the thread on deployer chains.

i.e. It won't need to do the filtering explicitly itself.

[bill.burke]

Ok, makes a lot of sense now...THis component notion. Makes rollbacks a lot easier and you depend on the deployment architecture to manage what needs to be rolledback...