[ http://jira.jboss.com/jira/browse/JBMICROCONT-4?page=comments#action_12310879 ] Adrian Brock commented on JBMICROCONT-4: ----------------------------------------
Guys, maybe we shouldn't call it a VFS. Perhaps (VDF) Virtual Deployment Framework is a better name. The purpose of the coponent isn't to abstract away the protocol (though that will be a part of it). In fact for the osgi facade there will be a requirement for a component to get URLHandlers. The purpose of the VDF is to abstract away: 1) The meta data location 2) The real urls that make up the classpath 3) Identifying subdeployments 4) The unpacking of the subdeployments into a temporary location 5) The downloading of remote deployments to the temporary location 6) Unpacked/packed deployments 7) The logical urls that make up the codebase for security checks > 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
