[ http://jira.jboss.com/jira/browse/JBMICROCONT-5?page=comments#action_12314837 ] Dimitris Andreadis commented on JBMICROCONT-5: ----------------------------------------------
I'm adding a comment here, because the forums are down.. Lets say we have: a.bean |-b.bean |-c.jar And just 3 deployers, registered in that priority order: (C)lassLoadingDeployer -> (B)eanDeployer -> (J)ARDeployer. After the deployment structure is analyzed (by the bean & jar deployers) we have the corresponding DeploymentContext/subcontexts in place with each one having recorded its own url as a classpath. How 2nd stage deployment processing would work in this case, wrt depth and priority (.jar comes before .bean, according to suffix rules) C(c.jar) C(b.bean) C(a.bean) B(c.jar) B(b.bean) B(a.bean) J(c.jar) J(b.bean) J(a.bean) Or C(c.jar) B(c.jar) J(c.jar) C(b.bean) B(b.bean) J(b.bean) C(a.bean) B(a.bean) J(a.bean) Also, in the 1st case, should the MainDeployer control the traversal, or simply pass the base context to each deployer, and he traverses at will? Finally, what would the ClassLoadingDeployer do? Judging from the 3.x/4.x mechanism it seems to be creating a UCL for the base node, then adding the classpath of all subnodes to this UCL. (but processing here is parent first). Should I just go to the top most deployment, create a plain URLClassLoader, add all classpaths, and point to it from subcontexts? > Main Deployer > ------------- > > Key: JBMICROCONT-5 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-5 > Project: JBoss MicroContainer > Type: Task > Components: Deployment > Reporter: Adrian Brock > Assignee: Dimitris Andreadis > Fix For: JBossMC_1_0_0M2 > > > MainDeployer > ------------ > The primary methods of MainDeployer are > (re/un)deploy(URL) > other methods are > (un)register/register(deployer, priority) > which will be used by the microcontainer > when a deployer is installed > stats based methods that expose information from the VDF > and config/constructors methods for things like the VDF and > initial deployers. > deploy(url) > 1) create a skeleton VDF context for the top level deployment > 2) ask the structural component chain who recognises it > repeat recursively for identified subcontexts > 3) invoke down the deployment component chain > starting with the deepest subcontexts first > redeploy(url) > similar to deploy() but performing a reinstall on the > microcontainer (i.e. suspend on valve for components being > reinstalled) > undeploy(url) > invoke down the deployment chain in reverse order > to remove the installed components > Reverse order means both in terms of subcontexts > and priority. > (un)register/register(deployer) > The deployer here identifies the structural and > deployment components of the deployer > and their respective "priorities". > This will be the name in the registry which > might be instantiated later. > Where present, the deployer is added to the > relevent chain. > ISSUE: Need to tighten up the semantics of the > register/unregister(deployer) for when the > deployment component has dependencies and > cannot be instantiated immediately -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
