[
https://issues.jboss.org/browse/SHRINKDESC-153?page=com.atlassian.jira.pl...
]
Ralf Battenfeld commented on SHRINKDESC-153:
--------------------------------------------
I worked a little bit on this. I don't know really which concrete InputStream
inplementation could potentially causing a problem.
The solution I found was to use the PushbackInputStream as concrete and deterministic
implementation of an InputStream. So, the available() call will be executed on the
internally created PushbackInputStream instead from the passed InputStream object.
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/o...
--
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