November 2013 - shrinkwrap-issues

[JBoss JIRA] (SHRINKWRAP-469) ShrinkWrapDirectoryStream.iterator missing IllegalStateException cases

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-469?page=com.atlassian.jira.pl... ] Michal Matloka updated SHRINKWRAP-469: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/shrinkwrap/shrinkwrap/pull/82 > ShrinkWrapDirectoryStream.iterator missing IllegalStateException cases > ---------------------------------------------------------------------- > > Key: SHRINKWRAP-469 > URL: https://issues.jboss.org/browse/SHRINKWRAP-469 > Project: ShrinkWrap > Issue Type: Bug > Reporter: Under Flowerpot > Assignee: Michal Matloka > Priority: Minor > > Unfortunately the nio2 API was designed before Java8's stream library. > The documentation says that ShrinkWrapDirectoryStream.iterator must throw IllegalStateException if the Stream is closed OR if the iterator() has been accessed already. > From my reading of the DirectoryStream javadoc, the implementation of Iterator is otherwise fine. close() does not have to prematurely terminate the Iterator. iterator() should just comply with the precondition exceptions. > ShrinkWrapDirectoryStream is package protected, there is no reason to discuss any relationship to SecureDirectoryStream. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-469) ShrinkWrapDirectoryStream.iterator missing IllegalStateException cases

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-469?page=com.atlassian.jira.pl... ] Michal Matloka reassigned SHRINKWRAP-469: ----------------------------------------- Assignee: Michal Matloka > ShrinkWrapDirectoryStream.iterator missing IllegalStateException cases > ---------------------------------------------------------------------- > > Key: SHRINKWRAP-469 > URL: https://issues.jboss.org/browse/SHRINKWRAP-469 > Project: ShrinkWrap > Issue Type: Bug > Reporter: Under Flowerpot > Assignee: Michal Matloka > Priority: Minor > > Unfortunately the nio2 API was designed before Java8's stream library. > The documentation says that ShrinkWrapDirectoryStream.iterator must throw IllegalStateException if the Stream is closed OR if the iterator() has been accessed already. > From my reading of the DirectoryStream javadoc, the implementation of Iterator is otherwise fine. close() does not have to prematurely terminate the Iterator. iterator() should just comply with the precondition exceptions. > ShrinkWrapDirectoryStream is package protected, there is no reason to discuss any relationship to SecureDirectoryStream. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-470) SeekableInMemoryByteChannel.truncate misimplements the contract

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-470?page=com.atlassian.jira.pl... ] Michal Matloka reassigned SHRINKWRAP-470: ----------------------------------------- Assignee: Michal Matloka > SeekableInMemoryByteChannel.truncate misimplements the contract > --------------------------------------------------------------- > > Key: SHRINKWRAP-470 > URL: https://issues.jboss.org/browse/SHRINKWRAP-470 > Project: ShrinkWrap > Issue Type: Bug > Reporter: Under Flowerpot > Assignee: Michal Matloka > > At the tail end of truncate, is this logic: > {code} > // If we've been given a size greater than we are > if (newSize > currentSize) { > // Reset the position only > this.position = newSize; > } > {code} > which is not what the API says: "If the given size is less than the current size then the entity is truncated, discarding any bytes beyond the new end. If the given size is greater than or equal to the current size then the entity is not modified." > I think you wanted this instead, which should be inside the above array truncation: > {code} > // If we've been given a size less than we are > if (newSize < currentSize) { > // Reset the size only > this.size = newSize; > } > {code} -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-470) SeekableInMemoryByteChannel.truncate misimplements the contract

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-470?page=com.atlassian.jira.pl... ] Michal Matloka updated SHRINKWRAP-470: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/shrinkwrap/shrinkwrap/pull/81 > SeekableInMemoryByteChannel.truncate misimplements the contract > --------------------------------------------------------------- > > Key: SHRINKWRAP-470 > URL: https://issues.jboss.org/browse/SHRINKWRAP-470 > Project: ShrinkWrap > Issue Type: Bug > Reporter: Under Flowerpot > Assignee: Michal Matloka > > At the tail end of truncate, is this logic: > {code} > // If we've been given a size greater than we are > if (newSize > currentSize) { > // Reset the position only > this.position = newSize; > } > {code} > which is not what the API says: "If the given size is less than the current size then the entity is truncated, discarding any bytes beyond the new end. If the given size is greater than or equal to the current size then the entity is not modified." > I think you wanted this instead, which should be inside the above array truncation: > {code} > // If we've been given a size less than we are > if (newSize < currentSize) { > // Reset the size only > this.size = newSize; > } > {code} -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-470) SeekableInMemoryByteChannel.truncate misimplements the contract

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-470?page=com.atlassian.jira.pl... ] Michal Matloka edited comment on SHRINKWRAP-470 at 11/29/13 6:35 PM: --------------------------------------------------------------------- Hey, So API says: {quote} 1. If the given size is less than the current size then the entity is truncated, discarding any bytes beyond the new end. 2. If the given size is greater than or equal to the current size then the entity is not modified. 3. In either case, if the current position is greater than the given size then it is set to that size. {quote} 1. is covered by https://github.com/shrinkwrap/shrinkwrap/blob/master/api-nio2/src/main/ja... 2. should be covered here https://github.com/shrinkwrap/shrinkwrap/blob/master/api-nio2/src/main/ja... but it should have form "do nothing", improved in PR to 'empty' block 3. is covered https://github.com/shrinkwrap/shrinkwrap/blob/master/api-nio2/src/main/ja... [~alrubinger] please verify :) was (Author: mmatloka): Hey, So API says: {quote} 1. If the given size is less than the current size then the entity is truncated, discarding any bytes beyond the new end. 2. If the given size is greater than or equal to the current size then the entity is not modified. 3. In either case, if the current position is greater than the given size then it is set to that size. {quote} 1. is covered by https://github.com/shrinkwrap/shrinkwrap/blob/master/api-nio2/src/main/ja... 2. should be covered here https://github.com/shrinkwrap/shrinkwrap/blob/master/api-nio2/src/main/ja... but it should have form "do nothing", improved in PR to 'empty' block 3. is covered https://github.com/shrinkwrap/shrinkwrap/blob/master/api-nio2/src/main/ja... > SeekableInMemoryByteChannel.truncate misimplements the contract > --------------------------------------------------------------- > > Key: SHRINKWRAP-470 > URL: https://issues.jboss.org/browse/SHRINKWRAP-470 > Project: ShrinkWrap > Issue Type: Bug > Reporter: Under Flowerpot > Assignee: Michal Matloka > > At the tail end of truncate, is this logic: > {code} > // If we've been given a size greater than we are > if (newSize > currentSize) { > // Reset the position only > this.position = newSize; > } > {code} > which is not what the API says: "If the given size is less than the current size then the entity is truncated, discarding any bytes beyond the new end. If the given size is greater than or equal to the current size then the entity is not modified." > I think you wanted this instead, which should be inside the above array truncation: > {code} > // If we've been given a size less than we are > if (newSize < currentSize) { > // Reset the size only > this.size = newSize; > } > {code} -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-470) SeekableInMemoryByteChannel.truncate misimplements the contract

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-470?page=com.atlassian.jira.pl... ] Michal Matloka commented on SHRINKWRAP-470: ------------------------------------------- Hey, So API says: {quote} 1. If the given size is less than the current size then the entity is truncated, discarding any bytes beyond the new end. 2. If the given size is greater than or equal to the current size then the entity is not modified. 3. In either case, if the current position is greater than the given size then it is set to that size. {quote} 1. is covered by https://github.com/shrinkwrap/shrinkwrap/blob/master/api-nio2/src/main/ja... 2. should be covered here https://github.com/shrinkwrap/shrinkwrap/blob/master/api-nio2/src/main/ja... but it should have form "do nothing", improved in PR to 'empty' block 3. is covered https://github.com/shrinkwrap/shrinkwrap/blob/master/api-nio2/src/main/ja... > SeekableInMemoryByteChannel.truncate misimplements the contract > --------------------------------------------------------------- > > Key: SHRINKWRAP-470 > URL: https://issues.jboss.org/browse/SHRINKWRAP-470 > Project: ShrinkWrap > Issue Type: Bug > Reporter: Under Flowerpot > > At the tail end of truncate, is this logic: > {code} > // If we've been given a size greater than we are > if (newSize > currentSize) { > // Reset the position only > this.position = newSize; > } > {code} > which is not what the API says: "If the given size is less than the current size then the entity is truncated, discarding any bytes beyond the new end. If the given size is greater than or equal to the current size then the entity is not modified." > I think you wanted this instead, which should be inside the above array truncation: > {code} > // If we've been given a size less than we are > if (newSize < currentSize) { > // Reset the size only > this.size = newSize; > } > {code} -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-5) Make it easier to add a maven repository with the maven resolvers

by Rafael Benevides (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-5?page=com.atlassian.jira.plugi... ] Rafael Benevides edited comment on SHRINKRES-5 at 11/28/13 10:57 AM: --------------------------------------------------------------------- I also would like to see this feature on SHR. It will easy to read some metadatas and try to resolver only in specific repositories. Example: test EAP dependencies resolution. was (Author: rafabene): I also would like to see this feature on SHR > Make it easier to add a maven repository with the maven resolvers > ----------------------------------------------------------------- > > Key: SHRINKRES-5 > URL: https://issues.jboss.org/browse/SHRINKRES-5 > Project: ShrinkWrap Resolvers > Issue Type: Enhancement > Reporter: Jason Porter > Priority: Minor > Labels: api-change > > It should be easier to add a repository than creating a full settings.xml. Perhaps something like addRepository(String), or addRepositories(String...) -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-5) Make it easier to add a maven repository with the maven resolvers

by Rafael Benevides (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-5?page=com.atlassian.jira.plugi... ] Rafael Benevides commented on SHRINKRES-5: ------------------------------------------ I also would like to see this feature on SHR > Make it easier to add a maven repository with the maven resolvers > ----------------------------------------------------------------- > > Key: SHRINKRES-5 > URL: https://issues.jboss.org/browse/SHRINKRES-5 > Project: ShrinkWrap Resolvers > Issue Type: Enhancement > Reporter: Jason Porter > Priority: Minor > Labels: api-change > > It should be easier to add a repository than creating a full settings.xml. Perhaps something like addRepository(String), or addRepositories(String...) -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-151) Descriptors should generate a common parent for different spec versions

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-151?page=com.atlassian.jira.pl... ] George Gastaldi commented on SHRINKDESC-151: -------------------------------------------- Right, then it should not be generated in the top level type, as it should contain only what's common between all spec versions > Descriptors should generate a common parent for different spec versions > ----------------------------------------------------------------------- > > Key: SHRINKDESC-151 > URL: https://issues.jboss.org/browse/SHRINKDESC-151 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Components: api-javaee > Reporter: George Gastaldi > Assignee: Ralf Battenfeld > > This affects only the JavaEE API. Some usecases manipulate descriptors regardless of the version it is currently on. The API could be abstracted to a common interface so that common element types to the supported complex types could be used. > A sample is provided in https://github.com/forge/javaee-descriptors/. The IMPL remains untouched (as generated by the ShrinkWrap generator) and common types are refactored to a super interface: > Super Interface: https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > Sub Interfaces: > https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > The generated code doesn't need to change either. The existence of the super interface is what matters most. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-151) Descriptors should generate a common parent for different spec versions

by Ralf Battenfeld (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-151?page=com.atlassian.jira.pl... ] Ralf Battenfeld commented on SHRINKDESC-151: -------------------------------------------- I am working on this. It is not an trivial task and needs some time. There will be things which are unknown to me and have to be address when it comes up. I mean when a version introduces for example a new top level type which do not exist in the older versions. I will see ... > Descriptors should generate a common parent for different spec versions > ----------------------------------------------------------------------- > > Key: SHRINKDESC-151 > URL: https://issues.jboss.org/browse/SHRINKDESC-151 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Components: api-javaee > Reporter: George Gastaldi > Assignee: Ralf Battenfeld > > This affects only the JavaEE API. Some usecases manipulate descriptors regardless of the version it is currently on. The API could be abstracted to a common interface so that common element types to the supported complex types could be used. > A sample is provided in https://github.com/forge/javaee-descriptors/. The IMPL remains untouched (as generated by the ShrinkWrap generator) and common types are refactored to a super interface: > Super Interface: https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > Sub Interfaces: > https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > The generated code doesn't need to change either. The existence of the super interface is what matters most. -- 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, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues November 2013