8 Replies Latest reply on Oct 22, 2009 3:43 PM by alesj

    Autoexplosion of archives

    bob.mcwhirter

      Is there some standard or default way to mark certain archives as needing exploding before doing a true deployment, or even structure deployment?

      Turns out, even with the .rails archives bit, the JRuby bits aren't quite happy with URLs yet.

      I'd like a deploy/myapp.rails file, if it's not already exploded, to get exploded under tmp/... somewhere before structure recognition and metadata deployment. But if it is exploded (or a symlink to an exploded directory tree), just use it as-is.

      Bonus points if the link between deploy/myapp.rails and tmp/myapp.rails/ exploded directory is kept, and undeploy/redeploy still exists.

      If I have to write it myself, would you think it's a PARSE stage deployer looking for .rails? Will MC hand me non-leaf VirtualFiles for deployment? "Parsing" of the archive could be a visitor that explodes it into tmp/ and then deploys that new unit?

      Thanks for any insight,

      -Bob

        • 1. Re: Autoexplosion of archives
          alesj

          We already have this. ;-)

          You can define this in jboss-structure.xml.
          Its context element takes modification attribute.
          It can either be "temp", "unpack" or "explode":
          - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-core-spi/src/main/java/org/jboss/deployers/spi/structure/ModificationType.java

          Dunno how will this fix URLs issues,
          as they will still remain VFS urls.

          Refs are correctly re-wired, deployers have no knowledge of any modification.

          • 2. Re: Autoexplosion of archives
            alesj

             

            "alesj" wrote:
            Its context element takes modification attribute.

            Eventually this is part of ContextInfo,
            so you can pre-determine this yourself.

            • 3. Re: Autoexplosion of archives
              bob.mcwhirter

              Yah, if the top-level deployment isn't bundled up in an archive, I can assume it's filesystem-based and can do vfsFile.toURL().getFile(). It might be somewhat evil, but it works for me so far. :)

              • 4. Re: Autoexplosion of archives
                bob.mcwhirter

                I'm finding this difficult to get right...

                If I use TEMP, it seems to just copy my archive into tmp/ as a single file.

                If I use EXPLODE, it recursively explodes my archive, along with any .jar contained within. This upsets jruby, because it expects foo.jar to be a jarfile, not a directory.

                If I use UNPACK, nothing happens. The UnpackCopyMechanism gives up at the root level, since it's testing if it's nested inside something else.

                What I effectively want is just a top-level un-jarring.

                as if I'd done

                jar xvf myapp.rails

                and deposited the results into tmp/myapp-tmp/...

                My RailsStructure is creating a ContextInfo attached to the StructureContext, and setting the modification type upon it.

                Should I instead be also creating a ContextInfo for each top-level child I want slurped out of my archive?

                Thanks,

                -Bob

                • 5. Re: Autoexplosion of archives
                  alesj

                   

                  "bob.mcwhirter" wrote:
                  I'm finding this difficult to get right...

                  There might not be the modification type you're looking for.
                  But it's easy to add what ever you want. ;-)

                  And I also see types behave as I expected. :-)

                  You're welcome to impl "top" == 'I effectively want is just a top-level un-jarring'.
                  And I'll add it to VFS 2.0.1. ;-)

                  • 6. Re: Autoexplosion of archives
                    bob.mcwhirter

                     

                    "alesj" wrote:

                    There might not be the modification type you're looking for.
                    But it's easy to add what ever you want. ;-)


                    Yah, I looked at that too. Though, that requires extending the ModificationType enumeration and registering a ModificationAction. Non-trivial to try out a different ModificationAction, it would seem.

                    Perhaps a ModificationType.ATTACHED and go looking for a ModificationAction.class attachment if set?

                    "alesj" wrote:

                    And I also see types behave as I expected. :-)


                    Yah, I think they all work as expected, just not a complete set from my POV. I did see some examples with an UNPACK on the root, but that seems to be non-tenable. UNPACK only works on child context-infos from the look of it. Else, the isNested() check stops it on the root without doing anything if you point it at the root deployed archive, not a nested archive.

                    "alesj" wrote:

                    You're welcome to impl "top" == 'I effectively want is just a top-level un-jarring'.
                    And I'll add it to VFS 2.0.1. ;-)


                    I'll poke around, but I should be able to tell the difference between foo.jar as a real directory and foo.jar as a mounted vfszip? I can still do a byte-for-byte copy of a vfszip-mounted JAR?

                    I'll work on an implementation.

                    Thanks!

                    -Bob

                    • 7. Re: Autoexplosion of archives
                      alesj

                       

                      "bob.mcwhirter" wrote:

                      Yah, I looked at that too. Though, that requires extending the ModificationType enumeration and registering a ModificationAction. Non-trivial to try out a different ModificationAction, it would seem.

                      Perhaps a ModificationType.ATTACHED and go looking for a ModificationAction.class attachment if set?

                      I don't think it makes sense to go that far,
                      we just need to cover all useful cases,
                      as I think there are not that many of them.

                      Apart from your case + the one's we already have,
                      I can't think of another one. :-)

                      "bob.mcwhirter" wrote:

                      Yah, I think they all work as expected, just not a complete set from my POV. I did see some examples with an UNPACK on the root, but that seems to be non-tenable. UNPACK only works on child context-infos from the look of it. Else, the isNested() check stops it on the root without doing anything if you point it at the root deployed archive, not a nested archive.

                      Yes, unpack is only meant for nested jars.

                      "bob.mcwhirter" wrote:

                      I'll poke around, but I should be able to tell the difference between foo.jar as a real directory and foo.jar as a mounted vfszip?

                      From VFS no.
                      We already had this dev discussion,
                      and afaik Scott had some good arguments.

                      In the worst case you can do this:
                      - http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/main/org/jboss/system/server/profile/basic/MetaDataAwareProfile.java
                      See hasBeenModified.

                      "bob.mcwhirter" wrote:

                      I can still do a byte-for-byte copy of a vfszip-mounted JAR?

                      Sure.

                      "bob.mcwhirter" wrote:

                      I'll work on an implementation.

                      + tests. ;-)