Deployers Reloaded
This is an informational post. If you want to discuss specific topics
raised here, please create a seperate thread rather than creating another
unreadable monster thread. :-)
Its been over three months since I left the deployers framework
for you guys to get on with trying out.
I think that's sufficient time for you come up with usecases.
I'm now going to rework the deployers in the light of what has been discovered
and some extra requirements, some are experimental, others not.
PROPER ABSTRACTIONS
We need to create the proper abstractions over the DeploymentContext.
The DeploymentContext (a replacement for the horrible DeploymentInfo)
was only ever intended as an internal booking device
to tie the four different views of the data together.
1) Client view - the person requesting the deployment
2) Management view - the managed objects
3) Structure view - Scott already made a start on this
4) Deployer view - the DeploymentUnit
The DeploymentInfo was horrible because it leaked implementation details
into all sorts of code and nobody knowed whether the information was
being updated consistently.
The purpose of the abstractions is to ensure that the internal model is exposed
consistently to the deployers.
Exposing DeploymentContext on the DeploymentUnit was only ever a hack
to allow you guys to get on with writing the deployers so we can find out
what features were missing.
DOCUMENTATION
I need to document the Deployers so that people know what the model means
and how best to use it. The current AspectDeployer is example where even
the main idea of how the new deployers is supposed to work or integrate with the
profile service or other deployers (it has a number of other issues as well :-).
NEW REQUIREMENTS - FROM THE EXISTING DEPLOYERS
Top level only deployers - like the classloading deployer, the security deployer(s)
also want to deal only with the top level deployment, this should be handled more
transparently
Components - this prototype needs completing and like the "top level only" deployers
there needs to be extra support for deployers that are only or not interested in
components.
Ordering - most of the deployers are defining their own ordering rather than using the standard (which kind of defeats the point), see later on state machine and attachment streams.
Others?
NEW REQUIREMENTS - STRUCTURE
Russian doll, etc. - Scott has expressed a requirement to have the old implicit
deployment rules. This should really be a pluggable policy. Ideally, we should be
able to also implement an "all or nothing" deployment rule as well rather than the
current rules where parts of an EAR get deployed because there is explicit rule
to stop them (or they are out of order because implicit rules in general don't work).
NEW REQUIREMENTS - ATTACHMENT STREAMS
Currently a deployment will go through all deployers. The deployer is expected
to do something like:
public void deploy(DeploymentUnit unit)
{
MyMetaData md = unit.getAttachment(MyMetaData.class);
if (md == null)
return;
// do stuff
}
Ideally, we should be able to expose this information such that the deployer
is never called if there is no such attachment(s).
Similarly the output should be definable so the "main deployer" can order the
"stream". e.g.
nothing => ParsingDeployer<DeploymentMetaData> => DeploymentMetaData => ComponentDeployer<DeploymentMetaData, ComponentMetaData> => ComponentMetaData => RealDeployer<ComponentMetaData>
NEW REQUIREMENT - DEPLOYMENT DEPENDENCIES
Part of the OSGi work requires classloading dependencies (at both package
and deployment level). For non-OSGi deployments this will be definable via
jboss-classloading.xml, i.e. export, import, dynamic import and uses
(See the OSGi spec for what those are).
This means that the deployments themselves will have dependencies
so I'm going to introduce the Microcontainer dependency mechanism
into the MainDeployer to handle this.
In some sense, this also removes some of the ordering problems
since the currently defined standard ordering will be replaced with
ControllerStates.
I think the combination of assigning well defined states when deployers get run,
coupled with the attachment streams should handle most cases, but I'm
still going to keep the deployer ordering for use cases where this might
not be enough to resolve the ambiguity (assuming the order matters? :-).
TESTS
I don't see any of the new features being used by the deployers in JBossAS
or JBoss Embedded having corresponding tests in the JBoss Deployers project.
How you guys expect this not to regress is beyond me?
I'm going to abstract out what I think are the features intended and create
tests for them. I'm not going to create tests for what I think is just broken usage. ;-)