I have gone through the system2 (can be checked out as part of the jbossmc cvs alias or this eclipse project set: http://fisheye.jboss.com/viewrep/JBoss/build/mc/eclipse.psf) and updated the vdf prototype to align with the two phase deployment model we talked about in JBW that is needed for use with the profile service.
As part of this I went over the existing vdf discussion and jira items (see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=58404) and I have the following changes to discuss:
1. I don't see a need to separate structural deployers from runtime deployers. In the previous discussion there was a notion that the structural phase would run a separate deployer stack and that the first deployer that recognized the deployment would win. With the extension of the structural phase to one that essentially parses a physical deployment info metadata that supports the profile service configuration and management view behaviors, essentially every deployer can contribute both forms of metadata to a deployment.
2. Related to this, a DeploymentContext (the object representation of a subdeployment) does not have an associated AspectDeployer. Instead there is a set of deployment types that identify the AspectDeployer that contributed to the metadata and will want to process this context at runtime.
3. The org.jboss.deployers.vdf package which essentially was the virtual file system concept has been replaced with the existing container org.jboss.vfs.* classes. A DeploymentContext has a VirtualFile rather than a VDFComponent.
4. The notion of deployer suffixes in this vdf deployer scheme seems a legacy bootstrap notion at best. The org.jboss.deployers.plugins.MainDeployerImpl externalizes the notion of how a deployment is started to a org.jboss.deployers.spi.DeploymentGraphBuilder which returns a Graph that is a directed graph of the deployment contexts. A depth first traversal of this graph with execution of each deployer that matches the DeploymentContext registered deployment types defines the deployment processing.
The deployment order can therefore be based on the legacy structure/suffix notion, explicit deployment unit/context ordering, ...
5. The JARDeployer notion seems obsolete. The deployment structure is handled by vfs, ClassloaderDeployer, and the deployers themselves.
6. In addition to breaking the AspectDeployer into two distinct phases, there is a notion of a manged object that represents the view a management client would use to update a deployment. This ties into the profile service support for being able to update a deployment in a profile without having a running jboss instance. This is the biggest implementation change to deployers as currently the management interface is an implicit detail based on the jmx beans that happen to show up.
I'm still working on getting this update to the state of actually deploying mc beans and integrating with the profile service. After that getting the other deployers ported over to the vdf needs to be done to fully flesh this out.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954762#3954762
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954762
|
