3 Replies Latest reply on Nov 24, 2008 7:22 PM by starksm64

    Adding VFSMetaData for VFS deployment options

    alesj

      WRT:
      - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191875#4191875

      I guess we could add something like I suggested in wrt post.
      Although this looks a lot like jboss-structure.xml and its modification attribute, it is not.
      Since if we don't have noReaper option known before we actually create deployment root, there is no effect in disabling it later,
      as it will already run, hence probably stopping root file from being deleted from external client (e.g. plain File::delete from 2nd JVM),
      therefor not the effect user wanted with this flag.

      And since we already base most of our metadata on xml,
      I would use jboss-vfs.xml instead of before suggested vfs.properties.
      Or eventually it could be both, where jboss-vfs.xml would be easier to evolve,
      but vfs.properties easier to write.

      Although I don't see how I can read this file w/o VFS usage. :-)

        • 1. Re: Adding VFSMetaData for VFS deployment options
          starksm64

          Then we need a check on the vfs file to see if the post structure analysis options are consistent with the already created vfs files. If not, they need to be recreated with the proper options. Basically a second vfs visitor validation phase.

          • 2. Re: Adding VFSMetaData for VFS deployment options
            alesj

            That doesn't help.
            e.g 1st phase already starts reaper

            We need some sort of simple/lightweight VFS lookup,
            just need to get to the contents of META-INF.
            Something conceptually similar to what we do with DeploymentUnit::getResourceClassLoader.
            e.g. creating temp CL

            Lightweight VFS:
            - directories/files --> JDK's File API
            - jars --> a way to read just certain bytes; META-INF/vfs.properties?

            • 3. Re: Adding VFSMetaData for VFS deployment options
              starksm64

              Creating a temp CL is equivalent to creating a VirtualFile that we can throw away without lingering side-effects. Why can't we reap/unreap/whatever with the VFS layers that would be holding locks/streams open and then recreate the VF? I suppose its not a huge issue to require unpacked deployments if you want to supply VFS metadata, but it would be better to avoid such a restriction.