6 Replies Latest reply on Jun 30, 2010 2:49 PM by alrubinger

    ArchiveAsset and Exporters

    alrubinger

      https://jira.jboss.org/browse/SHRINKWRAP-199

       

      We never really got it right with ArchiveAsset.

       

      The Asset contract states that anything may be added to an archive, so long as it may be represented as a stream of bytes (ie. InputStream).  Archives simply cannot fulfill this contract; they may be a stream of bytes in any number of export formats: ZIP, TAR, TAR.GZ, TAR.BZ2.  Or they may be exploded into a directory structure, which is not a stream at all.  In the exploded case, this is more closely covered by archive.merge(), where the contents of an archive can be placed into another.

       

      Asset.openStream is used in the following cases:

       

      1. Exporting an archive
      2. GlassFish Extension (ShrinkwrapReadableArchiveImpl)
      3. VFS3 Extension

       

      Technically archives should be able to hold *any* object-based content.  It's only when the content is read that we need some mechanism to convert this to a stream.

       

      So we've discussed a bit in #jbosstesting the idea of adding any "Storable" type, and at the time it's read out again let the user supply some converter/exporter for each path.  The more I think on this, though technically workable, it sounds complex/involved/not worth it.  User code would be able to add anything, but have to supply some converter to read it out or export.  However this is more versatile; the user could add any content and export it in any number of different combinations.

       

      The path I think we should take is this:

       

      Explicitly define the exporter used for a nested archive when adding it to another archive.  It's contents would be exported on add, and changes to the nested archive would no longer be reflected in the parent.

       

      It's the least flexible solution, but IMO the most deterministic and simplest from an API perspective.  Honestly I think the main use cases say that the developer will know the target export type of the nested archive when it's added, so it's no problem for them to specify it at that time, and do the export of the nested archive as part of the addition operation:

       

       

        /**
          * Add an archive under a specific context and maintain the archive name as 
          * context path.
          * 
          * @param path to use 
          * @param archive to add
          * @param exporter Exporter type to use in fulfilling the {@link Asset#openStream()} contract for 
          *   the added (nested) archive.  
          * @return
          * @throws IllegalArgumentException If any argument is not specified
          */
         T add(Archive<?> archive, ArchivePath path, Class<? extends StreamExporter> exporter) throws IllegalArgumentException;
      
      

       

      Thoughts?

       

      S,

      ALR

        • 1. Re: ArchiveAsset and Exporters
          alrubinger

          Note:

           

          The current state in SVN does not do the export on add.  It simply associates an Archive with a StreamExporter type in ArchiveAsset.  We could also add some hooks to Archive saying "archive.setExportFormat(ArchivePath path,Class<? extends StreamExporter> exporter);" to change the export format of nested archives. 

           

          Again, here we're specifying export formats of nested stuff on add or thereafter, not on export itself.  Still seems simpler IMO.  Aslak had also pointed out that we could allow "archive.export(Map<ArchivePath,Class<? extends StreamExporter>)" to define exporter types on the export operation itself.  This however doesn't address the VFS3, GlassFish, or any other read-based operations (which may be manually by archive.getContents and iterating over Asset types).  For an archive to go into another archive, it simply must have a StreamExporter association.

           

          S,

          ALR

          • 2. Re: ArchiveAsset and Exporters
            aslak

            Just to add to the different options of export:

             

            - Exploded archive inside a Stream.  e.g. my.ear/my.jar/my.class

            • 3. Re: ArchiveAsset and Exporters
              alrubinger

              Huh?

              • 4. Re: ArchiveAsset and Exporters
                aslak

                Andrew Rubinger wrote:

                 

                Archives simply cannot fulfill this contract; they may be a stream of bytes in any number of export formats: ZIP, TAR, TAR.GZ, TAR.BZ2.  Or they may be exploded into a directory structure, which is not a stream at all. 

                It's not necessarily either Exploded or Stream. A Zip can contain a Exploded Nested Archive as well.

                • 5. Re: ArchiveAsset and Exporters
                  alrubinger

                  That's just recursing my statement.  Archives may be represented in some format, and in turn may contain more archives, which in turn contain more...

                   

                  S,

                  ALR

                  • 6. Re: ArchiveAsset and Exporters
                    alrubinger

                    Aslak Knutsen wrote:

                     

                    It's not necessarily either Exploded or Stream. A Zip can contain a Exploded Nested Archive as well.

                    Also, let's be careful with terminology.   A ZIP cannot contain an Archive at all.  Once exported to ZIP, you've just got Entries and content again.  We've lost the archive associations.

                     

                    S,

                    ALR