[jira] [Updated] (CONFIGURATION-700) Issue With backslash(\) and Forwardslash(/)
[ https://issues.apache.org/jira/browse/CONFIGURATION-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amitabh Pandey updated CONFIGURATION-700: - Description: Dear Team, I am using commons-configuration-1.10.jar for updating property file in java. I have achieve all my requirement(Preserve comment, White space) with this API.But stuck at one point.It is not working as per my expectations with slash.Below is one example. I have below url in my properties file. *C\:ABC.net/wsdl* Now it is getting change to below after modification *C:ABC.net\/wsdl* Means it is removing the backslash and changing forwardslash to \/.I know it is escaping character. But is there any way to prevent this. I cant not change any thing in property file. I have to handle through code only. Because of only this issue I again moved to Java util API. Please check fix of this. Rest is excellent. was: Dear Team, I am using commons-configuration-1.10.jar for updating property file in java. I have achieve all my requirement(Preserve comment, White space) with this API.But stuck at one point.It is not working as per my expectations with slash.Below is one example. I have below url in my properties file. C\:\\ABC.net Now it is getting change to below after modification C:\/\/ABC.net Means it is removing the backslash and changing forwardslash to \/.I know it is escaping character. But is there any way to prevent this. I cant not change any thing in property file. I have to handle through code only. Because of only this issue I again moved to Java util API. Please check fix of this. Rest is excellent. > Issue With backslash(\) and Forwardslash(/) > --- > > Key: CONFIGURATION-700 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-700 > Project: Commons Configuration > Issue Type: Bug > Components: Build >Affects Versions: 1.10 >Reporter: Amitabh Pandey >Priority: Major > Fix For: 1.10 > > > Dear Team, > I am using commons-configuration-1.10.jar for updating property file in java. > I have achieve all my requirement(Preserve comment, White space) with this > API.But stuck at one point.It is not working as per my expectations with > slash.Below is one example. > I have below url in my properties file. > *C\:ABC.net/wsdl* > Now it is getting change to below after modification > *C:ABC.net\/wsdl* > Means it is removing the backslash and changing forwardslash to \/.I know it > is escaping character. But is there any way to prevent this. I cant not > change any thing in property file. I have to handle through code only. > Because of only this issue I again moved to Java util API. > Please check fix of this. Rest is excellent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CONFIGURATION-700) Issue With backslash(\) and Forwardslash(/)
Amitabh Pandey created CONFIGURATION-700: Summary: Issue With backslash(\) and Forwardslash(/) Key: CONFIGURATION-700 URL: https://issues.apache.org/jira/browse/CONFIGURATION-700 Project: Commons Configuration Issue Type: Bug Components: Build Affects Versions: 1.10 Reporter: Amitabh Pandey Fix For: 1.10 Dear Team, I am using commons-configuration-1.10.jar for updating property file in java. I have achieve all my requirement(Preserve comment, White space) with this API.But stuck at one point.It is not working as per my expectations with slash.Below is one example. I have below url in my properties file. C\:\\ABC.net Now it is getting change to below after modification C:\/\/ABC.net Means it is removing the backslash and changing forwardslash to \/.I know it is escaping character. But is there any way to prevent this. I cant not change any thing in property file. I have to handle through code only. Because of only this issue I again moved to Java util API. Please check fix of this. Rest is excellent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (DBCP-476) AbandonedTrace.getTrace() contains race condition
[
https://issues.apache.org/jira/browse/DBCP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher resolved DBCP-476.
Resolution: Fixed
Assignee: Pascal Schumacher
Fix Version/s: 2.3.0
> AbandonedTrace.getTrace() contains race condition
> -
>
> Key: DBCP-476
> URL: https://issues.apache.org/jira/browse/DBCP-476
> Project: Commons DBCP
> Issue Type: Bug
>Reporter: Richard Cordova
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 2.3.0
>
>
> The clean up code in AbandonedTrace is subject to the reference being cleared
> in between the condition being checked and the referent being added to the
> result.
> {code}
> while (iter.hasNext()) {
> WeakReference ref = iter.next();
> if (ref.get() == null) {
> // Clean-up since we are here anyway
> iter.remove();
> } else {
> result.add(ref.get());
> }
> }
> {code}
> This can surface as a NullPointerException, e.g.
> {noformat}
> Caused by: java.lang.NullPointerException
> at
> org.apache.tomcat.dbcp.dbcp2.DelegatingStatement.close(DelegatingStatement.java:149)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-452) "Stream is not in the BZip2 format" exception on valid archive
[
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466246#comment-16466246
]
Stefan Bodewig commented on COMPRESS-452:
-
yes, done:
https://github.com/apache/commons-compress/commit/8040ea3db6f813afe6e83c935ed33e5c65966a60
> "Stream is not in the BZip2 format" exception on valid archive
> --
>
> Key: COMPRESS-452
> URL: https://issues.apache.org/jira/browse/COMPRESS-452
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers, Compressors
>Affects Versions: 1.16.1
>Reporter: Tomisław Kityński
>Priority: Major
> Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
> not in the BZip2 format" exception.
> The code is:
> {code:java}
> private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
> String fileName = "r:/txt.7z";
> SevenZArchiveEntry entry;
> try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
> while ((entry = arch.getNextEntry()) != null)
> { System.out.println(entry.getName()); }
> }
> {code}
> The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
> byte[]) constructor. Password seems to be OK, since changing it yields
> different exception (and it also works in 7z tool).
> Full exception is:
> {noformat}
> Exception in thread "main" java.io.IOException: Stream is not in the BZip2
> format
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> at
> org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
> at
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
> at UnpackTest.main(UnpackTest.java:17)
> {noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-452) "Stream is not in the BZip2 format" exception on valid archive
[
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466117#comment-16466117
]
Joerg Schaible commented on COMPRESS-452:
-
We may add one more constructor without password argument. Anybody using null
may then simply remove it.
> "Stream is not in the BZip2 format" exception on valid archive
> --
>
> Key: COMPRESS-452
> URL: https://issues.apache.org/jira/browse/COMPRESS-452
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers, Compressors
>Affects Versions: 1.16.1
>Reporter: Tomisław Kityński
>Priority: Major
> Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
> not in the BZip2 format" exception.
> The code is:
> {code:java}
> private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
> String fileName = "r:/txt.7z";
> SevenZArchiveEntry entry;
> try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
> while ((entry = arch.getNextEntry()) != null)
> { System.out.println(entry.getName()); }
> }
> {code}
> The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
> byte[]) constructor. Password seems to be OK, since changing it yields
> different exception (and it also works in 7z tool).
> Full exception is:
> {noformat}
> Exception in thread "main" java.io.IOException: Stream is not in the BZip2
> format
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> at
> org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
> at
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
> at UnpackTest.main(UnpackTest.java:17)
> {noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-452) "Stream is not in the BZip2 format" exception on valid archive
[
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466094#comment-16466094
]
Sebb commented on COMPRESS-452:
---
https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html
13.2 "... The Java programming language is designed to prevent additions to
contracts and accidental name collisions from breaking binary compatibility.
Specifically, addition of more methods overloading a particular method name
does not break compatibility with pre-existing binaries. The method signature
that the pre-existing binary will use for method lookup is chosen by the method
overload resolution algorithm at compile time (§15.12.2)."
AFAICT the method signature is recorded in the class file in order to
facilitate this.
However it will break source compatibility; the compiler cannot resolve the
ambiguity once the new method is available.
Note that Maven/Clirr does not distinguish binary and source compatibility.
Don't know about Japicmp.
> "Stream is not in the BZip2 format" exception on valid archive
> --
>
> Key: COMPRESS-452
> URL: https://issues.apache.org/jira/browse/COMPRESS-452
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers, Compressors
>Affects Versions: 1.16.1
>Reporter: Tomisław Kityński
>Priority: Major
> Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
> not in the BZip2 format" exception.
> The code is:
> {code:java}
> private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
> String fileName = "r:/txt.7z";
> SevenZArchiveEntry entry;
> try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
> while ((entry = arch.getNextEntry()) != null)
> { System.out.println(entry.getName()); }
> }
> {code}
> The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
> byte[]) constructor. Password seems to be OK, since changing it yields
> different exception (and it also works in 7z tool).
> Full exception is:
> {noformat}
> Exception in thread "main" java.io.IOException: Stream is not in the BZip2
> format
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> at
> org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
> at
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
> at UnpackTest.main(UnpackTest.java:17)
> {noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (COMPRESS-452) "Stream is not in the BZip2 format" exception on valid archive
[
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466089#comment-16466089
]
Stefan Bodewig edited comment on COMPRESS-452 at 5/7/18 4:12 PM:
-
japicmp doesn't see any breaking change at all, not even a source one. I'd
blame this on japicmp :-) I haven't been able to use Clirr on Compress for a
while now, the details are escaping me.
As for binary compatibility I'm pretty sure the constructor signature seen by
the compiler will be used. Method dispatch does most of its magic at compile
time and at runtime only looks for the most derived class that provides the
signature. In the case of constructors there is no derived class to look into
at all.
was (Author: bodewig):
japicmp doesn't see any breaking change at all, not even a source one. I'd
blame this i´n japicmp :-) I haven't been able to use Clirr on Compress for a
while now, the details are escaping me.
As for binary compatibility I'm pretty sure the constructor signature seen by
the compiler will be used. Method dispatch does most of its magic at compile
time and at runtime only looks for the most derived class that provides the
signature. In the case of constructors there is no derived class to look into
at all.
> "Stream is not in the BZip2 format" exception on valid archive
> --
>
> Key: COMPRESS-452
> URL: https://issues.apache.org/jira/browse/COMPRESS-452
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers, Compressors
>Affects Versions: 1.16.1
>Reporter: Tomisław Kityński
>Priority: Major
> Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
> not in the BZip2 format" exception.
> The code is:
> {code:java}
> private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
> String fileName = "r:/txt.7z";
> SevenZArchiveEntry entry;
> try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
> while ((entry = arch.getNextEntry()) != null)
> { System.out.println(entry.getName()); }
> }
> {code}
> The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
> byte[]) constructor. Password seems to be OK, since changing it yields
> different exception (and it also works in 7z tool).
> Full exception is:
> {noformat}
> Exception in thread "main" java.io.IOException: Stream is not in the BZip2
> format
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> at
> org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
> at
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
> at UnpackTest.main(UnpackTest.java:17)
> {noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-452) "Stream is not in the BZip2 format" exception on valid archive
[
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466089#comment-16466089
]
Stefan Bodewig commented on COMPRESS-452:
-
japicmp doesn't see any breaking change at all, not even a source one. I'd
blame this i´n japicmp :-) I haven't been able to use Clirr on Compress for a
while now, the details are escaping me.
As for binary compatibility I'm pretty sure the constructor signature seen by
the compiler will be used. Method dispatch does most of its magic at compile
time and at runtime only looks for the most derived class that provides the
signature. In the case of constructors there is no derived class to look into
at all.
> "Stream is not in the BZip2 format" exception on valid archive
> --
>
> Key: COMPRESS-452
> URL: https://issues.apache.org/jira/browse/COMPRESS-452
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers, Compressors
>Affects Versions: 1.16.1
>Reporter: Tomisław Kityński
>Priority: Major
> Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
> not in the BZip2 format" exception.
> The code is:
> {code:java}
> private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
> String fileName = "r:/txt.7z";
> SevenZArchiveEntry entry;
> try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
> while ((entry = arch.getNextEntry()) != null)
> { System.out.println(entry.getName()); }
> }
> {code}
> The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
> byte[]) constructor. Password seems to be OK, since changing it yields
> different exception (and it also works in 7z tool).
> Full exception is:
> {noformat}
> Exception in thread "main" java.io.IOException: Stream is not in the BZip2
> format
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> at
> org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
> at
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
> at UnpackTest.main(UnpackTest.java:17)
> {noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-452) "Stream is not in the BZip2 format" exception on valid archive
[
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466069#comment-16466069
]
Michael Osipov commented on COMPRESS-452:
-
Which constructor would be chosen?
{code:java}
new SevenZFile(new File(fileName), null))
{code}
{{byte[]}} or {{char[]}}?
> "Stream is not in the BZip2 format" exception on valid archive
> --
>
> Key: COMPRESS-452
> URL: https://issues.apache.org/jira/browse/COMPRESS-452
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers, Compressors
>Affects Versions: 1.16.1
>Reporter: Tomisław Kityński
>Priority: Major
> Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
> not in the BZip2 format" exception.
> The code is:
> {code:java}
> private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
> String fileName = "r:/txt.7z";
> SevenZArchiveEntry entry;
> try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
> while ((entry = arch.getNextEntry()) != null)
> { System.out.println(entry.getName()); }
> }
> {code}
> The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
> byte[]) constructor. Password seems to be OK, since changing it yields
> different exception (and it also works in 7z tool).
> Full exception is:
> {noformat}
> Exception in thread "main" java.io.IOException: Stream is not in the BZip2
> format
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> at
> org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
> at
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
> at UnpackTest.main(UnpackTest.java:17)
> {noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-452) "Stream is not in the BZip2 format" exception on valid archive
[
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466055#comment-16466055
]
Gary Gregory commented on COMPRESS-452:
---
How? Please explain.
> "Stream is not in the BZip2 format" exception on valid archive
> --
>
> Key: COMPRESS-452
> URL: https://issues.apache.org/jira/browse/COMPRESS-452
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers, Compressors
>Affects Versions: 1.16.1
>Reporter: Tomisław Kityński
>Priority: Major
> Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
> not in the BZip2 format" exception.
> The code is:
> {code:java}
> private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
> String fileName = "r:/txt.7z";
> SevenZArchiveEntry entry;
> try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
> while ((entry = arch.getNextEntry()) != null)
> { System.out.println(entry.getName()); }
> }
> {code}
> The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
> byte[]) constructor. Password seems to be OK, since changing it yields
> different exception (and it also works in 7z tool).
> Full exception is:
> {noformat}
> Exception in thread "main" java.io.IOException: Stream is not in the BZip2
> format
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> at
> org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
> at
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
> at UnpackTest.main(UnpackTest.java:17)
> {noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-452) "Stream is not in the BZip2 format" exception on valid archive
[
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466041#comment-16466041
]
Michael Osipov commented on COMPRESS-452:
-
Passing {{null}} would be a problem, wouldn't it [~garydgregory]?
> "Stream is not in the BZip2 format" exception on valid archive
> --
>
> Key: COMPRESS-452
> URL: https://issues.apache.org/jira/browse/COMPRESS-452
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers, Compressors
>Affects Versions: 1.16.1
>Reporter: Tomisław Kityński
>Priority: Major
> Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
> not in the BZip2 format" exception.
> The code is:
> {code:java}
> private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
> String fileName = "r:/txt.7z";
> SevenZArchiveEntry entry;
> try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
> while ((entry = arch.getNextEntry()) != null)
> { System.out.println(entry.getName()); }
> }
> {code}
> The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
> byte[]) constructor. Password seems to be OK, since changing it yields
> different exception (and it also works in 7z tool).
> Full exception is:
> {noformat}
> Exception in thread "main" java.io.IOException: Stream is not in the BZip2
> format
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> at
> org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
> at
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
> at UnpackTest.main(UnpackTest.java:17)
> {noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (COMPRESS-452) "Stream is not in the BZip2 format" exception on valid archive
[
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466031#comment-16466031
]
Gary Gregory edited comment on COMPRESS-452 at 5/7/18 3:29 PM:
---
Adding constructors does not break BC since the old ones are still there to be
found. Breaking source compatibility is a pain but OK as long as we document
what users should do in Javadocs.
What does mvn clirr:check report. Also try japicmp.
was (Author: garydgregory):
Adding constructors does not break BC since the old ones are still there to be
found. Breaking source compatibility is a pain but OK as long as we document
what users should do in Javadocs.
> "Stream is not in the BZip2 format" exception on valid archive
> --
>
> Key: COMPRESS-452
> URL: https://issues.apache.org/jira/browse/COMPRESS-452
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers, Compressors
>Affects Versions: 1.16.1
>Reporter: Tomisław Kityński
>Priority: Major
> Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
> not in the BZip2 format" exception.
> The code is:
> {code:java}
> private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
> String fileName = "r:/txt.7z";
> SevenZArchiveEntry entry;
> try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
> while ((entry = arch.getNextEntry()) != null)
> { System.out.println(entry.getName()); }
> }
> {code}
> The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
> byte[]) constructor. Password seems to be OK, since changing it yields
> different exception (and it also works in 7z tool).
> Full exception is:
> {noformat}
> Exception in thread "main" java.io.IOException: Stream is not in the BZip2
> format
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> at
> org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
> at
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
> at UnpackTest.main(UnpackTest.java:17)
> {noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (COMPRESS-452) "Stream is not in the BZip2 format" exception on valid archive
[
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466031#comment-16466031
]
Gary Gregory edited comment on COMPRESS-452 at 5/7/18 3:29 PM:
---
Adding constructors does not break BC since the old ones are still there to be
found. Breaking source compatibility is a pain but OK as long as we document
what users should do in Javadocs.
What does mvn clirr:check report? Also try japicmp.
was (Author: garydgregory):
Adding constructors does not break BC since the old ones are still there to be
found. Breaking source compatibility is a pain but OK as long as we document
what users should do in Javadocs.
What does mvn clirr:check report. Also try japicmp.
> "Stream is not in the BZip2 format" exception on valid archive
> --
>
> Key: COMPRESS-452
> URL: https://issues.apache.org/jira/browse/COMPRESS-452
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers, Compressors
>Affects Versions: 1.16.1
>Reporter: Tomisław Kityński
>Priority: Major
> Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
> not in the BZip2 format" exception.
> The code is:
> {code:java}
> private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
> String fileName = "r:/txt.7z";
> SevenZArchiveEntry entry;
> try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
> while ((entry = arch.getNextEntry()) != null)
> { System.out.println(entry.getName()); }
> }
> {code}
> The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
> byte[]) constructor. Password seems to be OK, since changing it yields
> different exception (and it also works in 7z tool).
> Full exception is:
> {noformat}
> Exception in thread "main" java.io.IOException: Stream is not in the BZip2
> format
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> at
> org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
> at
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
> at UnpackTest.main(UnpackTest.java:17)
> {noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-452) "Stream is not in the BZip2 format" exception on valid archive
[
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466031#comment-16466031
]
Gary Gregory commented on COMPRESS-452:
---
Adding constructors does not break BC since the old ones are still there to be
found. Breaking source compatibility is a pain but OK as long as we document
what users should do in Javadocs.
> "Stream is not in the BZip2 format" exception on valid archive
> --
>
> Key: COMPRESS-452
> URL: https://issues.apache.org/jira/browse/COMPRESS-452
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers, Compressors
>Affects Versions: 1.16.1
>Reporter: Tomisław Kityński
>Priority: Major
> Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
> not in the BZip2 format" exception.
> The code is:
> {code:java}
> private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
> String fileName = "r:/txt.7z";
> SevenZArchiveEntry entry;
> try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
> while ((entry = arch.getNextEntry()) != null)
> { System.out.println(entry.getName()); }
> }
> {code}
> The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
> byte[]) constructor. Password seems to be OK, since changing it yields
> different exception (and it also works in 7z tool).
> Full exception is:
> {noformat}
> Exception in thread "main" java.io.IOException: Stream is not in the BZip2
> format
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> at
> org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
> at
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
> at UnpackTest.main(UnpackTest.java:17)
> {noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-452) "Stream is not in the BZip2 format" exception on valid archive
[
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465989#comment-16465989
]
Michael Osipov commented on COMPRESS-452:
-
Ouch, this breaks binary compat, doesn't it?
> "Stream is not in the BZip2 format" exception on valid archive
> --
>
> Key: COMPRESS-452
> URL: https://issues.apache.org/jira/browse/COMPRESS-452
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers, Compressors
>Affects Versions: 1.16.1
>Reporter: Tomisław Kityński
>Priority: Major
> Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
> not in the BZip2 format" exception.
> The code is:
> {code:java}
> private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
> String fileName = "r:/txt.7z";
> SevenZArchiveEntry entry;
> try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
> while ((entry = arch.getNextEntry()) != null)
> { System.out.println(entry.getName()); }
> }
> {code}
> The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
> byte[]) constructor. Password seems to be OK, since changing it yields
> different exception (and it also works in 7z tool).
> Full exception is:
> {noformat}
> Exception in thread "main" java.io.IOException: Stream is not in the BZip2
> format
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> at
> org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
> at
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
> at UnpackTest.main(UnpackTest.java:17)
> {noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-452) "Stream is not in the BZip2 format" exception on valid archive
[
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465961#comment-16465961
]
Stefan Bodewig commented on COMPRESS-452:
-
[~michael-o]
https://github.com/apache/commons-compress/commit/237e1721221d158f6800e868cbefc83f02385029
:-)
Problem is - and that's why it is not on master, yet - all code that used a
constructor passing an explicit {{null}} as password would need to be adjusted
in order to compile.
> "Stream is not in the BZip2 format" exception on valid archive
> --
>
> Key: COMPRESS-452
> URL: https://issues.apache.org/jira/browse/COMPRESS-452
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers, Compressors
>Affects Versions: 1.16.1
>Reporter: Tomisław Kityński
>Priority: Major
> Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
> not in the BZip2 format" exception.
> The code is:
> {code:java}
> private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
> String fileName = "r:/txt.7z";
> SevenZArchiveEntry entry;
> try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
> while ((entry = arch.getNextEntry()) != null)
> { System.out.println(entry.getName()); }
> }
> {code}
> The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
> byte[]) constructor. Password seems to be OK, since changing it yields
> different exception (and it also works in 7z tool).
> Full exception is:
> {noformat}
> Exception in thread "main" java.io.IOException: Stream is not in the BZip2
> format
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> at
> org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
> at
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
> at UnpackTest.main(UnpackTest.java:17)
> {noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-452) "Stream is not in the BZip2 format" exception on valid archive
[
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465893#comment-16465893
]
Michael Osipov commented on COMPRESS-452:
-
[~bodewig], I'd really deprecate the constructors and move to {{char[]}}. This
bug is so subtile that the client will search way too long for the cause.
> "Stream is not in the BZip2 format" exception on valid archive
> --
>
> Key: COMPRESS-452
> URL: https://issues.apache.org/jira/browse/COMPRESS-452
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers, Compressors
>Affects Versions: 1.16.1
>Reporter: Tomisław Kityński
>Priority: Major
> Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
> not in the BZip2 format" exception.
> The code is:
> {code:java}
> private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
> String fileName = "r:/txt.7z";
> SevenZArchiveEntry entry;
> try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
> while ((entry = arch.getNextEntry()) != null)
> { System.out.println(entry.getName()); }
> }
> {code}
> The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
> byte[]) constructor. Password seems to be OK, since changing it yields
> different exception (and it also works in 7z tool).
> Full exception is:
> {noformat}
> Exception in thread "main" java.io.IOException: Stream is not in the BZip2
> format
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> at
> org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
> at
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
> at UnpackTest.main(UnpackTest.java:17)
> {noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (COMPRESS-452) "Stream is not in the BZip2 format" exception on valid archive
[
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated COMPRESS-452:
Description:
The included 7z archive (with only one file), that is password protected, can
be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
not in the BZip2 format" exception.
The code is:
{code:java}
private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
public static void main(String[] args) throws IOException {
String fileName = "r:/txt.7z";
SevenZArchiveEntry entry;
try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
while ((entry = arch.getNextEntry()) != null)
{ System.out.println(entry.getName()); }
}
{code}
The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
byte[]) constructor. Password seems to be OK, since changing it yields
different exception (and it also works in 7z tool).
Full exception is:
{noformat}
Exception in thread "main" java.io.IOException: Stream is not in the BZip2
format
at
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
at
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
at
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
at
org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
at
org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
at
org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
at
org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
at
org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
at UnpackTest.main(UnpackTest.java:17)
{noformat}
was:
The included 7z archive (with only one file), that is password protected, can
be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
not in the BZip2 format" exception.
The code is:
{{private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
public static void main(String[] args) throws IOException {
String fileName = "r:/txt.7z";
SevenZArchiveEntry entry;
try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
while ((entry = arch.getNextEntry()) != null)
{ System.out.println(entry.getName()); }
}
}}}
The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
byte[]) constructor. Password seems to be OK, since changing it yields
different exception (and it also works in 7z tool).
Full exception is:
Exception in thread "main" java.io.IOException: Stream is not in the BZip2
format
at
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
at
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
at
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
at
org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
at
org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
at
org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
at
org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
at
org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
at UnpackTest.main(UnpackTest.java:17)
PS Sorry for the bad formatting, but I it seems like this editor must be much
smarter than me and it knows better.
> "Stream is not in the BZip2 format" exception on valid archive
> --
>
> Key: COMPRESS-452
> URL: https://issues.apache.org/jira/browse/COMPRESS-452
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers, Compressors
>Affects Versions: 1.16.1
>Reporter: Tomisław Kityński
>Priority: Major
> Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
> not in the BZip2 format" exception.
> The code is:
> {code:java}
> private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
> String fileName = "r:/txt.7z";
> SevenZArchiveEntry entry;
> try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
> while ((entry = arch.getNextEntry()) != null)
> {
[jira] [Commented] (DAEMON-385) commons-daemon-1.1.0 not supported with AIX 7
[ https://issues.apache.org/jira/browse/DAEMON-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465800#comment-16465800 ] Michael Osipov commented on DAEMON-385: --- We can only support systems we have access to. You can provide patches for AIX. > commons-daemon-1.1.0 not supported with AIX 7 > - > > Key: DAEMON-385 > URL: https://issues.apache.org/jira/browse/DAEMON-385 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: 1.1.0 >Reporter: vikram >Priority: Major > > when run .cofigure script to created JSVC getting error *configure: error: > Unsupported operating system "aix7.1.4.0".* > > > ./configure > *** Current host *** > checking build system type... powerpc-ibm-aix7.1.4.0 > checking host system type... powerpc-ibm-aix7.1.4.0 > checking cached host system type... ok > *** C-Language compilation tools *** > checking for gcc... gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking for ranlib... ranlib > checking for strip... strip > *** Host support *** > checking C flags dependant on host system type... failed > configure: error: Unsupported operating system "aix7.1.4.0" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MATH-1459) Create a way to calculate the Jacobian Matrix using a Differentiator
[
https://issues.apache.org/jira/browse/MATH-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465752#comment-16465752
]
Gilles commented on MATH-1459:
--
bq. Will the unit test extend AbstractLeastSquaresOptimizerAbstractTest? Or
will it extend nothing?
As per my previous comment, it should not extend
{{AbstractLeastSquaresOptimizerAbstractTest}} since that class is meant to test
an optimizer, while the functionality here concerns is an _input_ to the
optimizer.
> Create a way to calculate the Jacobian Matrix using a Differentiator
>
>
> Key: MATH-1459
> URL: https://issues.apache.org/jira/browse/MATH-1459
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 4.X
>Reporter: adrian
>Priority: Minor
> Fix For: 4.X
>
>
> Create a way to automatically calculate a Jacobian Matrix using a
> Differentiator.
> I have done this with a pull request, but would like feedback.
> edit: https://github.com/apache/commons-math/pull/84
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IO-559) FilenameUtils.normalize should verify hostname syntax in UNC path
[
https://issues.apache.org/jira/browse/IO-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465706#comment-16465706
]
Maria Dima commented on IO-559:
---
Hello, is there any feedback on this issue?
How critical is it considered by Apache community?
> FilenameUtils.normalize should verify hostname syntax in UNC path
> -
>
> Key: IO-559
> URL: https://issues.apache.org/jira/browse/IO-559
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.6
>Reporter: Stefan Bodewig
>Priority: Major
>
> {{FilenameUtils.normalize}} will accept broken file names as UNC path even if
> their hostname part doesn't match the syntax of a proper hostname. Using
> certain hostnames like "." this may lead to strange side effects.
> Most likely the best fix will be to make {{getPrefixLength}} verify the
> hostname part of a suspected UNC path and return a value of {{NOT_FOUND}} if
> it is not a valid hostname - much like it does for triple slashes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-452) "Stream is not in the BZip2 format" exception on valid archive
[
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465655#comment-16465655
]
Tomisław Kityński commented on COMPRESS-452:
Oh, I admit I blindly assumed it should be 8-bit ASCII encoding... Thanks for
pointing that out! 8) Sure, you can include this archive into test suite if you
wish to. Thanks once again!
> "Stream is not in the BZip2 format" exception on valid archive
> --
>
> Key: COMPRESS-452
> URL: https://issues.apache.org/jira/browse/COMPRESS-452
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers, Compressors
>Affects Versions: 1.16.1
>Reporter: Tomisław Kityński
>Priority: Major
> Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is
> not in the BZip2 format" exception.
> The code is:
> {{private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
> String fileName = "r:/txt.7z";
> SevenZArchiveEntry entry;
> try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
> while ((entry = arch.getNextEntry()) != null)
> { System.out.println(entry.getName()); }
> }
> }}}
> The same exception is thrown when one uses SevenZFile(SeekableByteChannel,
> byte[]) constructor. Password seems to be OK, since changing it yields
> different exception (and it also works in 7z tool).
> Full exception is:
> Exception in thread "main" java.io.IOException: Stream is not in the BZip2
> format
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:134)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> at
> org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
> at
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
> at UnpackTest.main(UnpackTest.java:17)
> PS Sorry for the bad formatting, but I it seems like this editor must be
> much smarter than me and it knows better.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
