[shrinkwrap-issues] [JBoss JIRA] (SHRINKDESC-153) XmlDomNodeImporterImpl should never rely on InputStream.available()

[Ralf Battenfeld (JIRA)]

    [ https://issues.jboss.org/browse/SHRINKDESC-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825339#comment-12825339 ] 

Ralf Battenfeld commented on SHRINKDESC-153:
--------------------------------------------

Hi Andrew, George

I analyzed the issue as described in the JIRA. Personally, I don't believe that this is really an issue. The current behavior is that in case of an empty stream an empty descriptor is returned. TO remote the available() call would break this concept and introduce big error handling on the user side.

The javadoc says:
... It is never correct to use the return value of this method to allocate a buffer intended to hold all data in this stream. ...

The point is that the implementation doesn't allocate buffer at all. Googling around indicates that a solution is to use the PushpackInputStream, which is a real implementation instead of the abstract inputstream.

I implemented a simple solution by using this concrete InputStream class. In my opinion, we have two options:
1. To leave at it is now. So far, I am not aware of issues regarding this.
2. To use the PushbackInputStream.

I sent a pull request.

Regards,
Ralf
                
> XmlDomNodeImporterImpl should never rely on InputStream.available()
> -------------------------------------------------------------------
>
>                 Key: SHRINKDESC-153
>                 URL: https://issues.jboss.org/browse/SHRINKDESC-153
>             Project: ShrinkWrap Descriptors
>          Issue Type: Bug
>          Components: spi
>            Reporter: George Gastaldi
>            Assignee: Ralf Battenfeld
>
> Some InputStream implementations return 0 in the available() method, however it is possible to read. This is described in the javadoc: 
> {quote}
> Returns an estimate of the number of bytes that can be read (or skipped over) from this input stream without blocking by the next invocation of a method for this input stream. The next invocation might 
>  be the same thread or another thread. A single read or skip of this many bytes will not block, but may read or skip fewer bytes. 
> Note that while some implementations of InputStream will return the total number of bytes in the stream, many will not. It is never correct to use the return value of this method to allocate a buffer 
>  intended to hold all data in this stream. 
> {quote}
> The problematic code lies in 
> https://github.com/shrinkwrap/descriptors/blob/master/spi/src/main/java/org/jboss/shrinkwrap/descriptor/spi/node/dom/XmlDomNodeImporterImpl.java#L58

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira