3 Replies Latest reply on Aug 23, 2009 1:40 PM by alrubinger

    Change requests for TMPARCH-9

    alrubinger

      In building upon the work done in TMPARCH-9 to make a VFS Implementation of a storage engine (https://jira.jboss.org/jira/browse/TMPARCH-16), I've come across the following points for discussion/adjustment:

      * Seems the only purpose of MemoryMapArchiveImpl is to implement "getActualClass()". This returns the type MemoryMapArchive, which isn't really implementation-specific. Can the done in the MemoryMapArchiveBase (if we even need a base for this, probably just the impl will do).
      * MemoryMapArchiveBase.toString(boolean) never checks for if "false" is specified, in which case we should delegate to the no-arg method.
      * MemoryMapArchiveBase.toString(boolean) internally does a Comparable implementation (as TODO), though BasicPath provides this. I'll now commit as part of the Path contract that Comparable is extended, so we can do away with this extra bit.
      * MemoryMapArchiveBase should be documented as Thread-safe (it appears to be)

      S,
      ALR

        • 1. Re: Change requests for TMPARCH-9
          alrubinger

           

          "ALRubinger" wrote:
          * Seems the only purpose of MemoryMapArchiveImpl is to implement "getActualClass()". This returns the type MemoryMapArchive, which isn't really implementation-specific. Can the done in the MemoryMapArchiveBase (if we even need a base for this, probably just the impl will do).


          MemoryMapArchiveImpl also closes the generic context; perhaps this was the intent?

          • 2. Re: Change requests for TMPARCH-9
            johnbailey

            The primary purpose of MemoryMapArchiveImpl was to close the generic context. It seemed like MemoryMap would be a good base of storage archives, but the I wanted to make sure the extensions could still benifit from the generic chaining, but also provide a default impl that doesn't require a generic paramer type.

            Is there another way you would like to handle this?

            • 3. Re: Change requests for TMPARCH-9
              alrubinger

               

              "johnbailey" wrote:
              Is there another way you would like to handle this?


              Nah, if you wanna keep the context open that's cool.

              S,
              ALR