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
Assigned to: 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
