[ http://jira.jboss.com/jira/browse/JBMICROCONT-4?page=comments#action_12314441 ] Scott M Stark commented on JBMICROCONT-4: -----------------------------------------
Right now the webdav related stuff is in the common module. We need to be careful not to pull in too many dependencies at the micro-container level. We really should redefine what modules we expect to have and what the dependencies are going to be. > Virtual File System service > --------------------------- > > Key: JBMICROCONT-4 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-4 > Project: JBoss MicroContainer > Type: Feature Request > Reporter: Ivelin Ivanov > Assignee: Dimitris Andreadis > Priority: Critical > Fix For: JBossMC_1_0_0M2 > > > [Adrian] > Ok, here is the design I have in mind for the new deployer aspects. > This will be part of JBoss Kernel M2 release due by end of January. > Deploying Deployers: > First you have to be able to deploy a deployer. Not an easy task as I imagine > the deployer will have dependencies on other services. The aim will be to > minimize > these dependencies to ease the problem. > Basic Architecture: > The basic architecture of the aspectized deployer is that the deployments > work with a tree of DeploymentInfo objects just like the deployers do now. > There are two major differences: > 1) The deployers do not deal with urls, they deal with VFS contexts > 2) The deployers do not create objects directly, instead they create kernel > MetaData objects and submit them to the kernel for instantiation/configuration > to obtain correct ordering of startup/shutdown > Deployment Mode: > The deployers work in two different modes > 1) The first step is to ask who recognises the VFS context. This is so > the responsible deployer can correctly decide which part of the context > takes part in the classloading and where the metadata is located. > Additionally, this may introduce subdeployments (VFS contexts) if the > deployment allows/contains them. > 2) The second step (the main chain) allows each deployer to augment the > kernel metadata with its own config. > Deployer Ordering: > Since the deployers are working on a metadata model rather than > constructing objects directly, there should be less problem with ordering. > Most ordering will be in the classloader/instantiation/config stage, > the deployer should insert that ordering in the form of dependencies in the > metadata. > The only ordering required of the deployer chain is where one deployer > needs to work on the kernel metadata output of another deployer. > Killing two birds with one stone: > The problems mentioned with the deployer requiring other services > and the first tasks performed by package specific deployers, > i.e. identifying the deployment and its structure > can be easily solved by splitting the deployers into two classes > 1) A structural component that says "I recognise this deployment and this is > how it is structured" > 2) An interpretive component that creates the kernel metadata from the > package. -- 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 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development