ShrinkWrap
  1. ShrinkWrap
  2. SHRINKWRAP-237

ShrinkWrap ClassLoader Caches the read Assets Inputstream

    Details

    • Type: Bug Bug
    • Status: Closed Closed (View Workflow)
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: 1.0.0-alpha-11
    • Fix Version/s: 1.0.0-alpha-12
    • Component/s: None
    • Labels:
      None
    • Environment:
      Weld 1.1.0.Beta1, Arqullian Alpha4, Seam XML Alpha3
    • Similar Issues:
      Show 10 results 

      Description

      http://pastebin.com/3neHZ6BL

      This can be reproduced using Weld 1.1.0.Beta1, Seam XML Alpha3 and Arqullian Alpha4- create a test that attempts to add a Manifest Resources from disk to Beans.xml.

      Seam XML will attempt to load the beans file and complain that the InputStream was closed.

      @RunWith(Arquillian.class)
      public class DefaultTimeZoneTest
      {
      @Deployment
      public static JavaArchive createTestArchive()

      { return ShrinkWrap.create(JavaArchive.class, "test.jar") .addClass(DefaultTimeZoneProducer.class) .addClass(DefaultTimeZoneConfig.class) .addManifestResource("org/jboss/seam/international/test/timezone/user-timezone.xml", ArchivePaths.create("beans.xml")); }

      @Inject
      DateTimeZone timeZone;

      @Test
      public void testDefaultTimeZoneProducerDirect()

      { Assert.assertNotNull(timeZone); }

      }

        Activity

        Hide
        Aslak Knutsen
        added a comment -

        http://github.com/shrinkwrap/shrinkwrap/blob/master/api/src/main/java/org/jboss/shrinkwrap/api/classloader/ShrinkWrapClassLoader.java#L135

        We cache the inputstream to keep track of it. opening the same file from the classloader multiple times result in EOF issues.. Don't cache the lookup, just add it to the 'openedStreams' list..

        Show
        Aslak Knutsen
        added a comment - http://github.com/shrinkwrap/shrinkwrap/blob/master/api/src/main/java/org/jboss/shrinkwrap/api/classloader/ShrinkWrapClassLoader.java#L135 We cache the inputstream to keep track of it. opening the same file from the classloader multiple times result in EOF issues.. Don't cache the lookup, just add it to the 'openedStreams' list..
        Hide
        Dan Allen
        added a comment - - edited

        Aslak, I'm not sure what you are getting at. Are you saying this is not an issue? I ran into the same problem testing the descriptors project. If I try to read in a descriptor two times in a row, even if I close the stream, the second time I get an EOF. We can't assume that developers will only ever read a resource once.

        I'll clarify my use case with an example. If I do this operation twice, the second time will fail.

        InputStream is = getResourceAsStream(name);

        if (is != null)
        {
        try

        { return Descriptors.importAs(descriptorType).from(is); }

        finally
        {
        try

        { is.close(); }

        catch (IOException e)

        { // Nothing we can do about this }

        }
        }

        Show
        Dan Allen
        added a comment - - edited Aslak, I'm not sure what you are getting at. Are you saying this is not an issue? I ran into the same problem testing the descriptors project. If I try to read in a descriptor two times in a row, even if I close the stream, the second time I get an EOF. We can't assume that developers will only ever read a resource once. I'll clarify my use case with an example. If I do this operation twice, the second time will fail. InputStream is = getResourceAsStream(name); if (is != null) { try { return Descriptors.importAs(descriptorType).from(is); } finally { try { is.close(); } catch (IOException e) { // Nothing we can do about this } } }
        Hide
        Aslak Knutsen
        added a comment -

        No I'm just stating where in the code the issues is and what needs to be done to fix it..

        I'm not sure what your getting at in your example tho, a InputStream is a one time operation, you can't reset it. So reading it twice will normally fail.

        I can counter your argument for Descriptors with; why are we closing resources we don't create/control. Give us a File or a String, we create the InputSream and we clean up. Give us a InputStream, your in charge of cleaning up. We don't know what type of inputstream etc we're getting, closing it might not be the desired behavior.

        Show
        Aslak Knutsen
        added a comment - No I'm just stating where in the code the issues is and what needs to be done to fix it.. I'm not sure what your getting at in your example tho, a InputStream is a one time operation, you can't reset it. So reading it twice will normally fail. I can counter your argument for Descriptors with; why are we closing resources we don't create/control. Give us a File or a String, we create the InputSream and we clean up. Give us a InputStream, your in charge of cleaning up. We don't know what type of inputstream etc we're getting, closing it might not be the desired behavior.
        Show
        Aslak Knutsen
        added a comment - http://github.com/shrinkwrap/shrinkwrap/pull/2
        Hide
        Andrew Rubinger
        added a comment -

        Pushed upstream.

        Show
        Andrew Rubinger
        added a comment - Pushed upstream.

          People

          • Assignee:
            Aslak Knutsen
            Reporter:
            Lincoln Baxter III
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: