1 2 Previous Next 26 Replies Latest reply on Sep 16, 2009 6:23 AM by alesj Go to original post
      • 15. Re: Exploding jar libraries in deployments
        alrubinger

         

        "jason.greene@jboss.com" wrote:
        Why don't you just switch from vfsmrmory to using a file based VFS on a temp location for now, until we see what happens with VFS in trunk?


        I should write a new virtual archive impl just for this one case, which could be addressed through the addition of one overloaded method in VFS?

        S,
        ALR

        • 16. Re: Exploding jar libraries in deployments
          jason.greene

           

          "ALRubinger" wrote:
          "jason.greene@jboss.com" wrote:
          Why don't you just switch from vfsmrmory to using a file based VFS on a temp location for now, until we see what happens with VFS in trunk?


          I should write a new virtual archive impl just for this one case, which could be addressed through the addition of one overloaded method in VFS?


          Is it really that hard to copy files into a temp dir and point the VFS at it?

          Part of the reason for issues with the current VFS impl is that everyone treats it like some magic silver-bullet and keeps hacking it to solve problems that should be solved elsewhere.

          • 17. Re: Exploding jar libraries in deployments
            alrubinger

             

            "jason.greene" wrote:
            Part of the reason for issues with the current VFS impl is that everyone treats it like some magic silver-bullet and keeps hacking it to solve problems that should be solved elsewhere.


            Let's forget for a moment that JBossWeb has this dependency upon a flat file structure. They've identified this and will be correcting it in the future.

            Use case:

            I have a vfsmemory archive. I want to copy its contents as a flat directory. With other VirtualFileHandler impls this is possible, but not currently memory. Which to me is a hole in the abstraction layer.

            S,
            ALR

            • 18. Re: Exploding jar libraries in deployments
              wolfc

              Don't blame the use case for the fact that VFS can't unjar vfsmemory.

              It's a plain bug in VFS.

              • 19. Re: Exploding jar libraries in deployments
                jason.greene

                 

                "ALRubinger" wrote:

                Use case:

                I have a vfsmemory archive. I want to copy its contents as a flat directory. With other VirtualFileHandler impls this is possible, but not currently memory. Which to me is a hole in the abstraction layer.


                vfsmemory is not a use case, is a solution (a bad one at that). The use case is you have some files you want to make into a deployment. The VFS is not supposed to be a virtual deployment API, event though it keeps getting hacked to be one.

                • 20. Re: Exploding jar libraries in deployments
                  jason.greene

                   

                  "wolfc" wrote:
                  Don't blame the use case for the fact that VFS can't unjar vfsmemory.

                  It's a plain bug in VFS.


                  Yes, it's broken, among other things, which is why its currently nuked from the VFS3 prototype.

                  • 21. Re: Exploding jar libraries in deployments
                    alrubinger

                     

                    "jason.greene@jboss.com" wrote:
                    The use case is you have some files you want to make into a deployment. The VFS is not supposed to be a virtual deployment API, event though it keeps getting hacked to be one.


                    To be very clear, I have my own Deployment type. But in the end deployable types are backed by some file-esque archive. And I happen to be using the vfsmemory backend. So I expect it to support the full range of operations permitted upon VirtualFile.

                    S,
                    ALR

                    • 22. Re: Exploding jar libraries in deployments
                      alesj

                       

                      "ALRubinger" wrote:

                      I have a vfsmemory archive. I want to copy its contents as a flat directory. With other VirtualFileHandler impls this is possible, but not currently memory. Which to me is a hole in the abstraction layer.

                      OK, I think the only proper solution here is to make this VFSUtils::unjar take into account all possible VFSHandler types,
                      while the end result should be exactly the same as what original (from Common-core) unjar creates.

                      You (and definitely *not* Carlo) are free to hack this away on Branch_2_0, and if you need any help let me know.
                      Or you would rather see that I hack this?

                      • 23. Re: Exploding jar libraries in deployments
                        alrubinger

                         

                        "alesj" wrote:
                        You (and definitely *not* Carlo) are free to hack this away on Branch_2_0, and if you need any help let me know.
                        Or you would rather see that I hack this?


                        I'll open an issue and submit my patches for you to reject. ;)

                        S,
                        ALR

                        • 24. Re: Exploding jar libraries in deployments
                          alesj

                           

                          "ALRubinger" wrote:

                          submit my patches for you to reject. ;)

                          If it will be any near Carlo's MC hacks, I can reject it right now, and save you the trouble. :-)

                          Just kiddin', go ahead.
                          Dunno how useful you will find the current VFSUtils::(modification-type) tests.

                          Perhaps move the current unjar to legacyUnjar (or some better name),
                          and test your work with the current tests.
                          Or try adding a few new ones. ;-)

                          • 25. Re: Exploding jar libraries in deployments
                            jaikiran

                             

                            "jaikiran" wrote:

                            I'll create a JIRA for this and attach the testcase.


                            This is taking longer than i expected. It's going to take some more time. Turns out the way MainDeployer deploys applications (this is how it's done in testcase), behaves differently from directly deploying in the deploy folder.

                            There is some VFS magic in AbstractWarDeployer http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x/server/src/main/org/jboss/web/deployers/AbstractWarDeployer.java which adds the "org.jboss.web.expandedWarClasspath" classpath attachment to the war deployment. And this behaves differently when deploying through MainDeployer (whose input is the entire path of the war outside the AS structure) and when deployed by placing in deploy folder of AS:

                            // get the real unjared url
                             expWarUrl = VFSUtils.getRealURL(unjared);
                            
                             // Map
                             String warPathName = root.getPathName();
                             if (warPathName.endsWith("/") == false)
                             warPathName += "/";
                             List<VirtualFile> classpathVFs = vfsUnit.getClassPath();
                             if (classpathVFs != null)
                             {
                             List<URL> classpath = new ArrayList<URL>();
                             for (VirtualFile vf : classpathVFs)
                             {
                             try
                             {
                             String path = vf.getPathName();
                             if (path.startsWith(warPathName))
                             {
                             path = path.substring(warPathName.length());
                             URL pathURL = new URL(expWarUrl, path);
                             classpath.add(pathURL);
                             }
                             else
                             {
                             log.debug("Ignoring path element: " + vf);
                             }
                             }
                             catch (Exception e)
                             {
                             log.debug("Ignoring path element: " + vf, e);
                             }
                             }
                             unit.addAttachment("org.jboss.web.expandedWarClasspath", classpath);
                             }
                            
                            
                            


                            In short, i need more time :)


                            • 26. Re: Exploding jar libraries in deployments
                              alesj

                              Looking at the issue more closely,
                              I don't think handling of vfs-memory via some copy mechanism would actually help here.
                              As it would be the tld handling that wouldn't work then - as shown in our initial exception.

                              tld handling currently explicitly expects zip file,
                              where in our case we wouldn't know how to generically create one out from vfs-memory contents.
                              Only proper solution, and that's what Remy is currently working on, is to have tld handling ported (back) to VFS.

                              1 2 Previous Next