VDFComponent
dimitris Jan 6, 2005 12:58 PMI started with a VDFComponent abstraction that would wrap a URI and provide basic filesystem-like access to it:
public URI getURI(); public String getScheme(); public String getBaseName(); public long getLastModified(); public boolean exists(); public boolean isFile(); public boolean isDirectory(); public VDFComponent[] getChildren(); public void setContext(Object ctx); public Object getContext();
I wrote a simple file-based implementation and a modified version of the URLDeploymentScanner over it; that worked and was checked in common & system
Then, I took the MainDeployer and started removing functionality and putting in the VDFComponent, so that it handles the copying/packing of the pointed resource, keeping the MainDeployer operational, so I can test. That introduced more methods on the VDFComponent interface, which are probably temporarily there, like:
public File getLocalFile(); public URLClassLoader getLocalClassLoader(); public Manifest getManifest(); public VDFComponent[] getManifestComponents();
Now, I'm reading the deployer overview in JIRA, and have some questions:
- It seems to me the VDFContext (replacing DeploymentInfo) should probably contain a VDFComponent that encapsulates fields like 'name', 'logical/physical url', 'manifest', etc.
- Are we using URIs or not? I see everywhere references to URLs
- At the point where the classloaders are created the code is JMX dependent.
- Are the new MainDeployer/Deployer, etc. to be part of the new 'system' or 'kernel' module? I mean, what is the strategy there: to re-write them as completely new components? Maintain compatibility with the interfaces of the old ones???
- I guess the vdf stuff should move to kernel, as well.
At this point there are dependencies everywhere, so any pointers to 'leaf' components that could be developed by 'translating' existing functionality, are appreciated.
I'll see to check in my prototypes in the new structure...