5 Replies Latest reply on May 29, 2007 10:14 AM by bill.burke

    PROBLEM: No default VFS behavior

    bill.burke
    bill.burke May 8, 2007 4:01 PM

      A problem showed up in Embedded JBoss that a user had a custom URL type that obviously wasn't handled by the VFS:

      http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4044050#4044050

      I'm wondering if we should provide some default behavior in the VFS similarly the way URL Classloaders work. For instance, with URL Classloaders if the URL ends with '/' a directory structure is assumed, if it doesn't then it considers it a JAR. Intuitively, I think we could provide some similar default behavior with the VFS so that we don't necessarily have to require custom VFS plugins for every URL type. At least we could default the JAR case.

      Bill

      • 97345 Views
      • Tags:
        • 1. Re: PROBLEM: No default VFS behavior
          mangokiwi May 10, 2007 11:09 AM (in response to bill.burke)

          Hi,

          I am the person who is having problems with the URLHandler in eclipse/equinox fighting the Embedded Jboss urlhandler.

          If you want me to try something out, want stack traces from a URLHandler problem, generally want more information about what I am encountering, etc, let me know.

          Diwant

            • Actions
          • 2. Re: PROBLEM: No default VFS behavior
            adrian.brock May 16, 2007 1:04 PM (in response to bill.burke)

            Isn't the intention to remove the URLHandler stuff once we have the VFS based classloader?
            What other reason is there for the URLHandler other than workarounds for the
            URLClassLoader behaviour?

              • Actions
            • 3. Re: PROBLEM: No default VFS behavior
              mangokiwi May 17, 2007 1:41 PM (in response to bill.burke)

              I *believe* that Equinox/Eclipse uses its own set of disjointed class loaders to implement its osgi bundling system.

              (OSGi bundling system means you can throw in disjointed pieces of code as bundles and the OSGi framework will dynamically load them and allow them to extend each other).

              To implement the OSGi part, Equinox/Eclipse uses a strange kind of class loading where each bundle gets its own class loader. So I think the VFS based classloader may not play ball nicely with this kind of setup.

              Diwant

                • Actions
              • 4. Re: PROBLEM: No default VFS behavior
                adrian.brock May 21, 2007 2:43 AM (in response to bill.burke)

                 

                "mangokiwi" wrote:
                I *believe* that Equinox/Eclipse uses its own set of disjointed class loaders to implement its osgi bundling system.


                What does that have to do with anything?
                JBoss inside Eclipse will either use the eclipse classloader (with no hotdeploy)
                like JBoss Embedded or it will bootstrap its own classloading (with no
                reference to eclipse classes).

                The issue is with the competition to define URLStreamHandlers
                something which should not be necessary with JBoss Embedded style deployments.

                  • Actions
                • 5. Re: PROBLEM: No default VFS behavior
                  bill.burke
                  bill.burke May 29, 2007 10:14 AM (in response to bill.burke)

                  Adrian, deployers use VFS handles to scan archives. If JBoss Embedded is running inside an OSGi or Eclipse environment it is going to get an OSGi or Eclipse style URL and will not grok it.

                  What I was saying was, maybe we can write a default VFS context handler. If the URL ended in "/' then we can't do anything as the URL API does not support scanning, but if the URL did not end in "/" we could assume the file was a JAR file and use a JAR handler.

                    • Actions