October 2013 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKWRAP-468) Archive.move() on a directory does not move the files in that directory

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-468?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKWRAP-468: -------------------------------------------- Likely a "mv" on a dir should be recursive by definition; check that the API docs will support this change without breaking back-compat. > Archive.move() on a directory does not move the files in that directory > ----------------------------------------------------------------------- > > Key: SHRINKWRAP-468 > URL: https://issues.jboss.org/browse/SHRINKWRAP-468 > Project: ShrinkWrap > Issue Type: Bug > Affects Versions: 1.2.0 > Reporter: Kelsey Francis > Assignee: Michal Matloka > > Archive.move() only creates the target as a directory with the same name as source; it does not move the child nodes of source under target. -- 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

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-468) Archive.move() on a directory does not move the files in that directory

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-468?page=com.atlassian.jira.pl... ] Andrew Rubinger updated SHRINKWRAP-468: --------------------------------------- Assignee: Michal Matloka > Archive.move() on a directory does not move the files in that directory > ----------------------------------------------------------------------- > > Key: SHRINKWRAP-468 > URL: https://issues.jboss.org/browse/SHRINKWRAP-468 > Project: ShrinkWrap > Issue Type: Bug > Affects Versions: 1.2.0 > Reporter: Kelsey Francis > Assignee: Michal Matloka > > Archive.move() only creates the target as a directory with the same name as source; it does not move the child nodes of source under target. -- 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

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-468) Archive.move() on a directory does not move the files in that directory

by Kelsey Francis (JIRA)

Kelsey Francis created SHRINKWRAP-468: ----------------------------------------- Summary: Archive.move() on a directory does not move the files in that directory Key: SHRINKWRAP-468 URL: https://issues.jboss.org/browse/SHRINKWRAP-468 Project: ShrinkWrap Issue Type: Bug Affects Versions: 1.2.0 Reporter: Kelsey Francis Archive.move() only creates the target as a directory with the same name as source; it does not move the child nodes of source under target. -- 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

1
0
0 / 0

[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: -------------------------------------------- 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/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

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-467) ShrinkWrapFileSystemProvider NPE

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-467?page=com.atlassian.jira.pl... ] Andrew Rubinger resolved SHRINKWRAP-467. ---------------------------------------- Resolution: Done Upstream: 2cc8663255e87909064e427822b6b55f1d18c386 > ShrinkWrapFileSystemProvider NPE > -------------------------------- > > Key: SHRINKWRAP-467 > URL: https://issues.jboss.org/browse/SHRINKWRAP-467 > Project: ShrinkWrap > Issue Type: Bug > Affects Versions: 1.2.0 > Reporter: Andrew Rubinger > Assignee: Andrew Rubinger > Fix For: 1.2.1 > > > Using the following nio2 call: > {code}FileSystems.newFileSystem(ShrinkWrapFileSystems.getRootUri(archive), new HashMap());{code} > ...An NPE appears instead of an IllegalArgumentException because the Map was not containing the Archive object. > Submitted via: https://github.com/ALRubinger/shrinkwrap/issues/3 -- 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

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-467) ShrinkWrapFileSystemProvider NPE

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-467?page=com.atlassian.jira.pl... ] Andrew Rubinger updated SHRINKWRAP-467: --------------------------------------- Summary: ShrinkWrapFileSystemProvider NPE (was: Using the following nio2 call: FileSystems.newFileSystem(ShrinkWrapFileSystems.getRootUri(archive), new HashMap()); An NPE appears instead of an IllegalArgumentException because the Map was not containing the Archive object.) > ShrinkWrapFileSystemProvider NPE > -------------------------------- > > Key: SHRINKWRAP-467 > URL: https://issues.jboss.org/browse/SHRINKWRAP-467 > Project: ShrinkWrap > Issue Type: Bug > Affects Versions: 1.2.0 > Reporter: Andrew Rubinger > Assignee: Andrew Rubinger > Fix For: 1.2.1 > > > Using the following nio2 call: > {code}FileSystems.newFileSystem(ShrinkWrapFileSystems.getRootUri(archive), new HashMap());{code} > ...An NPE appears instead of an IllegalArgumentException because the Map was not containing the Archive object. > Submitted via: https://github.com/ALRubinger/shrinkwrap/issues/3 -- 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

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-467) Using the following nio2 call: FileSystems.newFileSystem(ShrinkWrapFileSystems.getRootUri(archive), new HashMap()); An NPE appears instead of an IllegalArgumentException because the Map was not containing the Archive object.

by Andrew Rubinger (JIRA)

Andrew Rubinger created SHRINKWRAP-467: ------------------------------------------ Summary: Using the following nio2 call: FileSystems.newFileSystem(ShrinkWrapFileSystems.getRootUri(archive), new HashMap()); An NPE appears instead of an IllegalArgumentException because the Map was not containing the Archive object. Key: SHRINKWRAP-467 URL: https://issues.jboss.org/browse/SHRINKWRAP-467 Project: ShrinkWrap Issue Type: Bug Affects Versions: 1.2.0 Reporter: Andrew Rubinger Assignee: Andrew Rubinger Fix For: 1.2.1 Using the following nio2 call: {code}FileSystems.newFileSystem(ShrinkWrapFileSystems.getRootUri(archive), new HashMap());{code} ...An NPE appears instead of an IllegalArgumentException because the Map was not containing the Archive object. Submitted via: https://github.com/ALRubinger/shrinkwrap/issues/3 -- 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

1
0
0 / 0

[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 edited comment on SHRINKDESC-153 at 10/23/13 2:02 PM: ---------------------------------------------------------------------- Ralf, I believe the best solution is to remove the if statement and the consumer of the InputStream should handle this. was (Author: gastaldi): Ralf, A SocketInputStream may not return the available() bytes. The best solution is to remove the if statement. Let the consumer of the InputStream handle this > 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

1
0
0 / 0

[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: -------------------------------------------- Ralf, A SocketInputStream may not return the available() bytes. The best solution is to remove the if statement. Let the consumer of the InputStream handle this > 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

1
0
0 / 0

[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: -------------------------------------------- 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

10 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues October 2013