13 Replies Latest reply on Sep 29, 2006 9:02 AM by starksm64

    VFS isLeaf() vs isDirectory()/isFile()

      To avoid the confusion around the isDirectory()/isFile
      I've modified the VFS api to have the single method
      isLeaf() which is effectively isCannotHaveChildren()

      I also fixed the isArchive() so that it means either:
      1) It is an archive
      2) It is a structure pretending to be an archive, e.g. an unpacked directory

      While I was doing this I reworked the VisitorAttribues to
      remove the notions of directory.
      I also changed it so all the defaults are false to make it less
      confusing.

      The mappings are as follows (if you have uncommitted code):
      isFile() -> isLeaf()
      isDirectory() -> isLeaf() == false

      VisitorAttributes.NO_DIRECTORIES -> VisitorAttributes.LEAVES_ONLY
      VisitorAttributes.RECURSE_DIRECTORIES -> VisitorAttributes.RECURSE
      VisitorAttributes.RECURSE_NO_DIRECTORIES -> VisitorAttributes.RECURSE_LEAVES_ONLY

      setIncludeDirectories(false) -> setLeavesOnly(true)
      setIgnoreHidden(false) -> setIncludeHidden(true)

      Hopefully this should avoid some of the confusion that has crept into
      the api? Especially in the jar handlers.

      Finally, I think the VFSScanner should be changed according
      the TODO I added to the code, if it is doing what I think it is doing?

       // TODO replace . in the name with isArchive() == false?
       else if (component.getName().indexOf('.') == -1 && this.doRecursiveSearch)
       {
       // recurse if not '.' in name and recursive search is enabled
       addDeployments(list, component);
       }
      


        • 1. Re: VFS isLeaf() vs isDirectory()/isFile()
          starksm64

          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

             

            "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()

               

              "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()

                or WEB-INF folder in the WARStructureDeployer

                • 5. Re: VFS isLeaf() vs isDirectory()/isFile()

                   

                  "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

                     

                    "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()

                       

                      "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()

                         

                        "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()

                          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

                            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()

                              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

                                 

                                "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

                                  (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.