-
1. Re: VFS isLeaf() vs isDirectory()/isFile()
starksm64 Sep 28, 2006 9:33 AM (in response to adrian.brock)This makes more sense to me, although I still don't believe isArchive is sufficiently different from isLeaf == false to warrant an attribute. Its essentially isLeaf == false + a suffix pattern to indicate this is a special non-leaf. The suggested change of the VFScanner defines such a special non-leaf such that only archives can contain deployable content. Its not clear that the vfs really has sufficient knowledge of a non-leaf to make this distinction. Examples include:
- jars referenced via Class-Path manifest references are not to be considered as deployments.
- we need to support a virtual war/ejb-jar that is directory, that does not have to end in .war/.jar, containing war/ejb-jar contents.
I think we need a basic vfs notion, and an attributed vfs notion where the attributed vfs is a result of metadata coming from the structural analysis. In the attributed vfs I can ask is a non-leaf a deployment container or not. -
2. Re: VFS isLeaf() vs isDirectory()/isFile()
bill.burke Sep 28, 2006 9:52 AM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
- we need to support a virtual war/ejb-jar that is directory, that does not have to end in .war/.jar, containing war/ejb-jar contents.
This is especially true for embedded jboss. -
3. Re: VFS isLeaf() vs isDirectory()/isFile()
adrian.brock Sep 28, 2006 10:00 AM (in response to adrian.brock)"bill.burke@jboss.com" wrote:
"scott.stark@jboss.org" wrote:
- we need to support a virtual war/ejb-jar that is directory, that does not have to end in .war/.jar, containing war/ejb-jar contents.
This is especially true for embedded jboss.
This already works, provided it is a top level directory
or it has a META-INF folder, see the JARStruture deployer. -
4. Re: VFS isLeaf() vs isDirectory()/isFile()
adrian.brock Sep 28, 2006 10:01 AM (in response to adrian.brock)or WEB-INF folder in the WARStructureDeployer
-
5. Re: VFS isLeaf() vs isDirectory()/isFile()
adrian.brock Sep 28, 2006 10:03 AM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
I think we need a basic vfs notion, and an attributed vfs notion where the attributed vfs is a result of metadata coming from the structural analysis. In the attributed vfs I can ask is a non-leaf a deployment container or not.
The attribute VFS notion is the DeploymentContext.
The "isDeployment" is determined by the structure deployers
(or you can pass it in as a predetermined deployment context). -
6. Re: VFS isLeaf() vs isDirectory()/isFile()
starksm64 Sep 28, 2006 11:20 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
"scott.stark@jboss.org" wrote:
- we need to support a virtual war/ejb-jar that is directory, that does not have to end in .war/.jar, containing war/ejb-jar contents.
This already works, provided it is a top level directory
or it has a META-INF folder, see the JARStruture deployer.
or WEB-INF folder in the WARStructureDeployer
Yes, I know, but the existence of a WEB-INF is no longer a defining characteristic of a war. Think about sitting in jbosside with a single jsp or servlet that I want to deploy as a war. I view this as needing to setup a vfs repsentation of a war that is consumed by the structural deployers, and then deployed to the kernel. The virtual aspect of the vfs is being folded into the structural deployers too much currently.
This also does not get to the current question of how the VFScanner knows whether a given VirtualFile contains subdeployers. Maybe this is just a decision it should not be making though. The current recursion behavior is an artifact of porting the old url scanner."adrian@jboss.org" wrote:
The attribute VFS notion is the DeploymentContext.
The "isDeployment" is determined by the structure deployers
(or you can pass it in as a predetermined deployment context).
I suppose this is where I'm currently out of synch. I see too much vfs related structure parsing happening in the structural deployers. I would rather have clearer steps to the structural part of deployment:
1. establish a vfs that encapsulates both the protocol for accessing raw files and structural layout in terms of a root VirtualFile and its children. By this I mean a tree of names is defined, and the basic attributes of the nodes in the tree are defined. This means marking files as ears, ejb-jar, wars, etc.
2. structural deployers come along and identify the virtual file relationships in terms of classpaths, metadata descriptors, etc. -
7. Re: VFS isLeaf() vs isDirectory()/isFile()
adrian.brock Sep 29, 2006 7:23 AM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
I suppose this is where I'm currently out of synch. I see too much vfs related structure parsing happening in the structural deployers. I would rather have clearer steps to the structural part of deployment:
1. establish a vfs that encapsulates both the protocol for accessing raw files and structural layout in terms of a root VirtualFile and its children. By this I mean a tree of names is defined, and the basic attributes of the nodes in the tree are defined. This means marking files as ears, ejb-jar, wars, etc.
2. structural deployers come along and identify the virtual file relationships in terms of classpaths, metadata descriptors, etc.
I completely disagree. The notion of ear, ejb-jar is not a VFS concept
it is a deployment concept.
I'd be more inclined to make the "isArchive" a deployment concept
thus removing it from the VFS layer into the structure deployers.
But this would mean the structure deployers would need to be
an externalisable component such that the VFSScanner instead of
doing:if (file.isLeaf()) deploy(file); else if (file.isArchive()) deploy(file); else scan(file);
It would do:if (structureDeployers.isDeployment(file)) deploy(file); else if (isLeaf() == false) scan(file);
But there is a missing else in the last part where we have
an unrecognised leaf node that is unknown to the main deployer
so it can't report it as "undetermined structure". -
8. Re: VFS isLeaf() vs isDirectory()/isFile()
adrian.brock Sep 29, 2006 7:27 AM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
Yes, I know, but the existence of a WEB-INF is no longer a defining characteristic of a war. Think about sitting in jbosside with a single jsp or servlet that I want to deploy as a war. I view this as needing to setup a vfs repsentation of a war that is consumed by the structural deployers, and then deployed to the kernel.
I view this as a PREDETERMINED deployment context where
you pass in the web metadata (it doesn't even need to be a web.xml
file) and the classpath for the servlet (and its supporting classes).
i.e. it is an adhoc deployment that does not follow the normal structure.
I don't see the need to construct a complicated VFS context
when the simple VDF abstraction can already cope with
"programmatic structure" and can cope with circumstances
where there is no spoon (metadata file). :-) -
9. Re: VFS isLeaf() vs isDirectory()/isFile()
adrian.brock Sep 29, 2006 7:28 AM (in response to adrian.brock)NOTE: predetermined structure does not go through the structure
deployers, there is no need, the user has already told you what they want. -
10. Re: VFS isLeaf() vs isDirectory()/isFile()
starksm64 Sep 29, 2006 8:28 AM (in response to adrian.brock)Identityfing a vfs path as a context for setting up the war structure is far from a predetermined structure. I still need something to translate from a URI to a DeploymentContext (the attributed VirtualFile). The VFScanner does need the structural deployers to do this, and the deployment centric isArchive should be dropped from the VFS to clear up the current confusion on where the functional boundaries are.
In terms of the else clause, the scanner should just be reporting an error that the deployment location contains content that cannot be recognized. -
11. Re: VFS isLeaf() vs isDirectory()/isFile()
adrian.brock Sep 29, 2006 8:41 AM (in response to adrian.brock)Rather than arguing about and disagreeing, I'd suggest we write some
tests for the use cases and implement it.
It sounds like both approaches would work and have different use cases.
1) Being able to attribute a VirtualFile with deployment attributes
and have the structure deployer check the attribute(s).
2) Being able define your own structure by predetermined
deployment contexts.
I still think (2) is simpler.
And more generic since it doesn't require the construction
of metadata files when you already have the metadata object in memory
i.e. constructed on the fly.
It is also unclear to me how the attributes in (1) are
persisted in general? i.e. going beyond the case where
the ide can remember these in some ide config file.
Removing the isArchive() from the VFS layer, requires
the changes I suggested.
However, just ignoring the unrecognised structure means
it will not appear in the summary IncompleteDeployments
unless that processing is extended to include them somehow? -
12. Re: VFS isLeaf() vs isDirectory()/isFile()
starksm64 Sep 29, 2006 8:53 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
Rather than arguing about and disagreeing, I'd suggest we write some
tests for the use cases and implement it.
It sounds like both approaches would work and have different use cases.
1) Being able to attribute a VirtualFile with deployment attributes
and have the structure deployer check the attribute(s).
2) Being able define your own structure by predetermined
deployment contexts.
I still think (2) is simpler.
And more generic since it doesn't require the construction
of metadata files when you already have the metadata object in memory
i.e. constructed on the fly.
It is also unclear to me how the attributes in (1) are
persisted in general? i.e. going beyond the case where
the ide can remember these in some ide config file.
I agree that we need a real demonstration of how the proposed apis are used as in the end that is the determining factor. I don't see that (1) precludes (2). Its just more information into a structural analysis pass, which is still something a naive user of the deployment layer (like the jsr88/profile service) need to be able to translate deployment urls into deployable objects.
In terms of allowing attributes on files, the api will have to support adding them, and how/if they are stored an impl detail of the VFS."adrian@jboss.org" wrote:
Removing the isArchive() from the VFS layer, requires
the changes I suggested.
However, just ignoring the unrecognised structure means
it will not appear in the summary IncompleteDeployments
unless that processing is extended to include them somehow?
I don't see why having the unkown virtual file show up in the IncompleteDeployments is a needed element. In this case we are talking about multiple deployments, not an uknown element inside a top level deployment. How this is handled is purely a VFScanner detail as far as I can see. -
13. Re: VFS isLeaf() vs isDirectory()/isFile()
starksm64 Sep 29, 2006 9:02 AM (in response to adrian.brock)(1) can also be used as input into the handling of the failure to recognize a file. If the user marked a file as a deployable node, failure to recognize the structure is equivalent to the current "no deployers for ...' error of jboss4.