[jira] [Commented] (COMPRESS-230) Tar archive is not being read correctly
[ https://issues.apache.org/jira/browse/COMPRESS-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678988#comment-13678988 ] Stefan Bodewig commented on COMPRESS-230: - Directories are only to be expected inside the archive if they've been added explicitly. TAR - like all othe archiving formats - doesn't need directory entries at all. It is very common to create directories as needed when extracting archives. Tar archive is not being read correctly --- Key: COMPRESS-230 URL: https://issues.apache.org/jira/browse/COMPRESS-230 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.5 Environment: Ubuntu 12.04 java version 1.7.0_21 OpenJDK Runtime Environment (IcedTea 2.3.9) (7u21-2.3.9-0ubuntu0.12.10.1) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) Reporter: Ken Keefe Attachments: DetExpExample_mob23.tar The TAR archiver is not reading existing tar files correctly. It doesn't happen with every tar, just some of my tar files. I'll attach an example tar file. The first file it reads is not the root directory, but another file in the tar with ._ appended to the front of the file name for some reason. -- 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
[jira] [Commented] (COMPRESS-111) support for lzma files
[ https://issues.apache.org/jira/browse/COMPRESS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679014#comment-13679014 ] Stefan Bodewig commented on COMPRESS-111: - Read support for LZMA has been added inside the LZMA branch - it relies on an unreleased version of XZ for Java. support for lzma files -- Key: COMPRESS-111 URL: https://issues.apache.org/jira/browse/COMPRESS-111 Project: Commons Compress Issue Type: New Feature Components: Compressors Affects Versions: 1.0 Reporter: maurel jean francois Attachments: compress-trunk-lzmaRev0.patch, compress-trunk-lzmaRev1.patch adding support for compressing and decompressing of files with LZMA algoritm (Lempel-Ziv-Markov chain-Algorithm) (see http://markmail.org/search/?q=list%3Aorg.apache.commons.users/#query:list%3Aorg.apache.commons.users%2F+page:1+mid:syn4uuvbzusevtko+state:results) -- 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
[jira] [Created] (CONFIGURATION-546) ClassCastException in BeanHelper constructing beans with a list of child beans
Justin Couch created CONFIGURATION-546:
--
Summary: ClassCastException in BeanHelper constructing beans with
a list of child beans
Key: CONFIGURATION-546
URL: https://issues.apache.org/jira/browse/CONFIGURATION-546
Project: Commons Configuration
Issue Type: Bug
Components: Type conversion
Affects Versions: 1.9, 1.8
Reporter: Justin Couch
Priority: Minor
If you wish to create a bean that has a collection as a property where that
collection contains multiple beans, the code crashes as it assumes that you can
only ever have single bean declarations as children.
For example the following brief construct is not possible to build
class A {
String name;
}
class B {
ListA children;
}
The result is the following stack trace
Caused by: java.lang.ClassCastException: java.util.ArrayList cannot be cast to
org.apache.commons.configuration.beanutils.BeanDeclaration
at
org.apache.commons.configuration.beanutils.BeanHelper.initBean(BeanHelper.java:212)
at
org.apache.commons.configuration.beanutils.TestBeanHelper$TestBeanFactory.createBean(TestBeanHelper.java:579)
at
org.apache.commons.configuration.beanutils.BeanHelper.createBean(BeanHelper.java:342)
... 33 more
It's pretty easy to see why when you look at the code beginning line 208:
for (Map.EntryString, Object e : nestedBeans.entrySet())
{
String propName = e.getKey();
Class? defaultClass = getDefaultClass(bean, propName);
initProperty(bean, propName, createBean(
(BeanDeclaration) e.getValue(), defaultClass));
}
Note the silly assumption that e.getValue() only ever has BeanDeclaration
instances, where it could be BeanDeclaration[], or CollectionBeanDeclaration
as other possible options - which is what the above example show.
Extended version of the existing unit test to follow that illustrates the
problem.
--
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
[jira] [Updated] (CONFIGURATION-546) ClassCastException in BeanHelper constructing beans with a list of child beans
[
https://issues.apache.org/jira/browse/CONFIGURATION-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Couch updated CONFIGURATION-546:
---
Attachment: TestBeanHelper.java
BeanCreationTestBeanWithListChild.java
Updated unit test and new bean showing the crash.
ClassCastException in BeanHelper constructing beans with a list of child beans
--
Key: CONFIGURATION-546
URL: https://issues.apache.org/jira/browse/CONFIGURATION-546
Project: Commons Configuration
Issue Type: Bug
Components: Type conversion
Affects Versions: 1.8, 1.9
Reporter: Justin Couch
Priority: Minor
Attachments: BeanCreationTestBeanWithListChild.java,
TestBeanHelper.java
If you wish to create a bean that has a collection as a property where that
collection contains multiple beans, the code crashes as it assumes that you
can only ever have single bean declarations as children.
For example the following brief construct is not possible to build
class A {
String name;
}
class B {
ListA children;
}
The result is the following stack trace
Caused by: java.lang.ClassCastException: java.util.ArrayList cannot be cast
to org.apache.commons.configuration.beanutils.BeanDeclaration
at
org.apache.commons.configuration.beanutils.BeanHelper.initBean(BeanHelper.java:212)
at
org.apache.commons.configuration.beanutils.TestBeanHelper$TestBeanFactory.createBean(TestBeanHelper.java:579)
at
org.apache.commons.configuration.beanutils.BeanHelper.createBean(BeanHelper.java:342)
... 33 more
It's pretty easy to see why when you look at the code beginning line 208:
for (Map.EntryString, Object e : nestedBeans.entrySet())
{
String propName = e.getKey();
Class? defaultClass = getDefaultClass(bean, propName);
initProperty(bean, propName, createBean(
(BeanDeclaration) e.getValue(), defaultClass));
}
Note the silly assumption that e.getValue() only ever has BeanDeclaration
instances, where it could be BeanDeclaration[], or
CollectionBeanDeclaration as other possible options - which is what the
above example show.
Extended version of the existing unit test to follow that illustrates the
problem.
--
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
[jira] [Commented] (COMPRESS-54) Add 7zip or RAR archive support
[ https://issues.apache.org/jira/browse/COMPRESS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679056#comment-13679056 ] Stefan Bodewig commented on COMPRESS-54: The LZMA branch now supports LZMA decompression, at least it seems to :-) This currently relies on an unreleased version of XZ for Java. Add 7zip or RAR archive support --- Key: COMPRESS-54 URL: https://issues.apache.org/jira/browse/COMPRESS-54 Project: Commons Compress Issue Type: New Feature Components: Archivers Environment: N/A Reporter: Tim Pinet Priority: Minor Original Estimate: 30h Remaining Estimate: 30h Has anyone looked into adding support for 7zip and RAR file types? Using the j7zip and junrar libraries I was able to get a rough protoype working with commons-compress but only with extract support for RAR (due to licencing issues). Also, my prototype performance is poor so I definately need to improve it. -- 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
[jira] [Updated] (COLLECTIONS-468) Change Bag interface and implementations to conform to Collection interface
[ https://issues.apache.org/jira/browse/COLLECTIONS-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-468: Attachment: BagAdapter.java Attached a working example of a BagAdapter which provides an adapter of the Bag interface to the newly proposed Multiset interface. The Multiset interface is identical to the Bag interface with the difference that it conforms to the Collection super-interface. Change Bag interface and implementations to conform to Collection interface --- Key: COLLECTIONS-468 URL: https://issues.apache.org/jira/browse/COLLECTIONS-468 Project: Commons Collections Issue Type: Bug Reporter: Thomas Neidhart Fix For: 4.0 Attachments: BagAdapter.java, COLLECTIONS-468.patch Several methods of the Bag interface do not conform to the Collection interface (e.g. add, remove, containsAll, removeAll, retainAll). This should be fixed for 4.0. -- 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
[jira] [Updated] (COLLECTIONS-468) Change Bag interface and implementations to conform to Collection interface
[ https://issues.apache.org/jira/browse/COLLECTIONS-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-468: Attachment: Multiset.java Change Bag interface and implementations to conform to Collection interface --- Key: COLLECTIONS-468 URL: https://issues.apache.org/jira/browse/COLLECTIONS-468 Project: Commons Collections Issue Type: Bug Reporter: Thomas Neidhart Fix For: 4.0 Attachments: BagAdapter.java, COLLECTIONS-468.patch, Multiset.java Several methods of the Bag interface do not conform to the Collection interface (e.g. add, remove, containsAll, removeAll, retainAll). This should be fixed for 4.0. -- 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
[jira] [Resolved] (COLLECTIONS-472) wasted work in AbstractMapBag.containsAll()
[ https://issues.apache.org/jira/browse/COLLECTIONS-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved COLLECTIONS-472. - Resolution: Fixed Fix Version/s: 4.0 Applied in r1491258. Thanks for the patch! wasted work in AbstractMapBag.containsAll() --- Key: COLLECTIONS-472 URL: https://issues.apache.org/jira/browse/COLLECTIONS-472 Project: Commons Collections Issue Type: Bug Components: Bag Affects Versions: 3.2.1 Environment: any Reporter: Adrian Nistor Labels: patch,, performance Fix For: 4.0 Attachments: patch.diff The problem appears in version 3.2.1 and in revision 1489197. I attached a one-line patch that fixes it. In method AbstractMapBag.containsAll, the loop over other.uniqueSet() should return immediately after result becomes false, because result = result contains; can never become true again. All the iterations after result becomes false do not perform any useful work, at best they just set result again to false. -- 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
[jira] [Updated] (CONFIGURATION-546) ClassCastException in BeanHelper constructing beans with a list of child beans
[
https://issues.apache.org/jira/browse/CONFIGURATION-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Couch updated CONFIGURATION-546:
---
Attachment: BeanHelper.java
TestBeanHelper.java
BeanCreationTestBeanWithListChild.java
Tweaked test and example implementation that passes the tests.
ClassCastException in BeanHelper constructing beans with a list of child beans
--
Key: CONFIGURATION-546
URL: https://issues.apache.org/jira/browse/CONFIGURATION-546
Project: Commons Configuration
Issue Type: Bug
Components: Type conversion
Affects Versions: 1.8, 1.9
Reporter: Justin Couch
Priority: Minor
Attachments: BeanCreationTestBeanWithListChild.java,
BeanCreationTestBeanWithListChild.java, BeanHelper.java, TestBeanHelper.java,
TestBeanHelper.java
If you wish to create a bean that has a collection as a property where that
collection contains multiple beans, the code crashes as it assumes that you
can only ever have single bean declarations as children.
For example the following brief construct is not possible to build
class A {
String name;
}
class B {
ListA children;
}
The result is the following stack trace
Caused by: java.lang.ClassCastException: java.util.ArrayList cannot be cast
to org.apache.commons.configuration.beanutils.BeanDeclaration
at
org.apache.commons.configuration.beanutils.BeanHelper.initBean(BeanHelper.java:212)
at
org.apache.commons.configuration.beanutils.TestBeanHelper$TestBeanFactory.createBean(TestBeanHelper.java:579)
at
org.apache.commons.configuration.beanutils.BeanHelper.createBean(BeanHelper.java:342)
... 33 more
It's pretty easy to see why when you look at the code beginning line 208:
for (Map.EntryString, Object e : nestedBeans.entrySet())
{
String propName = e.getKey();
Class? defaultClass = getDefaultClass(bean, propName);
initProperty(bean, propName, createBean(
(BeanDeclaration) e.getValue(), defaultClass));
}
Note the silly assumption that e.getValue() only ever has BeanDeclaration
instances, where it could be BeanDeclaration[], or
CollectionBeanDeclaration as other possible options - which is what the
above example show.
Extended version of the existing unit test to follow that illustrates the
problem.
--
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
