[jboss-dev-forums] [Design of POJO Server] - Hot deploying deployers - deployer chains

[adrian@jboss.org]

Rather than having a single deployer chain,
what we really need is a tree like structure based on the
input/output of the metadata structures.

e.g.

  | -- one-to-one
  | -< one-to-many
  | \- additional branch
  | 
  | Services
  | -service.xml -- ServiceDeployment.class -< ServiceMetaData.class -- MBean
  |                    \- LoaderRepositoryConfig.class - ClassLoader
  | 
  | Rars
  | .rar -- RARMetaData.class -- ServiceMetaData -- etc.
  |       \- LoaderRepositoryConfig.class -- etc.
  | 
  | Connection factories
  | -ds.xml -- ServiceDeployment.class -- etc.
  |            \- LoaderRepositoryConfig.class -- etc.
  | 

With each deployer defining its inputs and outputs.
e.g.
SARDeployer
input = -service.xml
output = ServiceDeployment.class

ServiceDeploymentDeployer
input = ServiceDeployment.class, ServiceMetaData.class
output = ServiceMetaData.class

ServiceDeployer
input = ServiceMetaData.class
output = REAL

This way the chain can built up based on the input/outputs.

We still need the original relative ordering to decide
which parts of the chain of get done at what stage,
e.g. the ServiceClassloaderDeployer is done
before the ServiceDeploymentDeployer

The advantage to this, is that we know when a deployer is added
whether other deployments (really pieces of their metadata)
are affected. i.e. whether we need to unwind them to
reprocess something.

e.g. When I add the RARDeployer to the beginning of the chain
I only need to see what deployments are rars (end in .rar or have
a ra.xml) and process the output ServiceMetaData through its
particular chain.
e.g.2. If somebody interpolates a deployer 
that processes ServiceMetaData.class between the 
ServiceDeploymentDeployer and the ServiceMetaDataDeployer
then I need to unwind the work of the ServiceMetaDataDeployer
to do that work before winding forward again.

Such a mechanism also gives a more direct link for the front
end profile service to reprocess part of a deployment
(including just changing an attribute on an MBean if that
is all the update requires - i.e. no redeploy).

The big stumbling block, comes from things like:
-aop.xml
-security.xml
log4j.xml
where we don't want any (or maybe part) of the deployment to proceed
until these have established their context.

But if these are hotdeployed, how do we know they even exist?
One solution is to be able to define these "show stoppers"
in the main deployer or profile service metadata.

However, that still leaves the age old problem,
how do I apply a -security.xml to the security deployer?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972529#3972529

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972529