VFSDeploymentScanner questions

[starksm64]

I updated the VDFDeploymentScanner Dimitris had worked to a VFSDeploymentScanner that integrates with the VFS and ProfileService(See org.jboss.system.server.profileservice.VFSDeploymentScannerImpl in the system2 module).

A number of questions came up in this update.

1. What does hot deployment mean in the context of a ProfileService? The current implementation simply uses hot deployment as a simple mechanism to add deployments to the current server profile. Its a shortcut for editing the profile via some admin tool.

1a. In this context, what does touching a deployment mean? Any deployment added via hot deployment could have been edited any number of management tools and overriden the raw deployment metadata.

1b. Should a hot deployment service be a pure development notion that only loads deployments into memory and does not update the current profile?

2. The ordering of deployments based on suffix is largely useless with the current deployment framework that has any number of deployers operate on a deployment. Correct startup order is a function of deployers adding the correct dependency metadata to the kernel deployments they create. Any deployment package level dependency control would seem to be an aspect/deployer that used its own metadata to create place holder kernel objects (or used equivalents from jsr77) to introduce coarse grained dependencies. The question is, is this assement correct, and do we need such a coarse grained deployment aspect/deployer?

[adrian.brock]

There should be two types of "hot deployment".

1) The original version which is just a way to add urls (with no
chance of overrides by a management tool).

2) A more up-to-date version for the management tool
where you can specify a directory rather than a single url to deploy.
This is just a more convenient way of specifying urls.

In fact, (1) is just a subset of (2) where there is no "GUI" intervention

[adrian.brock]

2. The ordering of deployments based on suffix is largely useless with the current deployment framework that has any number of deployers operate on a deployment. Correct startup order is a function of deployers adding the correct dependency metadata to the kernel deployments they create. Any deployment package level dependency control would seem to be an aspect/deployer that used its own metadata to create place holder kernel objects (or used equivalents from jsr77) to introduce coarse grained dependencies. The question is, is this assement correct, and do we need such a coarse grained deployment aspect/deployer?

I'm not sure I understand this?

The deployments contain many pieces of metadata that are deployed
in an aspectized way. They still need an ordering, but based on the
metadata rather than the deployment suffix.

e.g. aop must be before classloading, classloading before
"instantiation", etc.

Other dependendencies (between services and entry points)
should be via the microcontainer. We are trying to remove
the implicit dependency of the suffix ordering and replace it
with a semi-implicit (i.e. added by deployer) dependency.

e.g. If an ejb uses another ejb/datasource then the
"enc/resource/reference" deployer adds this.
e.g.2. Trivially, the above also requires a dependency on naming
e.g.3. A web deployment has a dependency on the web container
etc.

[starksm64]

2. The ordering of deployments based on suffix is largely useless with the current deployment framework that has any number of deployers operate on a deployment. Correct startup order is a function of deployers adding the correct dependency metadata to the kernel deployments they create. Any deployment package level dependency control would seem to be an aspect/deployer that used its own metadata to create place holder kernel objects (or used equivalents from jsr77) to introduce coarse grained dependencies. The question is, is this assement correct, and do we need such a coarse grained deployment aspect/deployer?

I'm not sure I understand this?

The deployments contain many pieces of metadata that are deployed
in an aspectized way. They still need an ordering, but based on the
metadata rather than the deployment suffix.

e.g. aop must be before classloading, classloading before
"instantiation", etc.

Other dependendencies (between services and entry points)
should be via the microcontainer. We are trying to remove
the implicit dependency of the suffix ordering and replace it
with a semi-implicit (i.e. added by deployer) dependency.

e.g. If an ejb uses another ejb/datasource then the
"enc/resource/reference" deployer adds this.
e.g.2. Trivially, the above also requires a dependency on naming
e.g.3. A web deployment has a dependency on the web container
etc.

Right, this is what I'm saying. The previous notion of ordering the deployment contexts based on the deployment suffix has little meaning since the deployments get passed through the ordered list of deployers/aspects. Only if there are implicit dependencies like a legacy service looking up an ejb via jndi would there be meaning in having the sar depend on the target ejb jar. Such a dependency should an explicit deployment context level dependency rather than some deployment name based ordering.

[starksm64]

There should be two types of "hot deployment".

1) The original version which is just a way to add urls (with no
chance of overrides by a management tool).

2) A more up-to-date version for the management tool
where you can specify a directory rather than a single url to deploy.
This is just a more convenient way of specifying urls.

In fact, (1) is just a subset of (2) where there is no "GUI" intervention

This difference is just convienence of expressing deployments. What I'm asking about is whether the ProfileService is the only source of deployments, or whether the hot deployment service bypasses the ProfileService and uses the MainDeployer directly (as it does today). The latter would effectively eliminate the hot deployment service as usable in prod environments.

[adrian.brock]

Like I said on a different thread,

I see the basic dev environment "hot deployment" service
that works like JBoss4 just being a kind a simple profile service
that runs in memory.

We need this kind of simple profile service to make easy for
people to port JBoss4 configs and not have to deal with
two different paradigms internally.

[bill.burke]

We also don't want to force developers into a tool-based deployment model that most other vendors have. Ops might like the new approach, but development won't.

[starksm64]

I don't see why the hot deployment notion cannot be the baseline tool for deployment, and still have integration with the ProfileService. My concern with regard to leaving the hot deployment notion as something completely separate from the ProfileService is that it won't be used. If we wan't a similar prod compatible ease of use deployment, at least for single node systems, there will have to be some service that integrates hot deployment type of additions to the ProfileService. As far as I can see the only reason not to look at building the hot deployment service on top of the ProfileService would be the additional time it takes to complete an initial implementation. I can create a MainDeployer based implementation as a starting point to allow jboss5 to get to the point of deploying the existing configurations and look at an alternate implementation independently.