6 Replies Latest reply on Jan 30, 2005 4:55 PM by starksm64

    VDFComponent

    dimitris

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






        • 1. Re: 3857761

           

          "dimitris@jboss.org" wrote:
          I started with a VDFComponent abstraction that would wrap a URI and provide basic filesystem-like access to it:
          <snip/>


          Good.


          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.


          Aren't VDFContext and VDFComponent the same thing? I just used a different name.
          At no point should it expose File to the users. Everything should be handled via
          URLs, getResource(), InputStream etc.


          - Are we using URIs or not? I see everywhere references to URLs


          The plan is to use URI so we can use logical locations.
          A URI is a superset of URL, i.e. the physical location may not actually exist
          or at least be used.

          We haven't defined how the URI aliases will work yet so you can just use
          URL for now. Include some marker on the interfaces that it needs to be reviewed
          e.g.
          /**
           *@todo URI?
           */
          public URL getURL();
          



          - At the point where the classloaders are created the code is JMX dependent.


          I started a classloader abstraction in kernel. But it is not a complete replacement
          for the UCLs yet. I just wanted to test classloading dependencies.


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


          They should go in system2 (system if you checkout jboss-pojo).
          I want to differentiate the native microcontainer and deployers that
          are built on top it.


          • 2. Re: 3857761
            dimitris

             

            "adrian@jboss.org" wrote:

            Aren't VDFContext and VDFComponent the same thing? I just used a different name. At no point should it expose File to the users. Everything should be handled via URLs, getResource(), InputStream etc.


            Since I started the VDFComponent by replacing direct url access for the URLDeploymentScanner, the abstraction seems like something that lets you navigate over a file system, using a URI as a starting point, and accessing it transparently (either through URL, resource, .etc) However, not every VDFComponent will be a target for deployment.

            On the other hand, VDFContext (which is really DeploymentInfo replacement, or a simple data structure) could include a VDFComponent and add all the deployment specific stuff, e.g. subdeployments.

            • 3. Re: VDFComponent

              Hi Dimitris,

              Just a heads up, in case you missed it...

              "dimitris@jboss.org" wrote:

              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.


              "adrian@jboss.org" wrote:

              They should go in system2 (system if you checkout jboss-pojo).
              I want to differentiate the native microcontainer and deployers that
              are built on top it.



              • 4. Re: VDFComponent
                • 5. Re: VDFComponent
                  dimitris

                  I had read the message, but somehow I managed to do the exact opposite :-)

                  That be easy now, because I moved almost all the new stuff under:

                  org/jboss/deployers/...

                  in contrast to the old

                  org/jboss/deployment/...

                  I'll move it

                  • 6. Re: VDFComponent
                    starksm64

                    Another attribute missing in the VDFComponent is the notion of attributes. The current LastModified is a read-only attribute and Context is a read-write attribute. A generic DirContext like notion of attributes should be available.

                    The DeploymentContext is missing an arbitrary context map that existed in the DeploymentInfo. This is something that is used by the current deployers for shared state.