Deployers, ContextData and MangedObjects
adrian.brock Sep 11, 2006 9:37 AMI'm nearly ready to merge the new Deployers into MC-VDF-WORK.
The parts left to do are the ContextData and the ManagedObject.
There is a little bit of overlap in what these are trying to achieve,
I think the real distinction comes down to how they are used
and how they get created.
I'll call them context attachments or just attachments for short.
The requirements as I see them are:
1) The ability to typesafely retrieve data about a context
(this can be shared between deployers, i.e. one deployer
creates it for a later stage to use).
2) The attachment can be non-trivial, e.g. an EJB deployment can
have many ejbs, can have many resource refs.
3) The attachment can be predefined by the profile service.
i.e. rather than using the ejb-jar.xml in the deployment, it
uses an EJBDeployment.class instance that has already
been overridden.
4) I also want to integrate the MetaDataRepository
(this is not necessary for the initial integration)
at this level using the Scopes defined in org.jboss.metadata.
Each deployer is obviously going to have some say
in defining what scope a deployment or part of a deployment
belongs to.
I want to provide a helper mechanism whereby this can be
done declartively in simple cases, e.g. something like the following
pseudo code:
processDeployment(EJBDeployment.class, "ejb-jar.xml", ...);
where the deployment aspect extends a known parsing mechanism
like I did for the SimpleSubDeployerSupport.
It also does all the logic of checking whether the object
was already passed in.
The rest of the work will be about defining suitable attachments
e.g. things like the ENC processing from xml, annotations
(including the metadata repository) can be handled by sharing
the same attachments/metadata although the sources are different.
Finally (this is not necessary for the initial integration),
I want to investigate whether it makes sense
to create a first class notion of "sub contexts"
(of the deployment context) for things
like EJBs such that certain aspects can act on
the sub context as well as the main context.
e.g. The ENC processing would make sense at this level
where the ENC is constructed per EJB not the whole deployment.
More concretely, the ENC attachment would be at the subcontext (EJB)
level for EJB deployments but at the main context for servlets.
By making the ENC deployer "subcontext aware" it would be invoked
on each subcontext and look for metadata at that level.
The alternative to subcontexts is a complicated/abstract
metadata model and doing iteration internally within the aspect
(which is likely going to be repeated code/logic that is difficult
to change and not extensible as others introduce their
own subcontext model).
In the original design document for the Microcontainer I called these
"Subservices" and let them go all the way down to components
that make up a service, e.g. the pool or cache