1 2 Previous Next 21 Replies Latest reply on Jul 30, 2009 3:27 AM by ropalka

    VFS3 - missing features and other issues

    alesj

      To follow up today's VFS3 discussion, I'm opening a forum thread where we should discuss missing features and any other issues.

      The current VFS3 svn can be found here:
      - http://anonsvn.jboss.org/repos/jbossas/projects/vfs/branches/dml-zip-rework/

      My initial port of CL to VFS3 shows missing API:
      * http://anonsvn.jboss.org/repos/jbossas/projects/vfs/trunk/src/main/java/org/jboss/virtual/MemoryFileFactory.java
      * http://anonsvn.jboss.org/repos/jbossas/projects/vfs/trunk/src/main/java/org/jboss/virtual/AssembledDirectory.java

      The good thing is the we were pretty strict with VFS wrt API,
      hence the only user API was held in
      - http://anonsvn.jboss.org/repos/jbossas/projects/vfs/trunk/src/main/java/org/jboss/virtual/
      so, it currently looks like once we get those two impled we should be fine.

        • 1. Re: VFS3 - missing features and other issues
          alesj

          I just stumbled upon JarUtils, which proves me wrong here

          "alesj" wrote:

          The good thing is the we were pretty strict with VFS wrt API,
          hence the only user API was held in

          :-(

          What should we do with it?
          I guess we can move it to org.jboss.virtual.util package?

          • 2. Re: VFS3 - missing features and other issues
            alesj

             

            "alesj" wrote:

            What should we do with it?
            I guess we can move it to org.jboss.virtual.util package?

            I currently put it to the same place as it was - org.jboss.virtual.plugins.context.jar.

            • 3. Re: VFS3 - missing features and other issues
              alesj

              I created a CL branch based on VFS3 and it already compiles. :-)
              - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/branches/Trunk_VFS3/
              But since we're not properly mounting things, most of the VFS tests fails.

              What would be the best way to fix this, to generically mount whatever needs to be mounted?

              • 4. Re: VFS3 - missing features and other issues
                dmlloyd

                 

                "alesj" wrote:

                My initial port of CL to VFS3 shows missing API:
                * http://anonsvn.jboss.org/repos/jbossas/projects/vfs/trunk/src/main/java/org/jboss/virtual/MemoryFileFactory.java
                * http://anonsvn.jboss.org/repos/jbossas/projects/vfs/trunk/src/main/java/org/jboss/virtual/AssembledDirectory.java


                AssembledDirectory shouldn't be needed anymore with the new design (there is only one view of the VFS and that's the fully assembled view).

                MemoryFileFactory should be replaced with an alternative API... right now it all needs to be explicit (make a temp dir, mount the temp dir in the real VFS, and use getPhysicalFile() to make modifications). I think a static method might be a good idea to do this automatically though.

                Also the temp file API is bad and needs to be redone. I'll do so next week.

                • 5. Re: VFS3 - missing features and other issues
                  dmlloyd

                   

                  "alesj" wrote:
                  I just stumbled upon JarUtils, which proves me wrong here
                  "alesj" wrote:

                  The good thing is the we were pretty strict with VFS wrt API,
                  hence the only user API was held in

                  :-(

                  What should we do with it?
                  I guess we can move it to org.jboss.virtual.util package?


                  Throw it away. All it is used for is identifying archives, which is up to the individual deployers.

                  • 6. Re: VFS3 - missing features and other issues
                    dmlloyd

                     

                    "alesj" wrote:
                    I created a CL branch based on VFS3 and it already compiles. :-)
                    - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/branches/Trunk_VFS3/
                    But since we're not properly mounting things, most of the VFS tests fails.

                    What would be the best way to fix this, to generically mount whatever needs to be mounted?


                    I think the explicit mount needs to be either part of the test case or part of the test suite setup. Probably the latter. Then the unmount/cleanup would happen in the teardown.

                    • 7. Re: VFS3 - missing features and other issues
                      alesj

                       

                      "david.lloyd@jboss.com" wrote:

                      AssembledDirectory shouldn't be needed anymore with the new design (there is only one view of the VFS and that's the fully assembled view).

                      MemoryFileFactory should be replaced with an alternative API... right now it all needs to be explicit (make a temp dir, mount the temp dir in the real VFS, and use getPhysicalFile() to make modifications). I think a static method might be a good idea to do this automatically though.

                      I only need this API for back-compatibility.
                      How it's implemented in the back, I don't care.
                      But not having this would mean huge changes to MC testing,
                      as a lot CL, Deployers, WB, ... tests depends on it.

                      You can definitely deprecate it, and write better suited API to the new VFS API.

                      • 8. Re: VFS3 - missing features and other issues
                        alesj

                         

                        "david.lloyd@jboss.com" wrote:
                        Throw it away. All it is used for is identifying archives, which is up to the individual deployers.

                        Afair there was more to it than just deployers.
                        The idea was to keep the suffixes in a single place.
                        And there was nothing more close to the hierarchy top then VFS which was using it.

                        I guess I can move it to Common-core, as there is already some JarUtils.
                        And who ever uses that should populate it properly.


                        • 9. Re: VFS3 - missing features and other issues
                          alesj

                           

                          "david.lloyd@jboss.com" wrote:

                          I think the explicit mount needs to be either part of the test case or part of the test suite setup. Probably the latter. Then the unmount/cleanup would happen in the teardown.

                          I think we should also check an option of having auto-mount/unmount.


                          • 10. Re: VFS3 - missing features and other issues
                            dmlloyd

                             

                            "alesj" wrote:
                            "david.lloyd@jboss.com" wrote:

                            I think the explicit mount needs to be either part of the test case or part of the test suite setup. Probably the latter. Then the unmount/cleanup would happen in the teardown.

                            I think we should also check an option of having auto-mount/unmount.


                            Auto mount is easy. It's the unmount that's the problem - that's how we get into situations where we leak temp files everywhere. There's no way to detect when the filesystem isn't used anymore. That's the whole reason for the explicit mount/unmount design, and adding automount will just reintroduce the original problem again. Correctness is more important that ease of use in this case. Though honestly, keeping track of your resources and explicitly unmounting is not that hard - I don't see why it is such a burden.

                            • 11. Re: VFS3 - missing features and other issues
                              dmlloyd

                               

                              "alesj" wrote:
                              "david.lloyd@jboss.com" wrote:
                              Throw it away. All it is used for is identifying archives, which is up to the individual deployers.

                              Afair there was more to it than just deployers.
                              The idea was to keep the suffixes in a single place.


                              And this is a bad idea, as any deployer might use any extension for an archive. They should not be limited to a single global static list. And it's not appropriate for an archive deployer to explicitly manage nested archives of a type with which it is not familiar or authoritative over.

                              • 12. Re: VFS3 - missing features and other issues
                                dmlloyd

                                 

                                "alesj" wrote:
                                "david.lloyd@jboss.com" wrote:

                                AssembledDirectory shouldn't be needed anymore with the new design (there is only one view of the VFS and that's the fully assembled view).

                                MemoryFileFactory should be replaced with an alternative API... right now it all needs to be explicit (make a temp dir, mount the temp dir in the real VFS, and use getPhysicalFile() to make modifications). I think a static method might be a good idea to do this automatically though.

                                I only need this API for back-compatibility.
                                How it's implemented in the back, I don't care.
                                But not having this would mean huge changes to MC testing,
                                as a lot CL, Deployers, WB, ... tests depends on it.

                                You can definitely deprecate it, and write better suited API to the new VFS API.


                                If you want to add it back in, be my guest - it just means putting off the same work until later though. Except then it will probably be even more difficult since more time will pass allowing the API to become even more entrenched. We intended to change or remove the tests (some of the tests seem to exist only to test this feature; it would be strange to add the feature just to make those tests work). As for the other stuff, the temp file API needs to be fixed up a bit to allow for those components to be ported (remember that this is an unfinished prototype). I think the quick/easy fix would be a mistake here.

                                • 13. Re: VFS3 - missing features and other issues
                                  jason.greene

                                   

                                  "david.lloyd@jboss.com" wrote:
                                  "alesj" wrote:
                                  "david.lloyd@jboss.com" wrote:

                                  AssembledDirectory shouldn't be needed anymore with the new design (there is only one view of the VFS and that's the fully assembled view).

                                  MemoryFileFactory should be replaced with an alternative API... right now it all needs to be explicit (make a temp dir, mount the temp dir in the real VFS, and use getPhysicalFile() to make modifications). I think a static method might be a good idea to do this automatically though.

                                  I only need this API for back-compatibility.
                                  How it's implemented in the back, I don't care.
                                  But not having this would mean huge changes to MC testing,
                                  as a lot CL, Deployers, WB, ... tests depends on it.

                                  You can definitely deprecate it, and write better suited API to the new VFS API.


                                  If you want to add it back in, be my guest - it just means putting off the same work until later though. Except then it will probably be even more difficult since more time will pass allowing the API to become even more entrenched. We intended to change or remove the tests (some of the tests seem to exist only to test this feature; it would be strange to add the feature just to make those tests work). As for the other stuff, the temp file API needs to be fixed up a bit to allow for those components to be ported (remember that this is an unfinished prototype). I think the quick/easy fix would be a mistake here.


                                  Well, lets see how porting the main VFS testsuite goes, then look at the impact of the other usages. We definitely don't want to lose valid test scenarios. An auto-mount capability, or at least some utility class that does mount everything in advance would not be a bad thing for tests which verify scenarios that happen after the deployers would mount anyway. We do need to make sure that we are actually testing the way AS uses (or will use) the VFS, else the tests aren't that helpful.


                                  • 14. Re: VFS3 - missing features and other issues
                                    dmlloyd

                                    I committed static helper methods to make mounting various filesystem types less onerous. They are in the VFS class, called mount*().

                                    1 2 Previous Next