[starksm64]

The EJB Deployer can do what it already does: instantiate the container itself and install them manually into the kernel. No need for special MC states.

Then your back to the old monolithic model of mixing describing how to do something with doing it. This will complicate interaction with generalized notions like admin ops affecting all transport interfaces, clustering behaviors, as well as resue of code across server versions.

[starksm64]

DEPLOYMENT PROTOCOL

This is something that is not a part of the original prototype but it is a part of the
original design.

The basic idea is that the deployers can be run in two modes.
1) Runtime - this is what is implemented, it is the full deployment
2) Profile Service - in this case, the "real deployers" create contexts that have
stubbed out actions for the MC and JMX layers.

That is when it runs in Profile Service mode, it still goes through the full
deployment process, creates all the contexts and tries to resolve dependencies,
but it doesn't create any objects or invoke any setters or lifecycle methods.

NOTE: This is only for the deployments. It does need to do the full work
for the deployers and classloaders otherwise they wouldn't be able to do anything. :-)

Then the real deployers simply need to select the approriate contexts based on a DeploymentMode(Runtime,Validation) type of attachment. This of course precludes non-real deployers from directly interacting with any kernels.

[starksm64]

...
There are complications like the XSL deployer which needs to be changed
so you can pass in some form of DOM representation as the predetermined
attachment and still do the XSL transform on it, but this is an exceptional case
caused by badly written deployers that don't have a proper metadata model.

This is a deficiency of the base JAXPDeployer though. If it supported a dom document attachment rather than always parsing a virtual file this would just work. I created the following feature request for that:
http://jira.jboss.com/jira/browse/JBMICROCONT-144

I would assume its easier to add this than update the datasource deployer.