July 2013 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKWRAP-452) Eclipse java template contains year 2011

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-452?page=com.atlassian.jira.pl... ] Andrew Rubinger closed SHRINKWRAP-452. -------------------------------------- > Eclipse java template contains year 2011 > ---------------------------------------- > > Key: SHRINKWRAP-452 > URL: https://issues.jboss.org/browse/SHRINKWRAP-452 > Project: ShrinkWrap > Issue Type: Bug > Reporter: Michal Matloka > Assignee: Michal Matloka > Priority: Trivial > Fix For: 1.1.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, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-456) Incorrect Error Message if file for import does not exist

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-456?page=com.atlassian.jira.pl... ] Andrew Rubinger closed SHRINKWRAP-456. -------------------------------------- > Incorrect Error Message if file for import does not exist > --------------------------------------------------------- > > Key: SHRINKWRAP-456 > URL: https://issues.jboss.org/browse/SHRINKWRAP-456 > Project: ShrinkWrap > Issue Type: Feature Request > Components: api > Affects Versions: 1.1.2 > Reporter: Andrew Rubinger > Assignee: Andrew Rubinger > Priority: Minor > Fix For: 1.1.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, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-455) ConcurrentModificationException during delete on imported archive

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-455?page=com.atlassian.jira.pl... ] Andrew Rubinger closed SHRINKWRAP-455. -------------------------------------- > ConcurrentModificationException during delete on imported archive > ----------------------------------------------------------------- > > Key: SHRINKWRAP-455 > URL: https://issues.jboss.org/browse/SHRINKWRAP-455 > Project: ShrinkWrap > Issue Type: Bug > Reporter: Michal Matloka > Assignee: Michal Matloka > Fix For: 1.1.3 > > > Description from: https://community.jboss.org/message/808603#808603 > {noformat} > I'm trying to use Shrinkwrap to delete a folder in a JavaArchive (jar). My jar is quite simple, it contains only one folder named resources and this folder contains two files : > > myJavaArchive.jar: > /resources/ > /resources/bar.txt > /resources/foo.txt > > So I create a JavaArchive from my JAR file and I call delete method on "/resources" folder (see below) but it causes a ConcurrentModifictionException. > > My code : > > package com.test; > > import java.io.File; > > import org.jboss.shrinkwrap.api.ShrinkWrap; > import org.jboss.shrinkwrap.api.spec.JavaArchive; > > public class Main { > public static void main(String[] args) { > JavaArchive archive = ShrinkWrap.createFromZipFile(JavaArchive.class, > new File(Main.class.getResource("/myJavaArchive.jar").getFile())); > System.out.println(archive.toString(true)); > archive.delete("/resources"); > } > } > > > The stack trace : > > Exception in thread "main" java.util.ConcurrentModificationException > at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) > at java.util.HashMap$KeyIterator.next(HashMap.java:828) > at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1010) > at org.jboss.shrinkwrap.impl.base.MemoryMapArchiveBase.removeNodeRecursively(MemoryMapArchiveBase.java:309) > at org.jboss.shrinkwrap.impl.base.MemoryMapArchiveBase.delete(MemoryMapArchiveBase.java:291) > at org.jboss.shrinkwrap.impl.base.MemoryMapArchiveBase.delete(MemoryMapArchiveBase.java:325) > at org.jboss.shrinkwrap.impl.base.container.ContainerBase.delete(ContainerBase.java:393) > at com.test.Main.main(Main.java:13) > > {noformat} > I was able to reproduce this issue. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-451) NIO2 Implementation logic incorrect for determining directories

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-451?page=com.atlassian.jira.pl... ] Andrew Rubinger closed SHRINKWRAP-451. -------------------------------------- > NIO2 Implementation logic incorrect for determining directories > --------------------------------------------------------------- > > Key: SHRINKWRAP-451 > URL: https://issues.jboss.org/browse/SHRINKWRAP-451 > Project: ShrinkWrap > Issue Type: Bug > Affects Versions: 1.1.2 > Reporter: Andrew Rubinger > Assignee: Andrew Rubinger > Fix For: 1.1.3 > > > As reported by contributor Patrick Huy: > While trying to use shrinkwrap as an in memory file system for testing I noticed that Files.walkFileTreePath does not work at all as > {code}Path dirPath = fs.getPath("dir"); > Files.createDirectory(dirPath); > Assert.assertTrue("Created directory was not a directory", Files.isDirectory(dirPath));{code} > fails. Created directories are not correctly identified as such. Additionally the DirectoryStream implementation does not match what Java's implementation of walkFileTreePath expects (it returns all Files in the filesystem not just those beneath the specified path) -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-461) SeekableInMemoryByteChannel returns incorrect value for EOF

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-461?page=com.atlassian.jira.pl... ] Andrew Rubinger closed SHRINKWRAP-461. -------------------------------------- > SeekableInMemoryByteChannel returns incorrect value for EOF > ----------------------------------------------------------- > > Key: SHRINKWRAP-461 > URL: https://issues.jboss.org/browse/SHRINKWRAP-461 > Project: ShrinkWrap > Issue Type: Bug > Components: api > Affects Versions: 1.1.2 > Environment: Window 7, Java 7 > Reporter: Resurgam Immortius > Assignee: Andrew Rubinger > Fix For: 1.1.3 > > > The NIO2 API's SeekableInMemoryByteChannel currently returns 0 when a read requests data either at the end of the data or past the end of the data. > The API for SeekableByteChannel ( http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SeekableByteCh... ) states the return value should be -1 if EOF has been reached. This behavior is confirmed through testing of FileChannelImpl. > Java's sun.nio.cs.StreamDecoder.readBytes() expects this behavior, throwing an IOException if zero bytes are read. > I encountered this issue using GSON to write and then read a json file from a ShrinkWrap archive as part of a unit test. At the end of reading a json file, GSON checks that the EOF has been reached, and at this point a read returns 0 and causes an exception in sun.nio.cs.StreamDecoder.readBytes(). > A unit test showing the issue: > {code:java} > @Test > public void test() throws IOException { > JavaArchive homeArchive = ShrinkWrap.create(JavaArchive.class); > FileSystem vfs = ShrinkWrapFileSystems.newFileSystem(homeArchive); > Path path = vfs.getPath("out.json"); > try (BufferedWriter writer = Files.newBufferedWriter(path, Charset.forName("UTF-8"))) { > new GsonBuilder().create().toJson("Test", writer); > } > try (BufferedReader reader = Files.newBufferedReader(path, Charset.forName("UTF-8"))) { > assertEquals("Test", new GsonBuilder().create().fromJson(reader), String.class)); > } > } > {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, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-461) SeekableInMemoryByteChannel returns incorrect value for EOF

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-461?page=com.atlassian.jira.pl... ] Andrew Rubinger updated SHRINKWRAP-461: --------------------------------------- Git Pull Request: https://github.com/shrinkwrap/shrinkwrap/pull/76 > SeekableInMemoryByteChannel returns incorrect value for EOF > ----------------------------------------------------------- > > Key: SHRINKWRAP-461 > URL: https://issues.jboss.org/browse/SHRINKWRAP-461 > Project: ShrinkWrap > Issue Type: Bug > Components: api > Affects Versions: 1.1.2 > Environment: Window 7, Java 7 > Reporter: Resurgam Immortius > Assignee: Andrew Rubinger > Fix For: 1.1.3 > > > The NIO2 API's SeekableInMemoryByteChannel currently returns 0 when a read requests data either at the end of the data or past the end of the data. > The API for SeekableByteChannel ( http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SeekableByteCh... ) states the return value should be -1 if EOF has been reached. This behavior is confirmed through testing of FileChannelImpl. > Java's sun.nio.cs.StreamDecoder.readBytes() expects this behavior, throwing an IOException if zero bytes are read. > I encountered this issue using GSON to write and then read a json file from a ShrinkWrap archive as part of a unit test. At the end of reading a json file, GSON checks that the EOF has been reached, and at this point a read returns 0 and causes an exception in sun.nio.cs.StreamDecoder.readBytes(). > A unit test showing the issue: > {code:java} > @Test > public void test() throws IOException { > JavaArchive homeArchive = ShrinkWrap.create(JavaArchive.class); > FileSystem vfs = ShrinkWrapFileSystems.newFileSystem(homeArchive); > Path path = vfs.getPath("out.json"); > try (BufferedWriter writer = Files.newBufferedWriter(path, Charset.forName("UTF-8"))) { > new GsonBuilder().create().toJson("Test", writer); > } > try (BufferedReader reader = Files.newBufferedReader(path, Charset.forName("UTF-8"))) { > assertEquals("Test", new GsonBuilder().create().fromJson(reader), String.class)); > } > } > {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, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-461) SeekableInMemoryByteChannel returns incorrect value for EOF

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-461?page=com.atlassian.jira.pl... ] Andrew Rubinger resolved SHRINKWRAP-461. ---------------------------------------- Assignee: Andrew Rubinger Fix Version/s: 1.1.3 Resolution: Done Upstream: Thank you very much for this PR; great work. The comma in the API JavaDocs for SeekableByteChannel confused me in implementing this; at first glance it looked like either 0 or -1 was an appropriate return value. Good catch. 63eb258e9a058e36f7c542d0ee2bd1bbe9a6b011 > SeekableInMemoryByteChannel returns incorrect value for EOF > ----------------------------------------------------------- > > Key: SHRINKWRAP-461 > URL: https://issues.jboss.org/browse/SHRINKWRAP-461 > Project: ShrinkWrap > Issue Type: Bug > Components: api > Affects Versions: 1.1.2 > Environment: Window 7, Java 7 > Reporter: Resurgam Immortius > Assignee: Andrew Rubinger > Fix For: 1.1.3 > > > The NIO2 API's SeekableInMemoryByteChannel currently returns 0 when a read requests data either at the end of the data or past the end of the data. > The API for SeekableByteChannel ( http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SeekableByteCh... ) states the return value should be -1 if EOF has been reached. This behavior is confirmed through testing of FileChannelImpl. > Java's sun.nio.cs.StreamDecoder.readBytes() expects this behavior, throwing an IOException if zero bytes are read. > I encountered this issue using GSON to write and then read a json file from a ShrinkWrap archive as part of a unit test. At the end of reading a json file, GSON checks that the EOF has been reached, and at this point a read returns 0 and causes an exception in sun.nio.cs.StreamDecoder.readBytes(). > A unit test showing the issue: > {code:java} > @Test > public void test() throws IOException { > JavaArchive homeArchive = ShrinkWrap.create(JavaArchive.class); > FileSystem vfs = ShrinkWrapFileSystems.newFileSystem(homeArchive); > Path path = vfs.getPath("out.json"); > try (BufferedWriter writer = Files.newBufferedWriter(path, Charset.forName("UTF-8"))) { > new GsonBuilder().create().toJson("Test", writer); > } > try (BufferedReader reader = Files.newBufferedReader(path, Charset.forName("UTF-8"))) { > assertEquals("Test", new GsonBuilder().create().fromJson(reader), String.class)); > } > } > {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, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-461) SeekableInMemoryByteChannel returns incorrect value for EOF

by Resurgam Immortius (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-461?page=com.atlassian.jira.pl... ] Resurgam Immortius commented on SHRINKWRAP-461: ----------------------------------------------- The problem can more easily be reproduced by using Files.readAllLines(), which will similarly fail. > SeekableInMemoryByteChannel returns incorrect value for EOF > ----------------------------------------------------------- > > Key: SHRINKWRAP-461 > URL: https://issues.jboss.org/browse/SHRINKWRAP-461 > Project: ShrinkWrap > Issue Type: Bug > Components: api > Affects Versions: 1.1.2 > Environment: Window 7, Java 7 > Reporter: Resurgam Immortius > > The NIO2 API's SeekableInMemoryByteChannel currently returns 0 when a read requests data either at the end of the data or past the end of the data. > The API for SeekableByteChannel ( http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SeekableByteCh... ) states the return value should be -1 if EOF has been reached. This behavior is confirmed through testing of FileChannelImpl. > Java's sun.nio.cs.StreamDecoder.readBytes() expects this behavior, throwing an IOException if zero bytes are read. > I encountered this issue using GSON to write and then read a json file from a ShrinkWrap archive as part of a unit test. At the end of reading a json file, GSON checks that the EOF has been reached, and at this point a read returns 0 and causes an exception in sun.nio.cs.StreamDecoder.readBytes(). > A unit test showing the issue: > {code:java} > @Test > public void test() throws IOException { > JavaArchive homeArchive = ShrinkWrap.create(JavaArchive.class); > FileSystem vfs = ShrinkWrapFileSystems.newFileSystem(homeArchive); > Path path = vfs.getPath("out.json"); > try (BufferedWriter writer = Files.newBufferedWriter(path, Charset.forName("UTF-8"))) { > new GsonBuilder().create().toJson("Test", writer); > } > try (BufferedReader reader = Files.newBufferedReader(path, Charset.forName("UTF-8"))) { > assertEquals("Test", new GsonBuilder().create().fromJson(reader), String.class)); > } > } > {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, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-461) SeekableInMemoryByteChannel returns incorrect value for EOF

by Resurgam Immortius (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-461?page=com.atlassian.jira.pl... ] Resurgam Immortius updated SHRINKWRAP-461: ------------------------------------------ Description: The NIO2 API's SeekableInMemoryByteChannel currently returns 0 when a read requests data either at the end of the data or past the end of the data. The API for SeekableByteChannel ( http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SeekableByteCh... ) states the return value should be -1 if EOF has been reached. This behavior is confirmed through testing of FileChannelImpl. Java's sun.nio.cs.StreamDecoder.readBytes() expects this behavior, throwing an IOException if zero bytes are read. I encountered this issue using GSON to write and then read a json file from a ShrinkWrap archive as part of a unit test. At the end of reading a json file, GSON checks that the EOF has been reached, and at this point a read returns 0 and causes an exception in sun.nio.cs.StreamDecoder.readBytes(). A unit test showing the issue: {code:java} @Test public void test() throws IOException { JavaArchive homeArchive = ShrinkWrap.create(JavaArchive.class); FileSystem vfs = ShrinkWrapFileSystems.newFileSystem(homeArchive); Path path = vfs.getPath("out.json"); try (BufferedWriter writer = Files.newBufferedWriter(path, Charset.forName("UTF-8"))) { new GsonBuilder().create().toJson("Test", writer); } try (BufferedReader reader = Files.newBufferedReader(path, Charset.forName("UTF-8"))) { assertEquals("Test", new GsonBuilder().create().fromJson(reader), String.class)); } } {code} was: The NIO2 API's SeekableInMemoryByteChannel currently returns 0 when a read requests data either at the end of the data or past the end of the data. The API for SeekableByteChannel ( http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SeekableByteCh... ) states the return value should be -1 if EOF has been reached. This behavior is confirmed through testing of FileChannelImpl. Java's sun.nio.cs.StreamDecoder.readBytes() expects this behavior, throwing an IOException if zero bytes are read. I encountered this issue using GSON to write and then read a json file from a ShrinkWrap archive as part of a unit test. At the end of reading a json file, GSON checks that the EOF has been reached, and at this point a read returns 0 and causes an exception in sun.nio.cs.StreamDecoder.readBytes(). A unit test showing the issue: {code:java} @Test public void test() throws IOException { JavaArchive homeArchive = ShrinkWrap.create(JavaArchive.class); FileSystem vfs = ShrinkWrapFileSystems.newFileSystem(homeArchive); Path path = vfs.getPath("out.json"); new GsonBuilder().create().toJson("Test", Files.newBufferedWriter(path, Charset.forName("UTF-8"))); assertEquals("Test", new GsonBuilder().create().fromJson(Files.newBufferedReader(path, Charset.forName("UTF-8")), String.class)); } {code} > SeekableInMemoryByteChannel returns incorrect value for EOF > ----------------------------------------------------------- > > Key: SHRINKWRAP-461 > URL: https://issues.jboss.org/browse/SHRINKWRAP-461 > Project: ShrinkWrap > Issue Type: Bug > Components: api > Affects Versions: 1.1.2 > Environment: Window 7, Java 7 > Reporter: Resurgam Immortius > > The NIO2 API's SeekableInMemoryByteChannel currently returns 0 when a read requests data either at the end of the data or past the end of the data. > The API for SeekableByteChannel ( http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SeekableByteCh... ) states the return value should be -1 if EOF has been reached. This behavior is confirmed through testing of FileChannelImpl. > Java's sun.nio.cs.StreamDecoder.readBytes() expects this behavior, throwing an IOException if zero bytes are read. > I encountered this issue using GSON to write and then read a json file from a ShrinkWrap archive as part of a unit test. At the end of reading a json file, GSON checks that the EOF has been reached, and at this point a read returns 0 and causes an exception in sun.nio.cs.StreamDecoder.readBytes(). > A unit test showing the issue: > {code:java} > @Test > public void test() throws IOException { > JavaArchive homeArchive = ShrinkWrap.create(JavaArchive.class); > FileSystem vfs = ShrinkWrapFileSystems.newFileSystem(homeArchive); > Path path = vfs.getPath("out.json"); > try (BufferedWriter writer = Files.newBufferedWriter(path, Charset.forName("UTF-8"))) { > new GsonBuilder().create().toJson("Test", writer); > } > try (BufferedReader reader = Files.newBufferedReader(path, Charset.forName("UTF-8"))) { > assertEquals("Test", new GsonBuilder().create().fromJson(reader), String.class)); > } > } > {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, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-461) SeekableInMemoryByteChannel returns incorrect value for EOF

by Resurgam Immortius (JIRA)

Resurgam Immortius created SHRINKWRAP-461: --------------------------------------------- Summary: SeekableInMemoryByteChannel returns incorrect value for EOF Key: SHRINKWRAP-461 URL: https://issues.jboss.org/browse/SHRINKWRAP-461 Project: ShrinkWrap Issue Type: Bug Components: api Affects Versions: 1.1.2 Environment: Window 7, Java 7 Reporter: Resurgam Immortius The NIO2 API's SeekableInMemoryByteChannel currently returns 0 when a read requests data either at the end of the data or past the end of the data. The API for SeekableByteChannel ( http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SeekableByteCh... ) states the return value should be -1 if EOF has been reached. This behavior is confirmed through testing of FileChannelImpl. Java's sun.nio.cs.StreamDecoder.readBytes() expects this behavior, throwing an IOException if zero bytes are read. I encountered this issue using GSON to write and then read a json file from a ShrinkWrap archive as part of a unit test. At the end of reading a json file, GSON checks that the EOF has been reached, and at this point a read returns 0 and causes an exception in sun.nio.cs.StreamDecoder.readBytes(). A unit test showing the issue: {code:java} @Test public void test() throws IOException { JavaArchive homeArchive = ShrinkWrap.create(JavaArchive.class); FileSystem vfs = ShrinkWrapFileSystems.newFileSystem(homeArchive); Path path = vfs.getPath("out.json"); new GsonBuilder().create().toJson("Test", Files.newBufferedWriter(path, Charset.forName("UTF-8"))); assertEquals("Test", new GsonBuilder().create().fromJson(Files.newBufferedReader(path, Charset.forName("UTF-8")), String.class)); } {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, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues July 2013