glassfish
  1. glassfish
  2. GLASSFISH-18138

Error duing deployment of OSGi archive using reference: protocol on Equinox platform when the url refers to a directory

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.1.1
    • Fix Version/s: future release
    • Component/s: OSGi-JavaEE
    • Labels:
      None

      Description

      osgi-javaee-base/src/main/java/org/glassfish/osgijavaeebase/OSGiBundleArchive.java incorrectly assumes that reference: protocol always refers to files. While that's true for Felix, Equinox allows directories to be installed via reference: protocol.

        Activity

        Hide
        Sanjeeb Sahoo added a comment -

        It is not clear what is the issue here, because Felix also allows directories to be installed via reference protocol. See more information in this discussion [1]. In fact, when we do "asadmin deploy --type osgi foo.jar", deployment backend first explodes it in a location like domain_dir/applications/foo/ and the installs the bundle with a location as
        reference:file:domain_dir/applications/foo/. Felix does not copy the content into cache unless there are embedded jars in the directory, but it never copies or explodes the top level content.

        Looking at the code, I see that OSGiBundleArchive.getInputStream() is really assuming "uri" is pointing to a jar file and hence returning uri.toURL.openStream(). OSGiBundleArchive.getInputStream() is only called from WAB.init() if the WAB has "." in Bundle-ClassPath. Since that's not generally the case, we have not seen this issue that often. I guess we should fix this by checking like this:

        File jarFile = new File(uri);
        if(jarFile.isFile()){
            return new JarInputStream(new FileInputStream(jarFile));
        }
        

        [1] http://mail-archives.apache.org/mod_mbox/felix-dev/200906.mbox/<487a994c0906070909hda60df1ua595e0887ca066d4@mail.gmail.com>

        Show
        Sanjeeb Sahoo added a comment - It is not clear what is the issue here, because Felix also allows directories to be installed via reference protocol. See more information in this discussion [1] . In fact, when we do "asadmin deploy --type osgi foo.jar", deployment backend first explodes it in a location like domain_dir/applications/foo/ and the installs the bundle with a location as reference: file:domain_dir/applications/foo/ . Felix does not copy the content into cache unless there are embedded jars in the directory, but it never copies or explodes the top level content. Looking at the code, I see that OSGiBundleArchive.getInputStream() is really assuming "uri" is pointing to a jar file and hence returning uri.toURL.openStream(). OSGiBundleArchive.getInputStream() is only called from WAB.init() if the WAB has "." in Bundle-ClassPath. Since that's not generally the case, we have not seen this issue that often. I guess we should fix this by checking like this: File jarFile = new File(uri); if (jarFile.isFile()){ return new JarInputStream( new FileInputStream(jarFile)); } [1] http://mail-archives.apache.org/mod_mbox/felix-dev/200906.mbox/ <487a994c0906070909hda60df1ua595e0887ca066d4@mail.gmail.com>
        Hide
        TangYong added a comment -

        Hi sahoo,

        About the issue, let me remind a thing about deploy command. deploy command has a feature that can deploy base-directory app, for example:

        deploy --name hello /apps/MyApp

        OK, now, for such a directory, if its format meets osgi bundle format, why we can not support such a deployment?

        If you agree with me, I think that once supporting such a new feature(for example: deploy --type=osgi /bundles/MyBundle), the issue should have more sense. Of course, virtually, from a user's perspective, based directory osgi deployment is really not general.

        Show
        TangYong added a comment - Hi sahoo, About the issue, let me remind a thing about deploy command. deploy command has a feature that can deploy base-directory app, for example: deploy --name hello /apps/MyApp OK, now, for such a directory, if its format meets osgi bundle format, why we can not support such a deployment? If you agree with me, I think that once supporting such a new feature(for example: deploy --type=osgi /bundles/MyBundle), the issue should have more sense. Of course, virtually, from a user's perspective, based directory osgi deployment is really not general.

          People

          • Assignee:
            Sanjeeb Sahoo
            Reporter:
            Sanjeeb Sahoo
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: