[jira] [Resolved] (COLLECTIONS-565) Add support for NavigableSet interface
[ https://issues.apache.org/jira/browse/COLLECTIONS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved COLLECTIONS-565. - Resolution: Fixed Fix Version/s: 4.1 Resolve for 4.1, NavigableMap decorators can be added later. > Add support for NavigableSet interface > -- > > Key: COLLECTIONS-565 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-565 > Project: Commons Collections > Issue Type: New Feature >Reporter: Thomas Neidhart > Fix For: 4.1 > > > As we moved on to Java 6 we can now add appropriate decorators for > NavigableMap and NavigableSet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COLLECTIONS-565) Add support for NavigableSet interface
[ https://issues.apache.org/jira/browse/COLLECTIONS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-565: Summary: Add support for NavigableSet interface (was: Add support for Navigable[Map, Set] interface) > Add support for NavigableSet interface > -- > > Key: COLLECTIONS-565 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-565 > Project: Commons Collections > Issue Type: New Feature >Reporter: Thomas Neidhart > > As we moved on to Java 6 we can now add appropriate decorators for > NavigableMap and NavigableSet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COLLECTIONS-567) Add a MultiSet interface / implementations that do not violate the Collection contract
[ https://issues.apache.org/jira/browse/COLLECTIONS-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved COLLECTIONS-567. - Resolution: Fixed Resolve this issue for 4.1, additional implementations can be added later. > Add a MultiSet interface / implementations that do not violate the Collection > contract > -- > > Key: COLLECTIONS-567 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-567 > Project: Commons Collections > Issue Type: New Feature >Affects Versions: 4.0 >Reporter: Thomas Neidhart > Fix For: 4.1 > > > Prior to the release of 4.0 there was a discussion about to change the Bag > interface to make it compliant with the Collection contract. > The outcome was that the Bag interface should be kept as is to simplify > migration of older code-bases. > Now, it would make sense to add a MultiSet interface that is basically > similar to a Bag, but does comply to the Collection contract. The old Bag > could then be deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-567) Add a MultiSet interface / implementations that do not violate the Collection contract
[ https://issues.apache.org/jira/browse/COLLECTIONS-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15005921#comment-15005921 ] Thomas Neidhart commented on COLLECTIONS-567: - Added tests in r1714462. > Add a MultiSet interface / implementations that do not violate the Collection > contract > -- > > Key: COLLECTIONS-567 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-567 > Project: Commons Collections > Issue Type: New Feature >Affects Versions: 4.0 >Reporter: Thomas Neidhart > Fix For: 4.1 > > > Prior to the release of 4.0 there was a discussion about to change the Bag > interface to make it compliant with the Collection contract. > The outcome was that the Bag interface should be kept as is to simplify > migration of older code-bases. > Now, it would make sense to add a MultiSet interface that is basically > similar to a Bag, but does comply to the Collection contract. The old Bag > could then be deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-551) Move Iterable related methods from CollectionUtils to IterableUtils
[ https://issues.apache.org/jira/browse/COLLECTIONS-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15005927#comment-15005927 ] Thomas Neidhart commented on COLLECTIONS-551: - Deprecation completed for 4.1. More changes can be made in later releases if needed. > Move Iterable related methods from CollectionUtils to IterableUtils > --- > > Key: COLLECTIONS-551 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-551 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: Thomas Neidhart > Fix For: 4.1, 5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart updated COLLECTIONS-580:
Fix Version/s: 4.1
3.2.2
> Arbitrary remote code execution with InvokerTransformer
> ---
>
> Key: COLLECTIONS-580
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-580
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.0, 4.0
>Reporter: Philippe Marschall
> Fix For: 3.2.2, 4.1
>
> Attachments: COLLECTIONS-580.patch
>
>
> With {{InvokerTransformer}} serializable collections can be build that
> execute arbitrary Java code.
> {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes
> {{#entrySet}} and {{#get}} on a deserialized collection. If you have an
> endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you
> can combine the two to create arbitrary remote code execution vulnerability.
> I don't know of a good fix short of removing {{InvokerTransformer}} or making
> it not Serializable. Both probably break existing applications.
> This is not my research, but has been discovered by other people.
> https://github.com/frohoff/ysoserial
> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COLLECTIONS-567) Add a MultiSet interface / implementations that do not violate the Collection contract
[ https://issues.apache.org/jira/browse/COLLECTIONS-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-567: Fix Version/s: 4.1 > Add a MultiSet interface / implementations that do not violate the Collection > contract > -- > > Key: COLLECTIONS-567 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-567 > Project: Commons Collections > Issue Type: New Feature >Affects Versions: 4.0 >Reporter: Thomas Neidhart > Fix For: 4.1 > > > Prior to the release of 4.0 there was a discussion about to change the Bag > interface to make it compliant with the Collection contract. > The outcome was that the Bag interface should be kept as is to simplify > migration of older code-bases. > Now, it would make sense to add a MultiSet interface that is basically > similar to a Bag, but does comply to the Collection contract. The old Bag > could then be deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COLLECTIONS-517) [Collection|List]Utils.[intersection|union] should accept vararg parameters
[ https://issues.apache.org/jira/browse/COLLECTIONS-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-517: Fix Version/s: (was: 4.1) 4.x > [Collection|List]Utils.[intersection|union] should accept vararg parameters > --- > > Key: COLLECTIONS-517 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-517 > Project: Commons Collections > Issue Type: Improvement > Components: Collection, List >Affects Versions: 4.0 >Reporter: Hollis Waite >Priority: Minor > Fix For: 4.x > > Attachments: COLLECTIONS-517.patch > > > Would be convenient if intersection/union methods accepted arbitrary number > of arguments. Two-arg methods could be retained in order to avoid compiler > warnings > (https://issues.apache.org/jira/browse/COLLECTIONS-481?focusedCommentId=13762173=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13762173). > Alternatively, method could be overloaded to accept a single Iterable of > Lists/Sets. I could create a patch for this if it's deemed worthwhile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006005#comment-15006005 ] Kristian Rosenvold commented on IO-487: --- IntersectionClassAcceptor: Does a "Set" of acceptors make any sense when the ClassAcceptors dont implement equals/hashcode ? I'm wondering if this should really be moved to the "org.apache.commons.io.input" package, possibly with the acceptors in a sub-package ? (I'm discussing this with myself kind-of. But I think so) > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487-2.patch, IO-487-name-regex-acceptor.patch, > IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch, > IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MATH-1289) Incorrect calculation in org.apache.commons.math3.complex.Complex#multiply
[
https://issues.apache.org/jira/browse/MATH-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15005989#comment-15005989
]
Luc Maisonobe edited comment on MATH-1289 at 11/15/15 6:43 PM:
---
The expressions used in the library are correct.
With your expressions, computing I^2 would give +1 instead of -1. and
multiplication would not be commutative (for example I * 1 would be the
opposite of 1 * I).
Remember that in the complex class, the imaginary field is a *real* value
holding the multiplicative factor to be applied to I (the square root of -1).
In other words z = real + I * imaginary.
So
{noformat}
z1 * z2 = (r1 + I * i1) * (r2 + I * i2)
= (r1 * r2 + I * r1 * i2 + I * i1 * r2 + I * I * i1 * i2)
= (r1 * r2 + I * I * i1 * i2) + I * (r1 * i2 + i1 * r2)
= (r1 * r2 - i1 * i2) + I * (r1 * i2 + i1 * r2)
{noformat}
which is exactly the expression in the library.
was (Author: luc):
The expressions used in the library are correct.
With your expressions, computing I^2 would give +1 instead of -1. and
multiplication would not be commutative (for example I * 1 would be the
opposite of 1 * I).
Remember that in the complex class, the imaginary field is a *real* value
holding the multiplicative factor to be applied to I (the square root of -1).
In other words z = real + I * imaginary.
So
{noformat}
z1 * z2 = (r1 + I * i1) * (r2 + I * i2)
= (r1 * r2 + I * r1 * i2 + I * i1 * r2 + I * I * i1 * i2)
= (r1 * r2 + I * I * i1 * i1) + I * (r1 * i2 + i1 * r2)
= (r1 * r2 - i1 * i2) + I * (r1 * i2 + i1 * r2)
{noformat}
which is exactly the expression in the library.
> Incorrect calculation in org.apache.commons.math3.complex.Complex#multiply
> --
>
> Key: MATH-1289
> URL: https://issues.apache.org/jira/browse/MATH-1289
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.5
> Environment: Linux 3.16.0-44-generic #59-Ubuntu SMP Tue Jul 7
> 02:07:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
>Reporter: Detaille Octave
> Labels: easyfix
>
> Hello guys!
> If think there is a bug in the
> org.apache.commons.math3.complex.Complex#multiply method
> Line 536 & 537 below are not correct
> {code:title=Complex.java|borderStyle=solid}
> return createComplex(real * factor.real - imaginary * factor.imaginary, real
> * factor.imaginary + imaginary * factor.real);
> {code}
> It should be
> {code:title=Complex.java|borderStyle=solid}
> return createComplex(real * factor.real + imaginary * factor.imaginary,
> imaginary * factor.real-real * factor.imaginary);
> {code}
> Can you confirm that? Or do I miss something?
> Thanks a lot (also, for this excellent library).
> Best,
> Octave
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SANDBOX-501) Add configurable type conversion support
[ https://issues.apache.org/jira/browse/SANDBOX-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew P Mann updated SANDBOX-501: --- Attachment: commons-beanutils2.2015-11-15.patch ... and more tinkering. > Add configurable type conversion support > > > Key: SANDBOX-501 > URL: https://issues.apache.org/jira/browse/SANDBOX-501 > Project: Commons Sandbox > Issue Type: New Feature > Components: BeanUtils2 >Reporter: Benedikt Ritter > Attachments: commons-beanutils2.2015-11-13.patch, > commons-beanutils2.2015-11-14.patch, commons-beanutils2.2015-11-15.patch, > commons-beanutils2.java8.patch > > > BeanUtils1 supports automatic type conversion when setting properties. This > should be added to BeanUtils2. > A problem of the implementation of BeanUtils1 is, that the registry of > converts is cached in the BeanUtils class. BeanUtils2 should provide an API > for creating new instances of the o.a.c.beanutils2.BeanUtils with a > customized typ conversion registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SANDBOX-501) Add configurable type conversion support
[ https://issues.apache.org/jira/browse/SANDBOX-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006027#comment-15006027 ] Matthew P Mann edited comment on SANDBOX-501 at 11/15/15 8:59 PM: -- ... and more tinkering. See [attached patch|https://issues.apache.org/jira/secure/attachment/12772417/commons-beanutils2.2015-11-15.patch]. was (Author: mattmann): ... and more tinkering. > Add configurable type conversion support > > > Key: SANDBOX-501 > URL: https://issues.apache.org/jira/browse/SANDBOX-501 > Project: Commons Sandbox > Issue Type: New Feature > Components: BeanUtils2 >Reporter: Benedikt Ritter > Attachments: commons-beanutils2.2015-11-13.patch, > commons-beanutils2.2015-11-14.patch, commons-beanutils2.2015-11-15.patch, > commons-beanutils2.java8.patch > > > BeanUtils1 supports automatic type conversion when setting properties. This > should be added to BeanUtils2. > A problem of the implementation of BeanUtils1 is, that the registry of > converts is cached in the BeanUtils class. BeanUtils2 should provide an API > for creating new instances of the o.a.c.beanutils2.BeanUtils with a > customized typ conversion registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SANDBOX-501) Add configurable type conversion support
[
https://issues.apache.org/jira/browse/SANDBOX-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006027#comment-15006027
]
Matthew P Mann edited comment on SANDBOX-501 at 11/15/15 9:01 PM:
--
... and more tinkering. See [attached
patch|https://issues.apache.org/jira/secure/attachment/12772417/commons-beanutils2.2015-11-15.patch].
{code}
package org.apache.commons.beanutils2.converters;
import java.lang.reflect.Method;
import java.math.BigDecimal;
import java.math.BigInteger;
import java.util.Arrays;
import org.apache.commons.beanutils2.Address;
import org.apache.commons.beanutils2.ConverterRegistry;
import org.apache.commons.beanutils2.State;
import org.junit.Before;
import org.junit.Test;
import org.mockito.invocation.InvocationOnMock;
import org.mockito.stubbing.Answer;
import static java.lang.String.format;
import static org.apache.commons.beanutils2.utils.StringUtils.length;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertNull;
import static org.junit.Assert.assertTrue;
public class StringToArrayTest {
private StringToArray converter;
private ConverterRegistry converterRegistry;
@Before
public void setUp() {
converter = new StringToArray();
converterRegistry = new ConverterRegistry()
.register(converter)
.register(new JsonNumberConverter())
.register(new JsonStringConverter())
.register(new JsonArrayToArray())
.register(BigDecimal::toBigIntegerExact)
.register(Address::parse)
.register(FunctionConverter.from(BigDecimal.class).to(double.class).using(BigDecimal::doubleValue))
.register(FunctionConverter.from(BigDecimal.class).to(int.class).using(BigDecimal::intValueExact))
.register(FunctionConverter.from(String.class).to(BigDecimal.class).using(BigDecimal::new))
.register(FunctionConverter.from(String.class).to(char.class).using(string -> {
if (length(string) != 1) {
throw new
IllegalArgumentException(string);
}
return string.charAt(0);
}));
}
@Test
public void convert_StringToAddressArray() {
final String source = "[ \"1600 Pennsylvania Avenue Northwest,
Washington, DC 20500\", \"11 Wall Street, New York, NY 10005, US\", \"350
Fifth Avenue, New York, NY 10118\", \"4059 Mt Lee Drive, Hollywood, CA
90068\"]";
assertTrue(converter.canConvert(String.class, Address[].class));
final Address[] addresses = converter.convert(source,
Address[].class, converterRegistry);
assertEquals(4, addresses.length);
assertEquals("1600 Pennsylvania Avenue Northwest",
addresses[0].getStreetAddress());
assertEquals("Washington", addresses[0].getCity());
assertEquals(State.DC, addresses[0].getStateCode());
assertEquals("20500", addresses[0].getPostalCode());
assertNull(addresses[0].getCountryCode());
assertEquals("11 Wall Street", addresses[1].getStreetAddress());
assertEquals("New York", addresses[1].getCity());
assertEquals(State.NY, addresses[1].getStateCode());
assertEquals("10005", addresses[1].getPostalCode());
assertEquals("US", addresses[1].getCountryCode());
assertEquals("350 Fifth Avenue",
addresses[2].getStreetAddress());
assertEquals("New York", addresses[2].getCity());
assertEquals(State.NY, addresses[2].getStateCode());
assertEquals("10118", addresses[2].getPostalCode());
assertNull(addresses[2].getCountryCode());
assertEquals("4059 Mt Lee Drive",
addresses[3].getStreetAddress());
assertEquals("Hollywood", addresses[3].getCity());
assertEquals(State.CA, addresses[3].getStateCode());
assertEquals("90068", addresses[3].getPostalCode());
assertNull(addresses[3].getCountryCode());
}
@Test
public void convert_StringToNumberArray() {
final BigDecimal a =
BigDecimal.valueOf(Double.MAX_VALUE).pow(2);
final BigInteger b = BigInteger.valueOf(Long.MAX_VALUE).pow(2);
final int c = Integer.MAX_VALUE;
final long d = Long.MAX_VALUE;
final double e = Double.MAX_VALUE;
final float f = Float.MAX_VALUE;
final String source =
[jira] [Comment Edited] (SANDBOX-501) Add configurable type conversion support
[
https://issues.apache.org/jira/browse/SANDBOX-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006027#comment-15006027
]
Matthew P Mann edited comment on SANDBOX-501 at 11/15/15 9:03 PM:
--
... and more tinkering. See [attached
patch|https://issues.apache.org/jira/secure/attachment/12772417/commons-beanutils2.2015-11-15.patch].
{code}
public class StringToArrayTest {
private StringToArray converter;
private ConverterRegistry converterRegistry;
@Before
public void setUp() {
converter = new StringToArray();
converterRegistry = new ConverterRegistry()
.register(converter)
.register(new JsonNumberConverter())
.register(new JsonStringConverter())
.register(new JsonArrayToArray())
.register(BigDecimal::toBigIntegerExact)
.register(Address::parse)
.register(FunctionConverter.from(BigDecimal.class).to(double.class).using(BigDecimal::doubleValue))
.register(FunctionConverter.from(BigDecimal.class).to(int.class).using(BigDecimal::intValueExact))
.register(FunctionConverter.from(String.class).to(BigDecimal.class).using(BigDecimal::new))
.register(FunctionConverter.from(String.class).to(char.class).using(string -> {
if (length(string) != 1) {
throw new
IllegalArgumentException(string);
}
return string.charAt(0);
}));
}
@Test
public void convert_StringToAddressArray() {
final String source = "[ \"1600 Pennsylvania Avenue Northwest,
Washington, DC 20500\", \"11 Wall Street, New York, NY 10005, US\", \"350
Fifth Avenue, New York, NY 10118\", \"4059 Mt Lee Drive, Hollywood, CA
90068\"]";
assertTrue(converter.canConvert(String.class, Address[].class));
final Address[] addresses = converter.convert(source,
Address[].class, converterRegistry);
assertEquals(4, addresses.length);
assertEquals("1600 Pennsylvania Avenue Northwest",
addresses[0].getStreetAddress());
assertEquals("Washington", addresses[0].getCity());
assertEquals(State.DC, addresses[0].getStateCode());
assertEquals("20500", addresses[0].getPostalCode());
assertNull(addresses[0].getCountryCode());
assertEquals("11 Wall Street", addresses[1].getStreetAddress());
assertEquals("New York", addresses[1].getCity());
assertEquals(State.NY, addresses[1].getStateCode());
assertEquals("10005", addresses[1].getPostalCode());
assertEquals("US", addresses[1].getCountryCode());
assertEquals("350 Fifth Avenue",
addresses[2].getStreetAddress());
assertEquals("New York", addresses[2].getCity());
assertEquals(State.NY, addresses[2].getStateCode());
assertEquals("10118", addresses[2].getPostalCode());
assertNull(addresses[2].getCountryCode());
assertEquals("4059 Mt Lee Drive",
addresses[3].getStreetAddress());
assertEquals("Hollywood", addresses[3].getCity());
assertEquals(State.CA, addresses[3].getStateCode());
assertEquals("90068", addresses[3].getPostalCode());
assertNull(addresses[3].getCountryCode());
}
...
}
{code}
was (Author: mattmann):
... and more tinkering. See [attached
patch|https://issues.apache.org/jira/secure/attachment/12772417/commons-beanutils2.2015-11-15.patch].
{code}
public class StringToArrayTest {
private StringToArray converter;
private ConverterRegistry converterRegistry;
@Before
public void setUp() {
converter = new StringToArray();
converterRegistry = new ConverterRegistry()
.register(converter)
.register(new JsonNumberConverter())
.register(new JsonStringConverter())
.register(new JsonArrayToArray())
.register(BigDecimal::toBigIntegerExact)
.register(Address::parse)
.register(FunctionConverter.from(BigDecimal.class).to(double.class).using(BigDecimal::doubleValue))
.register(FunctionConverter.from(BigDecimal.class).to(int.class).using(BigDecimal::intValueExact))
.register(FunctionConverter.from(String.class).to(BigDecimal.class).using(BigDecimal::new))
[jira] [Comment Edited] (SANDBOX-501) Add configurable type conversion support
[
https://issues.apache.org/jira/browse/SANDBOX-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006027#comment-15006027
]
Matthew P Mann edited comment on SANDBOX-501 at 11/15/15 9:03 PM:
--
... and more tinkering. See [attached
patch|https://issues.apache.org/jira/secure/attachment/12772417/commons-beanutils2.2015-11-15.patch].
{code}
public class StringToArrayTest {
private StringToArray converter;
private ConverterRegistry converterRegistry;
@Before
public void setUp() {
converter = new StringToArray();
converterRegistry = new ConverterRegistry()
.register(converter)
.register(new JsonNumberConverter())
.register(new JsonStringConverter())
.register(new JsonArrayToArray())
.register(BigDecimal::toBigIntegerExact)
.register(Address::parse)
.register(FunctionConverter.from(BigDecimal.class).to(double.class).using(BigDecimal::doubleValue))
.register(FunctionConverter.from(BigDecimal.class).to(int.class).using(BigDecimal::intValueExact))
.register(FunctionConverter.from(String.class).to(BigDecimal.class).using(BigDecimal::new))
.register(FunctionConverter.from(String.class).to(char.class).using(string -> {
if (length(string) != 1) {
throw new
IllegalArgumentException(string);
}
return string.charAt(0);
}));
}
@Test
public void convert_StringToAddressArray() {
final String source = "[ \"1600 Pennsylvania Avenue Northwest,
Washington, DC 20500\", \"11 Wall Street, New York, NY 10005, US\", \"350
Fifth Avenue, New York, NY 10118\", \"4059 Mt Lee Drive, Hollywood, CA
90068\"]";
assertTrue(converter.canConvert(String.class, Address[].class));
final Address[] addresses = converter.convert(source,
Address[].class, converterRegistry);
assertEquals(4, addresses.length);
assertEquals("1600 Pennsylvania Avenue Northwest",
addresses[0].getStreetAddress());
assertEquals("Washington", addresses[0].getCity());
assertEquals(State.DC, addresses[0].getStateCode());
assertEquals("20500", addresses[0].getPostalCode());
assertNull(addresses[0].getCountryCode());
assertEquals("11 Wall Street", addresses[1].getStreetAddress());
assertEquals("New York", addresses[1].getCity());
assertEquals(State.NY, addresses[1].getStateCode());
assertEquals("10005", addresses[1].getPostalCode());
assertEquals("US", addresses[1].getCountryCode());
assertEquals("350 Fifth Avenue",
addresses[2].getStreetAddress());
assertEquals("New York", addresses[2].getCity());
assertEquals(State.NY, addresses[2].getStateCode());
assertEquals("10118", addresses[2].getPostalCode());
assertNull(addresses[2].getCountryCode());
assertEquals("4059 Mt Lee Drive",
addresses[3].getStreetAddress());
assertEquals("Hollywood", addresses[3].getCity());
assertEquals(State.CA, addresses[3].getStateCode());
assertEquals("90068", addresses[3].getPostalCode());
assertNull(addresses[3].getCountryCode());
}
...
}
{code}
was (Author: mattmann):
... and more tinkering. See [attached
patch|https://issues.apache.org/jira/secure/attachment/12772417/commons-beanutils2.2015-11-15.patch].
{code}
package org.apache.commons.beanutils2.converters;
import java.lang.reflect.Method;
import java.math.BigDecimal;
import java.math.BigInteger;
import java.util.Arrays;
import org.apache.commons.beanutils2.Address;
import org.apache.commons.beanutils2.ConverterRegistry;
import org.apache.commons.beanutils2.State;
import org.junit.Before;
import org.junit.Test;
import org.mockito.invocation.InvocationOnMock;
import org.mockito.stubbing.Answer;
import static java.lang.String.format;
import static org.apache.commons.beanutils2.utils.StringUtils.length;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertNull;
import static org.junit.Assert.assertTrue;
public class StringToArrayTest {
private StringToArray converter;
private ConverterRegistry converterRegistry;
@Before
public void setUp() {
converter = new StringToArray();
converterRegistry = new ConverterRegistry()
[jira] [Comment Edited] (SANDBOX-501) Add configurable type conversion support
[
https://issues.apache.org/jira/browse/SANDBOX-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006027#comment-15006027
]
Matthew P Mann edited comment on SANDBOX-501 at 11/15/15 9:04 PM:
--
... and more tinkering. See [attached
patch|https://issues.apache.org/jira/secure/attachment/12772417/commons-beanutils2.2015-11-15.patch].
{code}
public class StringToArrayTest {
private StringToArray converter;
private ConverterRegistry converterRegistry;
@Before
public void setUp() {
converter = new StringToArray();
converterRegistry = new ConverterRegistry()
.register(converter)
.register(new JsonNumberConverter())
.register(new JsonStringConverter())
.register(new JsonArrayToArray())
.register(BigDecimal::toBigIntegerExact)
.register(Address::parse)
.register(FunctionConverter.from(BigDecimal.class).to(double.class).using(BigDecimal::doubleValue))
.register(FunctionConverter.from(BigDecimal.class).to(int.class).using(BigDecimal::intValueExact))
.register(FunctionConverter.from(String.class).to(BigDecimal.class).using(BigDecimal::new))
.register(FunctionConverter.from(String.class).to(char.class).using(string -> {
if (length(string) != 1) {
throw new IllegalArgumentException(string);
}
return string.charAt(0);
}));
}
@Test
public void convert_StringToAddressArray() {
final String source = "[ \"1600 Pennsylvania Avenue Northwest,
Washington, DC 20500\", \"11 Wall Street, New York, NY 10005, US\", \"350
Fifth Avenue, New York, NY 10118\", \"4059 Mt Lee Drive, Hollywood, CA
90068\"]";
assertTrue(converter.canConvert(String.class, Address[].class));
final Address[] addresses = converter.convert(source, Address[].class,
converterRegistry);
assertEquals(4, addresses.length);
assertEquals("1600 Pennsylvania Avenue Northwest",
addresses[0].getStreetAddress());
assertEquals("Washington", addresses[0].getCity());
assertEquals(State.DC, addresses[0].getStateCode());
assertEquals("20500", addresses[0].getPostalCode());
assertNull(addresses[0].getCountryCode());
assertEquals("11 Wall Street", addresses[1].getStreetAddress());
assertEquals("New York", addresses[1].getCity());
assertEquals(State.NY, addresses[1].getStateCode());
assertEquals("10005", addresses[1].getPostalCode());
assertEquals("US", addresses[1].getCountryCode());
assertEquals("350 Fifth Avenue", addresses[2].getStreetAddress());
assertEquals("New York", addresses[2].getCity());
assertEquals(State.NY, addresses[2].getStateCode());
assertEquals("10118", addresses[2].getPostalCode());
assertNull(addresses[2].getCountryCode());
assertEquals("4059 Mt Lee Drive", addresses[3].getStreetAddress());
assertEquals("Hollywood", addresses[3].getCity());
assertEquals(State.CA, addresses[3].getStateCode());
assertEquals("90068", addresses[3].getPostalCode());
assertNull(addresses[3].getCountryCode());
}
...
}
{code}
was (Author: mattmann):
... and more tinkering. See [attached
patch|https://issues.apache.org/jira/secure/attachment/12772417/commons-beanutils2.2015-11-15.patch].
{code}
public class StringToArrayTest {
private StringToArray converter;
private ConverterRegistry converterRegistry;
@Before
public void setUp() {
converter = new StringToArray();
converterRegistry = new ConverterRegistry()
.register(converter)
.register(new JsonNumberConverter())
.register(new JsonStringConverter())
.register(new JsonArrayToArray())
.register(BigDecimal::toBigIntegerExact)
.register(Address::parse)
.register(FunctionConverter.from(BigDecimal.class).to(double.class).using(BigDecimal::doubleValue))
.register(FunctionConverter.from(BigDecimal.class).to(int.class).using(BigDecimal::intValueExact))
.register(FunctionConverter.from(String.class).to(BigDecimal.class).using(BigDecimal::new))
.register(FunctionConverter.from(String.class).to(char.class).using(string -> {
if (length(string) != 1) {
throw new
IllegalArgumentException(string);
}
return string.charAt(0);
}));
}
@Test
public void convert_StringToAddressArray() {
final String
[jira] [Created] (DAEMON-338) As admin, I would like to fetch existing Java Options (properties) from prunsrv.exe
Hsehdar created DAEMON-338: -- Summary: As admin, I would like to fetch existing Java Options (properties) from prunsrv.exe Key: DAEMON-338 URL: https://issues.apache.org/jira/browse/DAEMON-338 Project: Commons Daemon Issue Type: Wish Components: Procrun Affects Versions: 1.0.15 Reporter: Hsehdar Fix For: 1.0.16 h3. What is needed? When scripting (.bat) there is a need to fetch existing Java properties and display it. After which the property and it's value can be updated as needed manually. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1289) Incorrect calculation in org.apache.commons.math3.complex.Complex#multiply
Detaille Octave created MATH-1289:
-
Summary: Incorrect calculation in
org.apache.commons.math3.complex.Complex#multiply
Key: MATH-1289
URL: https://issues.apache.org/jira/browse/MATH-1289
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.5
Environment: Linux 3.16.0-44-generic #59-Ubuntu SMP Tue Jul 7 02:07:39
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
Reporter: Detaille Octave
Hello guys!
If think there is a bug in the
org.apache.commons.math3.complex.Complex#multiply method
Line 536 & 537 below are not correct
{code:title=Complex.java|borderStyle=solid}
return createComplex(real * factor.real - imaginary * factor.imaginary, real *
factor.imaginary + imaginary * factor.real);
{code}
It should be
{code:title=Complex.java|borderStyle=solid}
return createComplex(real * factor.real + imaginary * factor.imaginary,
imaginary * factor.real-real * factor.imaginary);
{code}
Can you confirm that? Or do I miss something?
Thanks a lot (also, for this excellent library).
Best,
Octave
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MATH-1289) Incorrect calculation in org.apache.commons.math3.complex.Complex#multiply
[
https://issues.apache.org/jira/browse/MATH-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-1289.
-
Resolution: Invalid
The expressions used in the library are correct.
With your expressions, computing I^2 would give +1 instead of -1. and
multiplication would not be commutative (for example I * 1 would be the
opposite of 1 * I).
Remember that in the complex class, the imaginary field is a *real* value
holding the multiplicative factor to be applied to I (the square root of -1).
In other words z = real + I * imaginary.
So
{noformat}
z1 * z2 = (r1 + I * i1) * (r2 + I * i2)
= (r1 * r2 + I * r1 * i2 + I * i1 * r2 + I * I * i1 * i2)
= (r1 * r2 + I * I * i1 * i1) + I * (r1 * i2 + i1 * r2)
= (r1 * r2 - i1 * i2) + I * (r1 * i2 + i1 * r2)
{noformat}
which is exactly the expression in the library.
> Incorrect calculation in org.apache.commons.math3.complex.Complex#multiply
> --
>
> Key: MATH-1289
> URL: https://issues.apache.org/jira/browse/MATH-1289
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.5
> Environment: Linux 3.16.0-44-generic #59-Ubuntu SMP Tue Jul 7
> 02:07:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
>Reporter: Detaille Octave
> Labels: easyfix
>
> Hello guys!
> If think there is a bug in the
> org.apache.commons.math3.complex.Complex#multiply method
> Line 536 & 537 below are not correct
> {code:title=Complex.java|borderStyle=solid}
> return createComplex(real * factor.real - imaginary * factor.imaginary, real
> * factor.imaginary + imaginary * factor.real);
> {code}
> It should be
> {code:title=Complex.java|borderStyle=solid}
> return createComplex(real * factor.real + imaginary * factor.imaginary,
> imaginary * factor.real-real * factor.imaginary);
> {code}
> Can you confirm that? Or do I miss something?
> Thanks a lot (also, for this excellent library).
> Best,
> Octave
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
