[JBoss JIRA] (SHRINKDESC-153) XmlDomNodeImporterImpl should never rely on InputStream.available()
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/SHRINKDESC-153?page=com.atlassian.jira.pl... ]
George Gastaldi commented on SHRINKDESC-153:
--------------------------------------------
Thanks for taking this. It's important to detect other places where this same approach is used and remove them whenever possible.
> 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
10 years, 6 months
[JBoss JIRA] (SHRINKDESC-153) XmlDomNodeImporterImpl should never rely on InputStream.available()
by Ralf Battenfeld (JIRA)
[ https://issues.jboss.org/browse/SHRINKDESC-153?page=com.atlassian.jira.pl... ]
Ralf Battenfeld reassigned SHRINKDESC-153:
------------------------------------------
Assignee: Ralf Battenfeld
> 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
10 years, 6 months
[JBoss JIRA] (SHRINKDESC-153) XmlDomNodeImporterImpl should never rely on InputStream.available()
by Ralf Battenfeld (JIRA)
[ https://issues.jboss.org/browse/SHRINKDESC-153?page=com.atlassian.jira.pl... ]
Ralf Battenfeld commented on SHRINKDESC-153:
--------------------------------------------
Fine to me, I will work on this JIRA.
> 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
>
> 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
10 years, 6 months
[JBoss JIRA] (SHRINKDESC-153) XmlDomNodeImporterImpl should never rely on InputStream.available()
by Andrew Rubinger (JIRA)
[ https://issues.jboss.org/browse/SHRINKDESC-153?page=com.atlassian.jira.pl... ]
Andrew Rubinger commented on SHRINKDESC-153:
--------------------------------------------
Anyone care to provide a PR? Perhaps [~rbattenfeld]?
> 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
>
> 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
10 years, 6 months
[JBoss JIRA] (SHRINKDESC-153) XmlDomNodeImporterImpl should never rely on InputStream.available()
by George Gastaldi (JIRA)
George Gastaldi created SHRINKDESC-153:
------------------------------------------
Summary: 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
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
10 years, 6 months
[JBoss JIRA] (SHRINKRES-151) Add license file
by Andrew Rubinger (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-151?page=com.atlassian.jira.plu... ]
Andrew Rubinger commented on SHRINKRES-151:
-------------------------------------------
IANAL, but I believe 4a is stating that derivative works must give a copy of the license. Either way, I've supplied one in the root of the repo.
> Add license file
> ----------------
>
> Key: SHRINKRES-151
> URL: https://issues.jboss.org/browse/SHRINKRES-151
> Project: ShrinkWrap Resolvers
> Issue Type: Task
> Reporter: Marek Goldmann
> Assignee: Andrew Rubinger
> Fix For: 2.1.0
>
>
> The project is licensed under ASL 2.0. A license file needs to be shipped with the project, see para 4 a) of the license text:
> {quote}
> You must give any other recipients of the Work or Derivative Works a copy of this License; and
> {quote}
--
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
10 years, 6 months
[JBoss JIRA] (SHRINKRES-151) Add license file
by Marek Goldmann (JIRA)
Marek Goldmann created SHRINKRES-151:
----------------------------------------
Summary: Add license file
Key: SHRINKRES-151
URL: https://issues.jboss.org/browse/SHRINKRES-151
Project: ShrinkWrap Resolvers
Issue Type: Task
Reporter: Marek Goldmann
Assignee: Andrew Rubinger
The project is licensed under ASL 2.0. A license file needs to be shipped with the project, see para 4 a) of the license text:
{quote}
You must give any other recipients of the Work or Derivative Works a copy of this License; and
{quote}
--
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
10 years, 6 months
[JBoss JIRA] (SHRINKRES-140) Update Aether implementation to org.eclipse.aether one
by Marek Goldmann (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-140?page=com.atlassian.jira.plu... ]
Marek Goldmann commented on SHRINKRES-140:
------------------------------------------
I think I should be fine for now with this branch. I'll try to make it compile on Fedora today.
Currently there are no packages that require shrinkwrap-resolver in Fedora (WildFly tests are disabled ATM too). But I would like to avoid removing the package from Fedora and having it in a buildable state at least. This can be fixed later, after this issue will be resolved.
> Update Aether implementation to org.eclipse.aether one
> ------------------------------------------------------
>
> Key: SHRINKRES-140
> URL: https://issues.jboss.org/browse/SHRINKRES-140
> Project: ShrinkWrap Resolvers
> Issue Type: Component Upgrade
> Components: impl-maven
> Affects Versions: 2.0.0-beta-5
> Reporter: Karel Piwko
> Assignee: Michal Matloka
>
> Aether is now a part of org.eclipse foundation. We should update to newer version when they release first stable version.
> Update should not affect user at all, it should comprise of replacing imports with new ones.
--
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
10 years, 6 months