glassfish
  1. glassfish
  2. GLASSFISH-16651

Allow wrapping of non-OSGi bundles when --type=osgi option is used in deploy command or GUI.

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 4.0_b58
    • Component/s: OSGi
    • Labels:
      None

      Description

      Since we support of wrapping of WARs with webbundle: URL scheme, we should explore the option of using it to wrap plain vanilla WARs when such WARs are deployed using --type=osgi property. This will allow OSGi Web Container to be available to a wider audience.

        Activity

        Hide
        Sanjeeb Sahoo added a comment -

        Tang Yong is contributing on this issue and has made something available at https://github.com/tangyong/GLASSFISH-16651 for us to use.

        Show
        Sanjeeb Sahoo added a comment - Tang Yong is contributing on this issue and has made something available at https://github.com/tangyong/GLASSFISH-16651 for us to use.
        Hide
        TangYong added a comment -

        Sahoo Said:

        I have looked at your changes. The proposed changes assume that when an archive is wrapped,
        only its MANIFEST.MF get modified, but that need not be the case. So, I suggest you do the following:

        // Construct a new URL with information provided in deploy command
        ...
        URL url = new URL(sb.toString());

        JarInputStream jis = new JarInputStream(url.openStream());
        JarEntry je;
        while ( (je = jis.getNextEntry()) != null)

        { // add an entry in target and copy to target }

        Show
        TangYong added a comment - Sahoo Said: I have looked at your changes. The proposed changes assume that when an archive is wrapped, only its MANIFEST.MF get modified, but that need not be the case. So, I suggest you do the following: // Construct a new URL with information provided in deploy command ... URL url = new URL(sb.toString()); JarInputStream jis = new JarInputStream(url.openStream()); JarEntry je; while ( (je = jis.getNextEntry()) != null) { // add an entry in target and copy to target }
        Hide
        TangYong added a comment -

        Now, the new source has been finished[1] and almost passed my test[2]. On the updated version, I fixed the following:

        1 Refactoring previous souce in order to make source more readable and also considering sahoo's comment.

        2 Fixing a problem of getting WAB QueryString

        [1] https://github.com/tangyong/GLASSFISH-16651/blob/master/osgi-container/OSGiArchiveHandler.java
        [2] https://github.com/tangyong/GLASSFISH-16651/tree/master/testsample

        The mean of what I said "almost passed" is that after I deployed a wab using "asadmin deploy --type=osgi --properties uriScheme=webbundle:Web-ContextPath=/test_sample1 e:\test_sample1.war", although it seemed no problem and can be also accessed normally, I found that on server.log, the following error message appeared,

        [#|2012-08-22T22:31:41.453+0900|SEVERE|44.0|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=23;_ThreadName=Thread-16;|java.lang.RuntimeException: java.io.IOException: Pipe closed
        at org.glassfish.osgiweb.WebBundleURLStreamHandlerService$2.visit(WebBundleURLStreamHandlerService.java:226)
        at org.glassfish.osgijavaeebase.JarHelper.accept(JarHelper.java:74)
        at org.glassfish.osgiweb.WebBundleURLStreamHandlerService.writeWithoutSignedFiles(WebBundleURLStreamHandlerService.java:207)
        at org.glassfish.osgiweb.WebBundleURLStreamHandlerService.writeWithoutSignedFiles(WebBundleURLStreamHandlerService.java:196)
        at org.glassfish.osgiweb.WebBundleURLStreamHandlerService.access$100(WebBundleURLStreamHandlerService.java:90)
        at org.glassfish.osgiweb.WebBundleURLStreamHandlerService$1$1.run(WebBundleURLStreamHandlerService.java:128)
        Caused by: java.io.IOException: Pipe closed
        at java.io.PipedInputStream.checkStateForReceive(PipedInputStream.java:244)
        at java.io.PipedInputStream.receive(PipedInputStream.java:185)
        at java.io.PipedOutputStream.write(PipedOutputStream.java:105)
        at java.util.zip.ZipOutputStream.writeInt(ZipOutputStream.java:445)
        at java.util.zip.ZipOutputStream.writeEXT(ZipOutputStream.java:362)
        at java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:220)
        at org.glassfish.osgiweb.WebBundleURLStreamHandlerService$2.visit(WebBundleURLStreamHandlerService.java:224)
        ... 5 more

        #]

        So, I will investigate the problem and fix it.

        Show
        TangYong added a comment - Now, the new source has been finished [1] and almost passed my test [2] . On the updated version, I fixed the following: 1 Refactoring previous souce in order to make source more readable and also considering sahoo's comment. 2 Fixing a problem of getting WAB QueryString [1] https://github.com/tangyong/GLASSFISH-16651/blob/master/osgi-container/OSGiArchiveHandler.java [2] https://github.com/tangyong/GLASSFISH-16651/tree/master/testsample The mean of what I said "almost passed" is that after I deployed a wab using "asadmin deploy --type=osgi --properties uriScheme=webbundle:Web-ContextPath=/test_sample1 e:\test_sample1.war", although it seemed no problem and can be also accessed normally, I found that on server.log, the following error message appeared, [#|2012-08-22T22:31:41.453+0900|SEVERE|44.0|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=23;_ThreadName=Thread-16;|java.lang.RuntimeException: java.io.IOException: Pipe closed at org.glassfish.osgiweb.WebBundleURLStreamHandlerService$2.visit(WebBundleURLStreamHandlerService.java:226) at org.glassfish.osgijavaeebase.JarHelper.accept(JarHelper.java:74) at org.glassfish.osgiweb.WebBundleURLStreamHandlerService.writeWithoutSignedFiles(WebBundleURLStreamHandlerService.java:207) at org.glassfish.osgiweb.WebBundleURLStreamHandlerService.writeWithoutSignedFiles(WebBundleURLStreamHandlerService.java:196) at org.glassfish.osgiweb.WebBundleURLStreamHandlerService.access$100(WebBundleURLStreamHandlerService.java:90) at org.glassfish.osgiweb.WebBundleURLStreamHandlerService$1$1.run(WebBundleURLStreamHandlerService.java:128) Caused by: java.io.IOException: Pipe closed at java.io.PipedInputStream.checkStateForReceive(PipedInputStream.java:244) at java.io.PipedInputStream.receive(PipedInputStream.java:185) at java.io.PipedOutputStream.write(PipedOutputStream.java:105) at java.util.zip.ZipOutputStream.writeInt(ZipOutputStream.java:445) at java.util.zip.ZipOutputStream.writeEXT(ZipOutputStream.java:362) at java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:220) at org.glassfish.osgiweb.WebBundleURLStreamHandlerService$2.visit(WebBundleURLStreamHandlerService.java:224) ... 5 more #] So, I will investigate the problem and fix it.
        Hide
        TangYong added a comment -

        >I found that on server.log, the following error message appeared,
        >...

        In current my implementation, I wrapped the "url.openStream()" into new JarInputStream[1], and after handling wab expanding logics, I closed the JarInputStream[2]. As a result, the above exception happened on writeWithoutSignedFiles method line 224 of WebBundleURLStreamHandlerService class[3].
        [1] JarInputStream jis = new JarInputStream(url.openStream());
        [2] jis.close()
        [3]
        ...
        jos.closeEntry();
        } catch (IOException e)

        { throw new RuntimeException(e); // TODO(Sahoo): Proper Exception Handling }

        ...

        Then, I made a confirmation by using "install webbundle:file:/e:/test_sample1.war?Web-ContextPath=/test_sample1" on gf felix shell in order to see whether the exception still happened on the server.log or not. The result is that the exception has not appeared on the server.log. So, I will see felix's using way to confirm whether my using way has problem or not.

        Show
        TangYong added a comment - >I found that on server.log, the following error message appeared, >... In current my implementation, I wrapped the "url.openStream()" into new JarInputStream [1] , and after handling wab expanding logics, I closed the JarInputStream [2] . As a result, the above exception happened on writeWithoutSignedFiles method line 224 of WebBundleURLStreamHandlerService class [3] . [1] JarInputStream jis = new JarInputStream(url.openStream()); [2] jis.close() [3] ... jos.closeEntry(); } catch (IOException e) { throw new RuntimeException(e); // TODO(Sahoo): Proper Exception Handling } ... Then, I made a confirmation by using "install webbundle: file:/e:/test_sample1.war?Web-ContextPath=/test_sample1 " on gf felix shell in order to see whether the exception still happened on the server.log or not. The result is that the exception has not appeared on the server.log. So, I will see felix's using way to confirm whether my using way has problem or not.
        Hide
        TangYong added a comment -

        Now, I have confirmed that on OSGiArchiveHandler.expand method, if using the following way[1], then the exception of "Pipe closed" will happen. However, in order to handle the jar entry, I wish to use JarInputStream.

        [1] JarInputStream jis = new JarInputStream(conn.getInputStream());

        On the other hand, if getting InputStream directly using "conn.getInputStream()" and not wrapping into JarInputStream,
        then the exception will not happen.

        So, maybe I have triggered a case for the following code block[2] and wish sahoo can see whether WebBundleURLStreamHandlerService class has some problem or not.
        [2]
        ...
        jos.closeEntry();
        } catch (IOException e)

        { throw new RuntimeException(e); // TODO(Sahoo): Proper Exception Handling }
        Show
        TangYong added a comment - Now, I have confirmed that on OSGiArchiveHandler.expand method, if using the following way [1] , then the exception of "Pipe closed" will happen. However, in order to handle the jar entry, I wish to use JarInputStream. [1] JarInputStream jis = new JarInputStream(conn.getInputStream()); On the other hand, if getting InputStream directly using "conn.getInputStream()" and not wrapping into JarInputStream, then the exception will not happen. So, maybe I have triggered a case for the following code block [2] and wish sahoo can see whether WebBundleURLStreamHandlerService class has some problem or not. [2] ... jos.closeEntry(); } catch (IOException e) { throw new RuntimeException(e); // TODO(Sahoo): Proper Exception Handling }
        Hide
        TangYong added a comment -

        Now, the exception problem has been fixed by getting inputStream directly and constructing a new JarInputStream wrapping ByteArrayInputStream. And the implementation has passed my test and on the server.log, the exception has been
        not happened. Please see[1],

        [1] https://github.com/tangyong/GLASSFISH-16651/blob/master/osgi-container/OSGiArchiveHandler.java

        Show
        TangYong added a comment - Now, the exception problem has been fixed by getting inputStream directly and constructing a new JarInputStream wrapping ByteArrayInputStream. And the implementation has passed my test and on the server.log, the exception has been not happened. Please see [1] , [1] https://github.com/tangyong/GLASSFISH-16651/blob/master/osgi-container/OSGiArchiveHandler.java
        Hide
        TangYong added a comment -

        Hi Sahoo,

        The attachments are modified source and created patch file using svn.

        The attachments have been formated according to unix env.

        In addition, modified source is based on 09/24 gf trunk source and I deleted some unused import statements as following:

        import org.glassfish.internal.api.DelegatingClassLoader;
        import org.glassfish.hk2.api.PreDestroy;
        import java.lang.ref.WeakReference;
        import com.sun.enterprise.module.ModulesRegistry;
        import com.sun.enterprise.module.Module;
        import com.sun.enterprise.module.ModuleDefinition;
        import com.sun.enterprise.module.common_impl.DefaultModuleDefinition;
        import com.sun.enterprise.util.io.FileUtils;
        import java.io.File;
        import java.net.URI;

        Please confirm the above.

        Thanks!

        Show
        TangYong added a comment - Hi Sahoo, The attachments are modified source and created patch file using svn. The attachments have been formated according to unix env. In addition, modified source is based on 09/24 gf trunk source and I deleted some unused import statements as following: import org.glassfish.internal.api.DelegatingClassLoader; import org.glassfish.hk2.api.PreDestroy; import java.lang.ref.WeakReference; import com.sun.enterprise.module.ModulesRegistry; import com.sun.enterprise.module.Module; import com.sun.enterprise.module.ModuleDefinition; import com.sun.enterprise.module.common_impl.DefaultModuleDefinition; import com.sun.enterprise.util.io.FileUtils; import java.io.File; import java.net.URI; Please confirm the above. Thanks!
        Hide
        Sanjeeb Sahoo added a comment -

        Thanks, Tang. I committed a slightly modified version of the patch to trunk in svn rev #56251. Could you please work with deployment team (Hong Zhang) to add a dev test in their test suite. They already have tests for osgi-container, so it is natural to add the new test there. We should test the following use case to test URL encoding/decoding as well:

        Use case:
        asadmin deploy --type osgi \
        --properties "UriScheme=webBundle:Bundle-SymbolicName=bar:\
        Import-Package=javax.servlet;javax.servlet.http;%20version\\=3.0;resolution\\:\\=mandatory:\Web-ContextPath=/foo" \
        /tmp/test_sample1.war

        See the use of "
        " in above command.

        Show
        Sanjeeb Sahoo added a comment - Thanks, Tang. I committed a slightly modified version of the patch to trunk in svn rev #56251. Could you please work with deployment team (Hong Zhang) to add a dev test in their test suite. They already have tests for osgi-container, so it is natural to add the new test there. We should test the following use case to test URL encoding/decoding as well: Use case: asadmin deploy --type osgi \ --properties "UriScheme=webBundle:Bundle-SymbolicName=bar:\ Import-Package=javax.servlet;javax.servlet.http;%20version\\=3.0;resolution\\:\\=mandatory:\Web-ContextPath=/foo" \ /tmp/test_sample1.war See the use of " " in above command.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: