[jira] [Comment Edited] (IO-513) Add convenience methods for reading class path resources
[
https://issues.apache.org/jira/browse/IO-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15490886#comment-15490886
]
Stian Soiland-Reyes edited comment on IO-513 at 9/14/16 4:38 PM:
-
I agree with Gary that there should be variants with the ClassLoader as an
additional parameter, (or even required parameter), use of these functions
will, unlike getResourceAsStream(), lead to errors in environments with
multiple classloaders (e.g. OSGi, or perhaps even within Tomcat), as:
IOUtils.class.getResource(name) will use the classloader of IOUtils, which
might not have access to the classloader that holds the resource you want. It's
all fine if you run on a single classpath (e.g. java -classpath loads:of:stuff)
- but not in anything more complex.
And so a library using IOUtils.resourceTo* methods without providing the
ClassLoader might break by anyone trying to use it in such "enterprise"
environments.
Perhaps using the (a bit slow) Reflection.getCallerClass() is a better default
if no ClassLoader is provided and the resource can't be found? Or what do folks
think - is that too much magic?
Better javadoc might help (if devs read it) - but for sure the variant
providing the ClassLoader.
was (Author: stain):
I agree with Gary that there should be variants with the ClassLoader as an
additional parameter, (or even required parameter), use of these functions
will, unlike getResourceAsStream(), lead to errors in environments with
multiple classloaders (e.g. OSGi, or perhaps even within Tomcat), as:
IOUtils.class.getResource(name) will use the classloader of IOUtils, which
might not have access to the classloader that holds the resource you want. It's
all fine if you run on a single classpath (e.g. java -classpath
loads:of:tsuff).
And so a library using IOUtils.resourceTo* methods without providing the
ClassLoader might break by anyone trying to use it in such "enterprise"
environments.
Perhaps using the (a bit slow) Reflection.getCallerClass() is a better default
if no ClassLoader is provided and the resource can't be found? Or what do folks
think - is that too much magic?
Better javadoc might help (if devs read it) - but for sure the variant
providing the ClassLoader.
> Add convenience methods for reading class path resources
>
>
> Key: IO-513
> URL: https://issues.apache.org/jira/browse/IO-513
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
>Reporter: Behrang Saeedzadeh
>Priority: Minor
> Labels: beginner, features, github-import, newbie
>
> Add convenience methods to {{IOUtils}} for reading class path resources and
> returning them as {{String}}, {{byte[]}}, and {{URL}} respectively.
> Github PR: https://github.com/apache/commons-io/pull/17
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-513) Add convenience methods for reading class path resources
[
https://issues.apache.org/jira/browse/IO-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15490886#comment-15490886
]
Stian Soiland-Reyes commented on IO-513:
I agree with Gary that there should be variants with the ClassLoader as an
additional parameter, (or even required parameter), use of these functions
will, unlike getResourceAsStream(), lead to errors in environments with
multiple classloaders (e.g. OSGi, or perhaps even within Tomcat), as:
IOUtils.class.getResource(name) will use the classloader of IOUtils, which
might not have access to the classloader that holds the resource you want. It's
all fine if you run on a single classpath (e.g. java -classpath
loads:of:tsuff).
And so a library using IOUtils.resourceTo* methods without providing the
ClassLoader might break by anyone trying to use it in such "enterprise"
environments.
Perhaps using the (a bit slow) Reflection.getCallerClass() is a better default
if no ClassLoader is provided and the resource can't be found? Or what do folks
think - is that too much magic?
Better javadoc might help (if devs read it) - but for sure the variant
providing the ClassLoader.
> Add convenience methods for reading class path resources
>
>
> Key: IO-513
> URL: https://issues.apache.org/jira/browse/IO-513
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
>Reporter: Behrang Saeedzadeh
>Priority: Minor
> Labels: beginner, features, github-import, newbie
>
> Add convenience methods to {{IOUtils}} for reading class path resources and
> returning them as {{String}}, {{byte[]}}, and {{URL}} respectively.
> Github PR: https://github.com/apache/commons-io/pull/17
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CODEC-225) InputStream not closed
[ https://issues.apache.org/jira/browse/CODEC-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15490448#comment-15490448 ] ASF GitHub Bot commented on CODEC-225: -- Github user SvetlinZarev closed the pull request at: https://github.com/apache/commons-codec/pull/5 > InputStream not closed > -- > > Key: CODEC-225 > URL: https://issues.apache.org/jira/browse/CODEC-225 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.10, 1.11 >Reporter: Svetlin Zarev >Assignee: Jochen Wiedmann > > After running static code analysis on common codecs we discovered that it > leaks file descriptors. The relevant locations are: > * DaitchMokotoffSoundex -> the static initializer on line 229 > * Rule -> the static initializer on line 212 and the parseRules() method on > line 438. > patch provided via github pull request. > This issue is relevant for web app deployments on OSes (like windows) that > lock the files if ther eare open streams to them, and will prevent > application undeployment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-188) ICNS Image Parser: Support for large Icons (ic07, ic08, ic09, ic10 [128px, 256px, 512px, 1024px])
[
https://issues.apache.org/jira/browse/IMAGING-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Wagner updated IMAGING-188:
-
Issue Type: New Feature (was: Improvement)
> ICNS Image Parser: Support for large Icons (ic07, ic08, ic09, ic10 [128px,
> 256px, 512px, 1024px])
> -
>
> Key: IMAGING-188
> URL: https://issues.apache.org/jira/browse/IMAGING-188
> Project: Commons Imaging
> Issue Type: New Feature
>Affects Versions: 1.0
> Environment: OS X
>Reporter: Marco Wagner
>
> I needed larger icons of icns files, than currently extracted with the Apache
> Commons Imaging ICNS Image Parser/ICNS Decoder.
> So I edited the Source Code:
> In case an icns element is a PNG (depends on 0-4th byte [header]),
> the bytes can be put in a ByteArrayInputStream and then read by ImageIO.read,
> that returns the BufferedImage needed.
> Then it can be added to the list of List in
> IcnsDecoder#decodeAllImages().
> InputStream in = new ByteArrayInputStream(imageData);
> BufferedImage image = ImageIO.read(in);
> To the enum IcnsType I added:
> ICNS_256x256_32BIT_ARGB_IMAGE("ic08", 256, 256, 32, false),
> ICNS_512x512_32BIT_ARGB_IMAGE("ic09", 512, 512, 32, false),
> ICNS_1024x1024_32BIT_ARGB_IMAGE("ic10", 1024, 1024, 32, false);
> https://en.wikipedia.org/wiki/Apple_Icon_Image_format
> No need for Rle24Compression.decompress() or decode32BPPImage().
> I can upload the code somewhere, please tell me how to do.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CODEC-225) InputStream not closed
[ https://issues.apache.org/jira/browse/CODEC-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved CODEC-225. --- Resolution: Fixed Assignee: Jochen Wiedmann Accepting patch, after rework. > InputStream not closed > -- > > Key: CODEC-225 > URL: https://issues.apache.org/jira/browse/CODEC-225 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.10, 1.11 >Reporter: Svetlin Zarev >Assignee: Jochen Wiedmann > > After running static code analysis on common codecs we discovered that it > leaks file descriptors. The relevant locations are: > * DaitchMokotoffSoundex -> the static initializer on line 229 > * Rule -> the static initializer on line 212 and the parseRules() method on > line 438. > patch provided via github pull request. > This issue is relevant for web app deployments on OSes (like windows) that > lock the files if ther eare open streams to them, and will prevent > application undeployment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IMAGING-188) ICNS Image Parser: Support for large Icons (ic07, ic08, ic09, ic10 [128px, 256px, 512px, 1024px])
Marco Wagner created IMAGING-188:
Summary: ICNS Image Parser: Support for large Icons (ic07, ic08,
ic09, ic10 [128px, 256px, 512px, 1024px])
Key: IMAGING-188
URL: https://issues.apache.org/jira/browse/IMAGING-188
Project: Commons Imaging
Issue Type: Improvement
Affects Versions: 1.0
Environment: OS X
Reporter: Marco Wagner
I needed larger icons of icns files, than currently extracted with the Apache
Commons Imaging ICNS Image Parser/ICNS Decoder.
So I edited the Source Code:
In case an icns element is a PNG (depends on 0-4th byte [header]),
the bytes can be put in a ByteArrayInputStream and then read by ImageIO.read,
that returns the BufferedImage needed.
Then it can be added to the list of List in
IcnsDecoder#decodeAllImages().
InputStream in = new ByteArrayInputStream(imageData);
BufferedImage image = ImageIO.read(in);
To the enum IcnsType I added:
ICNS_256x256_32BIT_ARGB_IMAGE("ic08", 256, 256, 32, false),
ICNS_512x512_32BIT_ARGB_IMAGE("ic09", 512, 512, 32, false),
ICNS_1024x1024_32BIT_ARGB_IMAGE("ic10", 1024, 1024, 32, false);
https://en.wikipedia.org/wiki/Apple_Icon_Image_format
No need for Rle24Compression.decompress() or decode32BPPImage().
I can upload the code somewhere, please tell me how to do.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-480) Improved threading performance ContextClassLoaderLocal
[ https://issues.apache.org/jira/browse/BEANUTILS-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15490273#comment-15490273 ] Stian Soiland-Reyes commented on BEANUTILS-480: --- Hi, Saponenko - have you got a chance to try again to make your patch for ContextClassLoaderLocal.java? It might be easier to do it as a GitHub pull request. > Improved threading performance ContextClassLoaderLocal > -- > > Key: BEANUTILS-480 > URL: https://issues.apache.org/jira/browse/BEANUTILS-480 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean / Property Utils >Affects Versions: 1.9.2 >Reporter: Saponenko Denis > Labels: patch, performance > Attachments: ContextClassLoaderLocal.java(2).patch > > > Improved > src/main/java/org/apache/commons/beanutils/ContextClassLoaderLocal.java with > concurrent collections to improve performance in a narrow places synchronized > blocks. Path attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (BEANUTILS-480) Improved threading performance ContextClassLoaderLocal
[ https://issues.apache.org/jira/browse/BEANUTILS-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated BEANUTILS-480: -- Fix Version/s: (was: 1.9.3) > Improved threading performance ContextClassLoaderLocal > -- > > Key: BEANUTILS-480 > URL: https://issues.apache.org/jira/browse/BEANUTILS-480 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean / Property Utils >Affects Versions: 1.9.2 >Reporter: Saponenko Denis > Labels: patch, performance > Attachments: ContextClassLoaderLocal.java(2).patch > > > Improved > src/main/java/org/apache/commons/beanutils/ContextClassLoaderLocal.java with > concurrent collections to improve performance in a narrow places synchronized > blocks. Path attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-187) Could not read block - when JPG file is saved from TIFF
[ https://issues.apache.org/jira/browse/IMAGING-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] R.M. updated IMAGING-187: - Description: I have got error java.io.IOException: Could not read block (block start: 399047, block length: 6240, data length: 9926). when I try to read EXIF or IPTC metadata (Imaging.getMetadata(file);) At first the file was saved in TIFF format. Then it was open and saved to final jpg format. This error I can see everytime, when I have any JPG saved from TIFF. I tried to use PaintShopPro and painting in windows. was: I have got error java.io.IOException: Could not read block (block start: 399047, block length: 6240, data length: 9926). when I try to read EXIF or IPTC metadata (Imaging.getMetadata(file);) At first the file was saved in TIFF format. Then it was open and saved to final jpg format. This error I can see everytime, when I had any JPG saved from TIFF. I tried to use PaintShopPro and painting in windows. > Could not read block - when JPG file is saved from TIFF > --- > > Key: IMAGING-187 > URL: https://issues.apache.org/jira/browse/IMAGING-187 > Project: Commons Imaging > Issue Type: Bug >Affects Versions: 1.0 >Reporter: R.M. > Attachments: IMG_000-tf.jpg > > > I have got error > java.io.IOException: Could not read block (block start: 399047, block length: > 6240, data length: 9926). > when I try to read EXIF or IPTC metadata (Imaging.getMetadata(file);) > At first the file was saved in TIFF format. Then it was open and saved to > final jpg format. This error I can see everytime, when I have any JPG saved > from TIFF. > I tried to use PaintShopPro and painting in windows. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-187) Could not read block - when JPG file is saved from TIFF
[ https://issues.apache.org/jira/browse/IMAGING-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] R.M. updated IMAGING-187: - Attachment: IMG_000-tf.jpg > Could not read block - when JPG file is saved from TIFF > --- > > Key: IMAGING-187 > URL: https://issues.apache.org/jira/browse/IMAGING-187 > Project: Commons Imaging > Issue Type: Bug >Affects Versions: 1.0 >Reporter: R.M. > Attachments: IMG_000-tf.jpg > > > I have got error > java.io.IOException: Could not read block (block start: 399047, block length: > 6240, data length: 9926). > when I try to read EXIF or IPTC metadata (Imaging.getMetadata(file);) > At first the file was saved in TIFF format. Then it was open and saved to > final jpg format. This error I can see everytime, when I had any JPG saved > from TIFF. > I tried to use PaintShopPro and painting in windows. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IMAGING-187) Could not read block - when JPG file is saved from TIFF
R.M. created IMAGING-187: Summary: Could not read block - when JPG file is saved from TIFF Key: IMAGING-187 URL: https://issues.apache.org/jira/browse/IMAGING-187 Project: Commons Imaging Issue Type: Bug Affects Versions: 1.0 Reporter: R.M. I have got error java.io.IOException: Could not read block (block start: 399047, block length: 6240, data length: 9926). when I try to read EXIF or IPTC metadata (Imaging.getMetadata(file);) At first the file was saved in TIFF format. Then it was open and saved to final jpg format. This error I can see everytime, when I had any JPG saved from TIFF. I tried to use PaintShopPro and painting in windows. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (BEANUTILS-491) Tests fail on Oracle and IBM Java 8
[
https://issues.apache.org/jira/browse/BEANUTILS-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes resolved BEANUTILS-491.
---
Resolution: Fixed
Assignee: Stian Soiland-Reyes
> Tests fail on Oracle and IBM Java 8
> ---
>
> Key: BEANUTILS-491
> URL: https://issues.apache.org/jira/browse/BEANUTILS-491
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: Nightly Builds, 1.9.2
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_91, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_91\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: C:\eclipse\IBM\ibm_sdk80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Gary Gregory
>Assignee: Stian Soiland-Reyes
>
> On Oracle Java 8:
> {noformat}
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_91, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_91\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> {noformat}
> I get:
> {noformat}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedPropertyDescriptor:156 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testListIndexedReadMethod:288 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedWriteMethod:302 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListReadMethod:256 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListWriteMethod:274 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> Jira422TestCase.testRootBean:36 expected: but
> was:
> Jira422TestCase.testSecondChildBean:42 expected: but
> was:
> Tests run: 1281, Failures: 10, Errors: 0, Skipped: 0
> {noformat}
> All is well on Oracle Java 7:
> {noformat}
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
> {noformat}
> With IBM Java 8:
> {noformat}
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: C:\eclipse\IBM\ibm_sdk80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> {noformat}
> I also get failures:
> {noformat}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor incompatible with
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
>
[jira] [Resolved] (BEANUTILS-493) Exception when setting indexed properties: "Default conversion to ArrayList failed"
[
https://issues.apache.org/jira/browse/BEANUTILS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes resolved BEANUTILS-493.
---
Resolution: Fixed
> Exception when setting indexed properties: "Default conversion to ArrayList
> failed"
> ---
>
> Key: BEANUTILS-493
> URL: https://issues.apache.org/jira/browse/BEANUTILS-493
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils, DynaBean
>Affects Versions: 1.9.2, 1.9.3
> Environment: commons-beanutils-1.9.3-20160606.150953-11
> jdk1.8.0_92
>Reporter: Bernhard Seebass
>Priority: Blocker
> Labels: regression
> Fix For: 1.9.3
>
> Attachments: BeanUtilsBean.java.patch, BeanUtilsBeanTest.java
>
>
> An exception is thrown when adding indexed properties to a DynaBean. This
> worked perfectly with Version 1.8.3
> org.apache.commons.beanutils.ConversionException: Default conversion to
> ArrayList failed.
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleMissing(AbstractConverter.java:314)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleError(AbstractConverter.java:269)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.convert(AbstractConverter.java:177)
> at
> org.apache.commons.beanutils.converters.ConverterFacade.convert(ConverterFacade.java:61)
> at
> org.apache.commons.beanutils.ConvertUtilsBean.convert(ConvertUtilsBean.java:491)
> at
> org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:1004)
> at BeanUtilsBeanTestApp.main(BeanUtilsBeanTestApp.java:11)
> Caused by: org.apache.commons.beanutils.ConversionException: Can't convert
> value '' to type class java.util.ArrayList
> at
> org.apache.commons.beanutils.converters.AbstractConverter.conversionException(AbstractConverter.java:474)
> at
> org.apache.commons.beanutils.converters.StringConverter.convertToType(StringConverter.java:96)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleMissing(AbstractConverter.java:312)
> ... 6 more
> Test Class:
> import org.apache.commons.beanutils.BeanUtilsBean;
> import org.apache.commons.beanutils.LazyDynaBean;
> public class BeanUtilsBeanTestApp {
>
> public static void main(String[] args) {
> try {
> LazyDynaBean lazyDynaBean = new LazyDynaBean();
> BeanUtilsBean beanUtilsBean =
> BeanUtilsBean.getInstance();
> beanUtilsBean.setProperty(lazyDynaBean, "x[0]", "x1");
> beanUtilsBean.setProperty(lazyDynaBean, "x[1]", "x2");
> System.out.println(lazyDynaBean.get("x")); // output
> using commons-beanutils 1.8.3: [x1, x2]
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-493) Exception when setting indexed properties: "Default conversion to ArrayList failed"
[
https://issues.apache.org/jira/browse/BEANUTILS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15490250#comment-15490250
]
Stian Soiland-Reyes commented on BEANUTILS-493:
---
Thanks!
I've included it in the upcoming 1.9.3 RC2.
> Exception when setting indexed properties: "Default conversion to ArrayList
> failed"
> ---
>
> Key: BEANUTILS-493
> URL: https://issues.apache.org/jira/browse/BEANUTILS-493
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils, DynaBean
>Affects Versions: 1.9.2, 1.9.3
> Environment: commons-beanutils-1.9.3-20160606.150953-11
> jdk1.8.0_92
>Reporter: Bernhard Seebass
>Priority: Blocker
> Labels: regression
> Fix For: 1.9.3
>
> Attachments: BeanUtilsBean.java.patch, BeanUtilsBeanTest.java
>
>
> An exception is thrown when adding indexed properties to a DynaBean. This
> worked perfectly with Version 1.8.3
> org.apache.commons.beanutils.ConversionException: Default conversion to
> ArrayList failed.
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleMissing(AbstractConverter.java:314)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleError(AbstractConverter.java:269)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.convert(AbstractConverter.java:177)
> at
> org.apache.commons.beanutils.converters.ConverterFacade.convert(ConverterFacade.java:61)
> at
> org.apache.commons.beanutils.ConvertUtilsBean.convert(ConvertUtilsBean.java:491)
> at
> org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:1004)
> at BeanUtilsBeanTestApp.main(BeanUtilsBeanTestApp.java:11)
> Caused by: org.apache.commons.beanutils.ConversionException: Can't convert
> value '' to type class java.util.ArrayList
> at
> org.apache.commons.beanutils.converters.AbstractConverter.conversionException(AbstractConverter.java:474)
> at
> org.apache.commons.beanutils.converters.StringConverter.convertToType(StringConverter.java:96)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleMissing(AbstractConverter.java:312)
> ... 6 more
> Test Class:
> import org.apache.commons.beanutils.BeanUtilsBean;
> import org.apache.commons.beanutils.LazyDynaBean;
> public class BeanUtilsBeanTestApp {
>
> public static void main(String[] args) {
> try {
> LazyDynaBean lazyDynaBean = new LazyDynaBean();
> BeanUtilsBean beanUtilsBean =
> BeanUtilsBean.getInstance();
> beanUtilsBean.setProperty(lazyDynaBean, "x[0]", "x1");
> beanUtilsBean.setProperty(lazyDynaBean, "x[1]", "x2");
> System.out.println(lazyDynaBean.get("x")); // output
> using commons-beanutils 1.8.3: [x1, x2]
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (BEANUTILS-493) Exception when setting indexed properties: "Default conversion to ArrayList failed"
[
https://issues.apache.org/jira/browse/BEANUTILS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated BEANUTILS-493:
--
Fix Version/s: 1.9.3
> Exception when setting indexed properties: "Default conversion to ArrayList
> failed"
> ---
>
> Key: BEANUTILS-493
> URL: https://issues.apache.org/jira/browse/BEANUTILS-493
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils, DynaBean
>Affects Versions: 1.9.2, 1.9.3
> Environment: commons-beanutils-1.9.3-20160606.150953-11
> jdk1.8.0_92
>Reporter: Bernhard Seebass
>Priority: Blocker
> Labels: regression
> Fix For: 1.9.3
>
> Attachments: BeanUtilsBean.java.patch, BeanUtilsBeanTest.java
>
>
> An exception is thrown when adding indexed properties to a DynaBean. This
> worked perfectly with Version 1.8.3
> org.apache.commons.beanutils.ConversionException: Default conversion to
> ArrayList failed.
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleMissing(AbstractConverter.java:314)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleError(AbstractConverter.java:269)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.convert(AbstractConverter.java:177)
> at
> org.apache.commons.beanutils.converters.ConverterFacade.convert(ConverterFacade.java:61)
> at
> org.apache.commons.beanutils.ConvertUtilsBean.convert(ConvertUtilsBean.java:491)
> at
> org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:1004)
> at BeanUtilsBeanTestApp.main(BeanUtilsBeanTestApp.java:11)
> Caused by: org.apache.commons.beanutils.ConversionException: Can't convert
> value '' to type class java.util.ArrayList
> at
> org.apache.commons.beanutils.converters.AbstractConverter.conversionException(AbstractConverter.java:474)
> at
> org.apache.commons.beanutils.converters.StringConverter.convertToType(StringConverter.java:96)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleMissing(AbstractConverter.java:312)
> ... 6 more
> Test Class:
> import org.apache.commons.beanutils.BeanUtilsBean;
> import org.apache.commons.beanutils.LazyDynaBean;
> public class BeanUtilsBeanTestApp {
>
> public static void main(String[] args) {
> try {
> LazyDynaBean lazyDynaBean = new LazyDynaBean();
> BeanUtilsBean beanUtilsBean =
> BeanUtilsBean.getInstance();
> beanUtilsBean.setProperty(lazyDynaBean, "x[0]", "x1");
> beanUtilsBean.setProperty(lazyDynaBean, "x[1]", "x2");
> System.out.println(lazyDynaBean.get("x")); // output
> using commons-beanutils 1.8.3: [x1, x2]
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] commons-lang issue #189: new impl of LevenshteinDistance
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/189 Though I also agree with @britter that some better description would help reviewing it :-) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #189: new impl of LevenshteinDistance
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/189 I think string distances were the one of the first things we thought about moving to [text]. Might be interesting to discuss implementing - if it makes sense - this change there. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (LANG-1266) Add alphabet converter
[
https://issues.apache.org/jira/browse/LANG-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-1266:
--
Fix Version/s: Discussion
> Add alphabet converter
> --
>
> Key: LANG-1266
> URL: https://issues.apache.org/jira/browse/LANG-1266
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.text.*
>Reporter: Eyal Allweil
> Fix For: Discussion
>
>
> (as described in [the mailing
> list|http://mail-archives.apache.org/mod_mbox/commons-dev/201609.mbox/%3c289983494.3057706.1472720010...@mail.yahoo.com%3e])
> This is a utility class I wrote for converting from one alphabet to another -
> for example, from unicode to latin, without using some of the chars in latin.
> The usage looks like this:
> {code}
> Set originals; // a, b, c, d
> Set encoding; // 0, 1, d
> Set doNotEncode; // d
> AlphabetConverter ac = AlphabetConverter.createConverter(originals, encoding,
> doNotEncode);
> ac.encode("a"); // 00
> ac.encode("b"); // 01
> ac.encode("c"); // 0d
> ac.encode("d"); // d
> ac.encode("abcd"); // 00010dd
> {code}
> Of course, x.equals(ac.decode(ac.encode(x))) should always be true.
> The implementation provided makes the encodings of fixed length, other than
> the "do not encode" chars, which remain as they are (length one).
> In addition, in order to make it easier to preserve the encoding scheme, I've
> added a human-readable toString implementation, and a constructor that can
> recreate an AlphabetConverter from the encoding map, such that:
> {code}
> AlphabetConverter ac;
> ac.equals(AlphabetConverter.createConverterFromMap(ac.getOriginalToEncoded()));
> // always should be true
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1266) Add alphabet converter
[
https://issues.apache.org/jira/browse/LANG-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15489739#comment-15489739
]
Benedikt Ritter commented on LANG-1266:
---
See my comment on the mailing list. I think this belongs into Commons Text and
not into Commons Lang.
> Add alphabet converter
> --
>
> Key: LANG-1266
> URL: https://issues.apache.org/jira/browse/LANG-1266
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.text.*
>Reporter: Eyal Allweil
> Fix For: Discussion
>
>
> (as described in [the mailing
> list|http://mail-archives.apache.org/mod_mbox/commons-dev/201609.mbox/%3c289983494.3057706.1472720010...@mail.yahoo.com%3e])
> This is a utility class I wrote for converting from one alphabet to another -
> for example, from unicode to latin, without using some of the chars in latin.
> The usage looks like this:
> {code}
> Set originals; // a, b, c, d
> Set encoding; // 0, 1, d
> Set doNotEncode; // d
> AlphabetConverter ac = AlphabetConverter.createConverter(originals, encoding,
> doNotEncode);
> ac.encode("a"); // 00
> ac.encode("b"); // 01
> ac.encode("c"); // 0d
> ac.encode("d"); // d
> ac.encode("abcd"); // 00010dd
> {code}
> Of course, x.equals(ac.decode(ac.encode(x))) should always be true.
> The implementation provided makes the encodings of fixed length, other than
> the "do not encode" chars, which remain as they are (length one).
> In addition, in order to make it easier to preserve the encoding scheme, I've
> added a human-readable toString implementation, and a constructor that can
> recreate an AlphabetConverter from the encoding map, such that:
> {code}
> AlphabetConverter ac;
> ac.equals(AlphabetConverter.createConverterFromMap(ac.getOriginalToEncoded()));
> // always should be true
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] commons-lang issue #189: new impl of LevenshteinDistance
Github user britter commented on the issue: https://github.com/apache/commons-lang/pull/189 Hello @yufcuy, can you provide more information as to why you think this change is necessary? Does it improve performance properties? Do you have benchmarked the new implementation against the old implementation? Regards, Benedikt --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
