[ http://jira.jboss.com/jira/browse/JBMICROCONT-4?page=comments#action_12310960 ] Dimitris Andreadis commented on JBMICROCONT-4: ----------------------------------------------
I've been experimenting with wrapping apache-vfs as a plug-in to jboss-vdf (virtual deployment framework?) As a starting point I made some packages under: org.jboss.vdf.spi org.jboss.vdf.plugins.vfs and I'm trying to re-write a deployment scanner over this, slowly adding the features required. It still needs a lot of work and testing but the result seems interesting, in that we could have a single scanner potentially scanning different filesystem types over the VFS plug-in by simply supplying different URIs, e.g.: file:/c:/jboss/deploy webdav:http://remote.server/deploy smb: ... (samba filesystem) (you could also have a different VDF plug-in, or plug-ins to the VFS plugin...) Then, I'd probably try to re-write one of the deployers using this, assuming this is the only way to come up with a working VDF api. I'm wondering about the proper location for checking in this. Currently I need to have it in HEAD/system to drive the development using a working server. I just chose package names that will presumably move easily to the HEAD/kernel module at a later time. Is there a better location for this code? > 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
