[Design of POJO Server] - Re: VFSDeploymentScanner questions
by scott.stark@jboss.org
"adrian(a)jboss.org" wrote : 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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957026#3957026
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957026
19 years, 3 months
[Design of POJO Server] - Re: VFSDeploymentScanner questions
by scott.stark@jboss.org
"adrian(a)jboss.org" wrote : "scott.stark(a)jboss.org" wrote :
| | 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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957015#3957015
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957015
19 years, 3 months