Deployment Structure

[adrian.brock]

This is a summary to try to end the discussions that are currently going
around in circles.

The basic idea follows the "do one thing well principle".

There are three components:
1) VFS - responsible for presenting the different protocols as a
single consistent file system, and abstracting away things like
unpacked directories pretending to be jars or unpacking nested jars.

2) StructureDeployers - responsible for determining the structure
of deployments, i.e. what is the classpath, metadata location
and subdeployments.

3) Deployers reponsible for working with the above models
to deploy stuff.

In no way should:
1) The VFS be dealing with deployment decisions.
2) The structure deployers be dealing with protocol issues.
3) The real deployers be dealing with protocol or structural issues.

I can think of one current exception to this rule where the
jboss-service.xml has an

<archives/>

that adds additional elements to the classpath.

In future, there is likely to be some form of aspectized
classloader.xml that will take the place of this element
and the loader-repository-config which can be processed by
the structure deployers such that this can be deprecated
and removed as the legacy mixing of concerns that it is.

[starksm64]

I agree, but I don't think the current interaction between 1 and 2 is adequately defined. I believe I should be able to attribute the path /projects/web/test-web-app as a war in the vfs. This does provide a context for war related deployment analysis, but its neccessary.

Otherwise, I don't see how a structural deployer will be able to identify that /projects/web/test-web-app/test.jsp is a war with a single jsp file.

[bill.burke]

I have a possible problem with #3. Take EJBDeployer. I need to be able to identify whether the EJBContainer is deployed within an EAR as apposed to being deployed within a super JAR (jar that has other jars) or a SAR or some other non-scoping entity. I need this to be able to generate the kernel name of the EJBContainer (ear name + jar name) and default JNDI name.

I guess what I could just do is scope the name if the DeploymentUnit.getDeploymentContext().getParent() is not null. The deploy/ directory is not considered a DeploymentContext/Unit, right?

[adrian.brock]

I guess what I could just do is scope the name if the DeploymentUnit.getDeploymentContext().getParent() is not null. The deploy/ directory is not considered a DeploymentContext/Unit, right?

No, there should be a

public interface DeploymentUnit
{
...
DeploymentUnit getParent();
}

The getDeploymentContext() is only there so you can get on with
doing things while we work these details out.

It's upto you. You can either use the DeploymentContext,
and I'll fix it later, or you can change the DeploymentUnit now
if you think something is generically useful.