[jira] [Commented] (DAEMON-280) jsvc umask comparison wrong - fix attached

2013-02-24 Thread Mladen Turk (JIRA)

[ 
https://issues.apache.org/jira/browse/DAEMON-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585656#comment-13585656
 ] 

Mladen Turk commented on DAEMON-280:


Actually the umask should be specified in octal. That's the usual way the shell 
does the job.
I'll check if the strtol is portable enough and use the second Imre's patch.


> jsvc umask comparison wrong - fix attached
> --
>
> Key: DAEMON-280
> URL: https://issues.apache.org/jira/browse/DAEMON-280
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Jsvc
>Affects Versions: 1.0.13
> Environment: linux x64 ubuntu 12.04
>Reporter: Imre Fitos
>Priority: Minor
>
> Current code does a bitwise AND with the supplied umask and decimal 022. 
> This will pass on 022 but fail on most other, proper umasks like 077.
> This is still present in 1.0.14
> patch to fix is here:
> {noformat}
> --- commons-daemon-1.0.13-src-ORIG/src/native/unix/native/jsvc-unix.c 
> 2013-02-06 13:15:58.0 -0500
> +++ commons-daemon-1.0.13-src/src/native/unix/native/jsvc-unix.c  
> 2013-02-22 13:19:08.937906780 -0500
> @@ -1230,13 +1230,13 @@
>  /*
>   * umask() uses inverse logic; bits are CLEAR for allowed access.
>   */
> -if (~args->umask & 0022) {
> -log_error("NOTICE: jsvc umask of %03o allows "
> +if ((~(args->umask % 10) & 2) || (~(args->umask / 10) & 2)) {
> +log_error("NOTICE: jsvc umask of %04d allows "
>"write permission to group and/or other", args->umask);
>  }
>  envmask = umask(args->umask);
>  set_output(args->outfile, args->errfile, args->redirectstdin, 
> args->procname);
> -log_debug("Switching umask back to %03o from %03o", envmask, 
> args->umask);
> +log_debug("Switching umask back to %04d from %04d", envmask, 
> args->umask);
>  res = run_controller(args, data, uid, gid);
>  if (logger_pid != 0) {
>  kill(logger_pid, SIGTERM);
> {noformat}

--
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] (COLLECTIONS-395) Request for UnBoundedLRUMap implementation with extra get method

2013-02-24 Thread Thomas Neidhart (JIRA)

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585504#comment-13585504
 ] 

Thomas Neidhart commented on COLLECTIONS-395:
-

Missing a patch.

> Request for UnBoundedLRUMap implementation with extra get method
> 
>
> Key: COLLECTIONS-395
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-395
> Project: Commons Collections
>  Issue Type: Wish
>  Components: Map
>Affects Versions: Nightly Builds
>Reporter: David Hawthorne
>Priority: Minor
>
> I've created an UnBoundedLRUMap implementation (based off of BoundedLRUMap) 
> using the svn tree at version 3.3, and this has come in so handy that it 
> makes sense to suggest it to the masters in charge of the collections 
> framework.
> One tweak I made to the copy we're using is an extra get method that takes 
> two arguments: key and boolean.  The boolean determines whether or not the 
> MRU item is updated, so we can make requests into the map that do *not* 
> affect order.  This is sometimes necessary in real world environments where 
> you do not want a data structure with LRU-only accesses.
> This implementation would solve the main problem we have with using the jdk's 
> LinkedHashMap LRU implementation.

--
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-309) IteratorChain should include factory methods for decorating iterator lists and arrays into locked IteratorChain.

2013-02-24 Thread Thomas Neidhart (JIRA)

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart resolved COLLECTIONS-309.
-

Resolution: Won't Fix

Directly using an externally provided collection/array in an class is always a 
bad idea. Locking the iterator would be not useful, as the provided list would 
be externally modifiable, leading to undefined behavior.

The usual good pattern is to copy the arguments to an internal collection, 
which is not much overhead but prevents any side-effects.

The current constructors already allow to provide a list as input, which 
entries will be added to the chain.

> IteratorChain should include factory methods for decorating iterator lists 
> and arrays into locked IteratorChain.
> 
>
> Key: COLLECTIONS-309
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-309
> Project: Commons Collections
>  Issue Type: Improvement
>  Components: Iterator
>Affects Versions: 3.2
> Environment: n/a
>Reporter: ori
>Priority: Minor
>
> IteratorChain should not instantiate an ArrayList for every new instance.
> A private constructor taking a list should be added.
> Then we can add static factory methods for decorating a list of iterators to 
> produce a locked chain:
> public static IteratorChain decorate( List iterators )
> {
> final IteratorChain chain = new IteratorChain( iterators );
> chain.lockChain();
> return chain;
> }
> private IteratorChain( List iteratorChain )
> {
> this.iteratorChain = iteratorChain;
> }
> public IteratorChain()
> {
> this( new ArrayList() );
> }
> Some other observations:
> 1. There's a copy/paste mistake in the comment above the isLocked member 
> declaration (it says ComparatorChain is "locked" after the first time 
> compare(Object,Object) is called).
> 2. It's probably impossible to change now but the naming/semantics of 
> IteratorChain, ComparatorChain, and ChainedTransformer should all be 
> identical. There's a lot of duplicated functionality among these 3 classes.

--
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-283) HashedMap deepClone

2013-02-24 Thread Thomas Neidhart (JIRA)

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart resolved COLLECTIONS-283.
-

Resolution: Implemented

HashedMap already implements a shallow clone, ie the entries are put into the 
cloned map.

This behavior is equivalent to the one in the proposed patch.
A real "deep" clone would clone all map entries and put them into the cloned 
map.

> HashedMap deepClone
> ---
>
> Key: COLLECTIONS-283
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-283
> Project: Commons Collections
>  Issue Type: New Feature
>  Components: Map
>Affects Versions: 4.0-beta-1
> Environment: All
>Reporter: Hasan Diwan
> Attachments: MapUtils.pat
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The HashedMap class lacks a method to do a deep clone() of the Object. This 
> patch adds it and adds a test to make sure it works.

--
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-370) Add method MapUtils.putIfNotNull

2013-02-24 Thread Thomas Neidhart (JIRA)

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart resolved COLLECTIONS-370.
-

Resolution: Implemented

MapUtils already contains a method which does exactly what is suggested: 
safeAddToMap.

Thus closing this issue as already implemented.

> Add method MapUtils.putIfNotNull
> 
>
> Key: COLLECTIONS-370
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-370
> Project: Commons Collections
>  Issue Type: New Feature
>  Components: Map
>Affects Versions: 3.2
>Reporter: Tom Pasierb
>Priority: Minor
> Attachments: COLLECTIONS-370.patch
>
>
> Add method MapUtils.putIfNotNull that adds the given value to the map only if 
> it is not null.
> Possible implementation:
> public static  void putIfNotNull(Map map, K key, V value) {
>   if (value != null) {
>   map.put(key, value);
>   }
> }

--
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] (COLLECTIONS-443) Proposal for adding IndexedTreeMap to collections

2013-02-24 Thread Thomas Neidhart (JIRA)

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585451#comment-13585451
 ] 

Thomas Neidhart commented on COLLECTIONS-443:
-

Hi Vitaly,

thanks for your contribution. Unfortunately the code hosted on the link you 
provided is released under GPL, which is not compatible with Apache license.

To include it into commons-collections it would be necessary that you attach 
the code in question to this issue and all source files with an Apache license 
header, or you update the license on the project hosted at googlecode.

Looking at the source itself, it looks like you did start your work from the 
original Sun/Oracle code, which will make this even more complicated.

Thomas

> Proposal for adding IndexedTreeMap to collections
> -
>
> Key: COLLECTIONS-443
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-443
> Project: Commons Collections
>  Issue Type: Improvement
>Reporter: Vitaly Sazanovich
>Priority: Minor
> Fix For: 4.x
>
>
> Dear developers,
> I have written a small enhancement to JDK's TreeMap that allows to find and 
> retrieve entries by index. The project can be found here: 
> http://code.google.com/p/indexed-tree-map/ 
> This is a very requested feature, at least on stackoverflow: 
> http://stackoverflow.com/search?q=treemap+index 
> I though it would be nice and useful if my implementation becomes part of 
> Apache collections. Also I could maintain these implementations in the future.

--
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-441) MultiKeyMap.clone() should call super.clone()

2013-02-24 Thread Thomas Neidhart (JIRA)

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart resolved COLLECTIONS-441.
-

   Resolution: Fixed
Fix Version/s: 4.0

In r1449519 I also removed the map field.

Releasing collections-4 will also involve a package rename to 
org.apache.commons.collections4 which will make the serialization not backwards 
compatible anyway, so it makes sense to make this change now.

Thanks for the report and patch!

> MultiKeyMap.clone() should call super.clone()
> -
>
> Key: COLLECTIONS-441
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-441
> Project: Commons Collections
>  Issue Type: Improvement
>  Components: Map
>Affects Versions: 4.0-beta-1
>Reporter: Thomas Vahrst
>Priority: Minor
> Fix For: 4.0
>
>
> This issue addresses a findbugs issue: 
> {quote}
> org.apache.commons.collections.map.MultiKeyMap.clone() does not call 
> super.clone()
> {quote}
> The current clone() implementation creates a new MultiKeyMap instance. This 
> will lead to problems when clone() is invoked on subclasses of MultiKeyMap. 
> This is a corresponding junit test which fails:
> {code}
> class MultiKeyMapTest
> // Subclass to test clone() method
> private static class MultiKeyMapSubclass extends MultiKeyMap String>{
> }
> public void testCloneSubclass(){
> MultiKeyMapSubclass m = new MultiKeyMapSubclass();
> 
> MultiKeyMapSubclass m2 = (MultiKeyMapSubclass) m.clone();
> 
> }
> {code}
> Instead of creating a new MultiKeyMap instance, the clone() method should 
> invoke super.clone() which leads in Object.clone(). This always returns an 
> object of the correct type. 
> {code}
> class MultiKeyMap{
> /**
>  * Clones the map without cloning the keys or values.
>  *
>  * @return a shallow clone
>  */
> @Override
> public MultiKeyMap clone() {
>try {
> MultiKeyMap m = (MultiKeyMap) super.clone();
> AbstractHashedMap, V> del = 
> (AbstractHashedMap, V>)decorated().clone();
> 
> m.map = del;
> ((AbstractMapDecorator)m).map = (Map) del;
> return m;
> } catch (CloneNotSupportedException ex) {
> throw new RuntimeException (ex);  // this should never happen...
> }
> }
> {code}
> *Note*
> For serialisation compatibilty reasons to commons collections V.3.2,  
> MultiKeyMap contains a map reference (the decorated map) which hides the same 
> field in the super class AbstractMapDecorator. This is quite 'ugly' to 
> understand and maintain.
> Should we consider to break the compatibility to the 3.2 version? 

--
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] (IO-356) CharSequenceInputStream#reset() behaves incorrectly in case when buffer size is not dividable by data size

2013-02-24 Thread Thomas Neidhart (JIRA)

[ 
https://issues.apache.org/jira/browse/IO-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585391#comment-13585391
 ] 

Thomas Neidhart commented on IO-356:


Additional info:

the infinite loop of testIO_356_Loop_UTF16 is due to the fact that the buffer 
size is set to 1, while for UTF-16 encoding, each input character requires at 
least 2 bytes. Thus the input buffer is never consumed as the encoding of the 
input to the output buffer in fillBuffer never succeeds, leading to the 
infinite loop.

We should check the buffer size in the constructor and fail if it is too small 
for the selected charset.

> CharSequenceInputStream#reset() behaves incorrectly in case when buffer size 
> is not dividable by data size
> --
>
> Key: IO-356
> URL: https://issues.apache.org/jira/browse/IO-356
> Project: Commons IO
>  Issue Type: Bug
>  Components: Streams/Writers
>Affects Versions: 2.4
>Reporter: Dmitry Katsubo
> Attachments: CharSequenceInputStreamTest.java
>
>
> The size effect happens when buffer size of input stream is not dividable by 
> requested data size. The bug is hidden in {{CharSequenceInputStream#reset()}} 
> method which should also call (I think) {{bbuf.limit(0)}} otherwise next call 
> to {{CharSequenceInputStream#read()}} will return the remaining tail which 
> {{bbuf}} has accumulated.
> In the attached test case the test fails, if {{dataSize = 13}} (not dividable 
> by 10) and runs OK if {{dataSize = 20}} (dividable by 10).

--
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] [Comment Edited] (IO-356) CharSequenceInputStream#reset() behaves incorrectly in case when buffer size is not dividable by data size

2013-02-24 Thread Thomas Neidhart (JIRA)

[ 
https://issues.apache.org/jira/browse/IO-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585387#comment-13585387
 ] 

Thomas Neidhart edited comment on IO-356 at 2/24/13 3:33 PM:
-

In the reset method we have to modify also the bbuf variable, as it actually 
contains the data to be read.
If you take a look at the fillBuffer method, it actually fills bbuf with as 
many data from cbuf as bbuf can hold.

A simple scenario, input string is (AB), bbuf has a buffer size of 10:

{noformat}
  is.mark();
  byte[] data = new byte[5];
  is.read(data);
{noformat}

data will contain "A", but bbuf will contain the full input string 
(AB).
When we now call:

{noformat}
  is.reset();
  is.read(data);
{noformat}

we just reposition cbuf, but we continue to read from bbuf, thus the result 
will be "B".
I think calling bbuf.limit(0) is correct and simple, although it might be 
possible to improve it.

Regarding the other failing unit tests:

We do call the encode method with the endOfInput flag always set to true. This 
means we have to reset the coder the next time we use it (calling also flush is 
advised according to javadoc of CharsetEncoder):

{noformat}
private void fillBuffer() throws CharacterCodingException {
this.bbuf.compact();
this.encoder.reset();
final CoderResult result = this.encoder.encode(this.cbuf, this.bbuf, 
true);
this.encoder.flush(bbuf);
if (result.isError()) {
result.throwException();
}
this.bbuf.flip();
}
{noformat}

This was probably introduced as the CharsetEncoder always precedes the data 
with with the byte-order mark when using UTF-16 charset.
In that way, the BOM is only output the first time the encoder is called, but 
it also means that mark/reset will not work with such charsets, as subsequent 
calls will not generate the BOM again.

I do not know how to fix this in a clean way atm, but I would consider the 
CharSequenceInputStream for UTF-16 charset as broken and document it.

  was (Author: tn):
In the reset method we have to modify also the bbuf variable, as it 
actually contains the data to be read.
If you take a look at the fillBuffer method, it actually fills bbuf with as 
many data from cbuf as bbuf can hold.

A simple scenario, input string is (AB), bbuf has a buffer size of 10:

{noformat}
  is.mark();
  byte[] data = new byte[5];
  is.read(data);
{noformat}

data will contain "A", but bbuf will contain the full input string 
(AB).
When we now call:

{noformat}
  is.reset();
  is.read(data);
{noformat}

we just reposition cbuf, but we continue to read from bbuf, thus the result 
will be "B".
I think calling bbuf.limit(0) is correct and simple, although it might be 
possible to improve it.

Regarding the other failing unit tests:

We do call the encode method with the endOfInput flag always set to true. This 
means we have to reset the coder the next time we use it (calling also flush is 
advised according to javadoc of CharsetEncoder):

{noformat}
private void fillBuffer() throws CharacterCodingException {
this.bbuf.compact();
this.encoder.reset();
final CoderResult result = this.encoder.encode(this.cbuf, this.bbuf, 
true);
this.encoder.flush(bbuf);
if (result.isError()) {
result.throwException();
}
this.bbuf.flip();
}
{noformat}

this error was silently ignored as we created the encoder like this:

{noformat}
this.encoder = charset.newEncoder()
.onMalformedInput(CodingErrorAction.REPLACE)
.onUnmappableCharacter(CodingErrorAction.REPLACE);
{noformat}

Another thing that I encountered, the CharsetEncoder always precedes the data 
with with the byte-order mark when using UTF-16 charset, so we might get 
strange behavior in the output bytes, as the byte-order mark may also appear 
multiple times (everytime the fillBuffer method is called) in the middle of the 
data. The number of bytes actually read do not correspond to the bytes from the 
input, as the BOM is inserted. So imho, any charset that produces a BOM does 
not work for the CharSequenceInputStream atm, and I have not yet an idea how to 
fix this.
  
> CharSequenceInputStream#reset() behaves incorrectly in case when buffer size 
> is not dividable by data size
> --
>
> Key: IO-356
> URL: https://issues.apache.org/jira/browse/IO-356
> Project: Commons IO
>  Issue Type: Bug
>  Components: Streams/Writers
>Affects Versions: 2.4
>Reporter: Dmitry Katsubo
> Attachments: CharSequenceInputStreamTest.java
>
>
> The size effect happens when buffer size of input stream is n

[jira] [Commented] (IO-356) CharSequenceInputStream#reset() behaves incorrectly in case when buffer size is not dividable by data size

2013-02-24 Thread Thomas Neidhart (JIRA)

[ 
https://issues.apache.org/jira/browse/IO-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585387#comment-13585387
 ] 

Thomas Neidhart commented on IO-356:


In the reset method we have to modify also the bbuf variable, as it actually 
contains the data to be read.
If you take a look at the fillBuffer method, it actually fills bbuf with as 
many data from cbuf as bbuf can hold.

A simple scenario, input string is (AB), bbuf has a buffer size of 10:

{noformat}
  is.mark();
  byte[] data = new byte[5];
  is.read(data);
{noformat}

data will contain "A", but bbuf will contain the full input string 
(AB).
When we now call:

{noformat}
  is.reset();
  is.read(data);
{noformat}

we just reposition cbuf, but we continue to read from bbuf, thus the result 
will be "B".
I think calling bbuf.limit(0) is correct and simple, although it might be 
possible to improve it.

Regarding the other failing unit tests:

We do call the encode method with the endOfInput flag always set to true. This 
means we have to reset the coder the next time we use it (calling also flush is 
advised according to javadoc of CharsetEncoder):

{noformat}
private void fillBuffer() throws CharacterCodingException {
this.bbuf.compact();
this.encoder.reset();
final CoderResult result = this.encoder.encode(this.cbuf, this.bbuf, 
true);
this.encoder.flush(bbuf);
if (result.isError()) {
result.throwException();
}
this.bbuf.flip();
}
{noformat}

this error was silently ignored as we created the encoder like this:

{noformat}
this.encoder = charset.newEncoder()
.onMalformedInput(CodingErrorAction.REPLACE)
.onUnmappableCharacter(CodingErrorAction.REPLACE);
{noformat}

Another thing that I encountered, the CharsetEncoder always precedes the data 
with with the byte-order mark when using UTF-16 charset, so we might get 
strange behavior in the output bytes, as the byte-order mark may also appear 
multiple times (everytime the fillBuffer method is called) in the middle of the 
data. The number of bytes actually read do not correspond to the bytes from the 
input, as the BOM is inserted. So imho, any charset that produces a BOM does 
not work for the CharSequenceInputStream atm, and I have not yet an idea how to 
fix this.

> CharSequenceInputStream#reset() behaves incorrectly in case when buffer size 
> is not dividable by data size
> --
>
> Key: IO-356
> URL: https://issues.apache.org/jira/browse/IO-356
> Project: Commons IO
>  Issue Type: Bug
>  Components: Streams/Writers
>Affects Versions: 2.4
>Reporter: Dmitry Katsubo
> Attachments: CharSequenceInputStreamTest.java
>
>
> The size effect happens when buffer size of input stream is not dividable by 
> requested data size. The bug is hidden in {{CharSequenceInputStream#reset()}} 
> method which should also call (I think) {{bbuf.limit(0)}} otherwise next call 
> to {{CharSequenceInputStream#read()}} will return the remaining tail which 
> {{bbuf}} has accumulated.
> In the attached test case the test fails, if {{dataSize = 13}} (not dividable 
> by 10) and runs OK if {{dataSize = 20}} (dividable by 10).

--
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] (CONFIGURATION-526) Support loading from and saving to DOM nodes

2013-02-24 Thread Oliver Heger (JIRA)

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585386#comment-13585386
 ] 

Oliver Heger commented on CONFIGURATION-526:


Patch applied. Thanks again.

> Support loading from and saving to DOM nodes
> 
>
> Key: CONFIGURATION-526
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-526
> Project: Commons Configuration
>  Issue Type: New Feature
>Reporter: Oliver Kopp
>Priority: Minor
>  Labels: patch
> Fix For: 2.0
>
> Attachments: add-DOM-load-and-save-to-XMLPropertiesConfiguration.txt, 
> pom.xml.patch
>
>
> I'm loading a complex XML document, where properties are are nested using the 
> Java 1.5 properties XML format. This is in contrast of the issue 
> CONFIGURATION-209, where an XML-based format has been introduced. I require 
> following signatures:
>   void load(Element element) throws ConfigurationException
>   void save(Document document, Node parent)
> Please find attached a patch implementing this requirement.

--
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] (IO-368) ClassLoaderObjectInputStream does not handle primitive typed members

2013-02-24 Thread Thomas Neidhart (JIRA)

 [ 
https://issues.apache.org/jira/browse/IO-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Neidhart updated IO-368:
---

Attachment: IO-368.patch

I could not reproduce the problem with the following jdks:

 * Sun JDK 1.5 update 22
 * Oracle JDK 1.6 update 41
 * OpenJDK 1.6 b27
 * OpenJDK 1.6 u13

But I think the code could be improved to the following:

if a ClassNotFoundException is thrown, delegate to the superclass.

The default ObjectInputStream does something similar:

if the class could not be found, check in a HashMap if it is one of the 
primitive types.

The null check is spurious imho, does Class.forName ever return null?

> ClassLoaderObjectInputStream does not handle primitive typed members
> 
>
> Key: IO-368
> URL: https://issues.apache.org/jira/browse/IO-368
> Project: Commons IO
>  Issue Type: Bug
>  Components: Streams/Writers
>Affects Versions: 2.0.1
> Environment: Single node computer, running standard JVM (Oracle 1.6.0)
>Reporter: Thaddeus Diamond
> Attachments: IO-368.patch
>
>
> Any class with a simple primitive (such as long, or int) cannot be 
> deserialized.  For example, the following code:
> {code:java}
> ObjectInputStream ois = null;
> try {
>   ois = new ClassLoaderObjectInputStream(getClass().getClassLoader(), new 
> ByteArrayInputStream(bytes));
>   return (T) ois.readObject();
> } catch (ClassNotFoundException e) {
>   LOGGER.error("Deserialization failed for {}", objectClass, e);
> } catch (IOException e) {
>   LOGGER.error("Deserialization failed for {}", objectClass, e);
> } finally {
>   if (ois != null) {
> try {
>   ois.close();
> } catch (IOException ignored) {
> }
>   }
> }
> {code}
> Will fail if bytes represents a byte[] of the serialized version of the 
> following class:
> {code:java}
> public class Foo {
>   private static final long serialVersionUID = 1L;
>   private long thisFieldWillCauseCLOISToFail;
>   // class logic, ctors, etc...
> }
> {code}
> With the following stacktrace:
> {noformat}
> Caused by: java.lang.ClassNotFoundException: long
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:247)
> at 
> org.apache.commons.io.input.ClassLoaderObjectInputStream.resolveClass(ClassLoaderObjectInputStream.java:68)
> at 
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574)
> at 
> java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495)
> at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1461)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1311)
> at 
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
> at 
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
> at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
> at 
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
> at 
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
> at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
> at 
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
> at 
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
> at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
> at 
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
> at 
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
> at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
> at java.util.ArrayList.readObject(ArrayList.java:593)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invo

[jira] [Commented] (BEANUTILS-401) set array work not right in newest version

2013-02-24 Thread Benedikt Ritter (JIRA)

[ 
https://issues.apache.org/jira/browse/BEANUTILS-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585370#comment-13585370
 ] 

Benedikt Ritter commented on BEANUTILS-401:
---

Hello smildlzj,

see my comment on [BEANUTILS-400]. Feel free to provide a patch for this.

Benedikt

> set array work not right in newest version
> --
>
> Key: BEANUTILS-401
> URL: https://issues.apache.org/jira/browse/BEANUTILS-401
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.8.3
>Reporter: smildlzj
>
> i have testCase like as fllow,but it have exception in newest version,but in 
> 1.6 version it's all right.
> public static void testBeanUtil() throws Exception{
>   String[] st=new String[]{"this","is"};
>   Map s1=new HashMap();
>   Map s2=new HashMap();
>   s1.put("mapProperty", s2);
>   s1.put("mappedArray", st);
>   PropertyUtils.setProperty(s1, "mapProperty.mappedArray[2]", 
> "ce");
>   Assert.assertEquals("ce", PropertyUtils.getProperty(s1, 
> "mapProperty.mappedArray[2]"));
>   }

--
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] (BEANUTILS-400) set get Array in map fail?

2013-02-24 Thread Benedikt Ritter (JIRA)

[ 
https://issues.apache.org/jira/browse/BEANUTILS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585368#comment-13585368
 ] 

Benedikt Ritter commented on BEANUTILS-400:
---

Hi smildlzj,

the exception thrown indicates what is wrong:
{code}
java.lang.IllegalArgumentException: Indexed or mapped properties are not 
supported on objects of type Map: mapProperty(mappedArray)
at 
org.apache.commons.beanutils.PropertyUtilsBean.getPropertyOfMapBean(PropertyUtilsBean.java:813)
at 
org.apache.commons.beanutils.PropertyUtilsBean.getNestedProperty(PropertyUtilsBean.java:764)
at 
org.apache.commons.beanutils.PropertyUtilsBean.getProperty(PropertyUtilsBean.java:846)
at 
org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:426)
{code}
PropertyUtils does not support this kind of access on Maps (yet). If you want 
you can create a SVN patch for this. We can then include it in the next 
release. Because PropertyUtils produces a failure that tells users what is 
wrong, this doesn't have the highest prio ;-)

Regards,
Benedikt


> set get Array in map fail?
> --
>
> Key: BEANUTILS-400
> URL: https://issues.apache.org/jira/browse/BEANUTILS-400
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
> Environment: jdk1.6
>Reporter: smildlzj
>
> i have test case like as follow,but was fail!any problem?
> public static void testGetMappedArray() throws Exception {
>   String[] array = new String[] {"abc", "def", "ghi"};
>   Map s1=new HashMap();
>   Map s2=new HashMap();
>   s1.put("mapProperty", s2);
>   s2.put("mappedArray", array);
> 
> assertEquals("abc", PropertyUtil.getProperty(s1, 
> "mapProperty(mappedArray)[0]"));
> assertEquals("def", PropertyUtil.getProperty(s1, 
> "mapProperty(mappedArray)[1]"));
> assertEquals("ghi", PropertyUtil.getProperty(s1, 
> "mapProperty(mappedArray)[2]"));
> 
> }

--
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] (BEANUTILS-393) BeanUtilsBean sets a wrong type to value when mapped key is set

2013-02-24 Thread Benedikt Ritter (JIRA)

 [ 
https://issues.apache.org/jira/browse/BEANUTILS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated BEANUTILS-393:
--

Fix Version/s: 1.8.4

> BeanUtilsBean sets a wrong type to value when mapped key is set
> ---
>
> Key: BEANUTILS-393
> URL: https://issues.apache.org/jira/browse/BEANUTILS-393
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.8.3
> Environment: any
>Reporter: Krolikowski
> Fix For: 1.8.4
>
>
> In my opinion line no 968 in org.apache.commons.beanutils.BeanUtilsBean sets 
> the wrong value to "type" variable.
> Look:
> {code:title=BeanUtilsBean.java}
> if (descriptor instanceof MappedPropertyDescriptor) {
> if (((MappedPropertyDescriptor) 
> descriptor).getMappedWriteMethod() == null) {
> if (log.isDebugEnabled()) {
> log.debug("Skipping read-only property");
> }
> return; // Read-only, skip this property setter
> }
> type = ((MappedPropertyDescriptor) descriptor).
> getMappedPropertyType();
> } else if (index >= 0 && descriptor instanceof 
> IndexedPropertyDescriptor) {
> if (((IndexedPropertyDescriptor) 
> descriptor).getIndexedWriteMethod() == null) {
> if (log.isDebugEnabled()) {
> log.debug("Skipping read-only property");
> }
> return; // Read-only, skip this property setter
> }
> type = ((IndexedPropertyDescriptor) descriptor).
> getIndexedPropertyType();
> } else if (key != null) {
> if (descriptor.getReadMethod() == null) {
> if (log.isDebugEnabled()) {
> log.debug("Skipping read-only property");
> }
> return; // Read-only, skip this property setter
> }
> type = (value == null) ? Object.class : value.getClass();  // 
> here is the bug, imho!!!
> } else {
> if (descriptor.getWriteMethod() == null) {
> if (log.isDebugEnabled()) {
> log.debug("Skipping read-only property");
> }
> return; // Read-only, skip this property setter
> }
> type = descriptor.getPropertyType();
> }
> {code}
> For example: Variable "value" can be an instance of String[]. It will have 
> this value if there is a property "test" type of Hashmap in 
> bean and a property "test(123)" will come from the form. Variable "value" 
> will have a value String[] {"123"}. 
> The variable "type" should get in this case a value of String.class, not 
> String[].class (not an array), what happens in this line:
> {code}
> type = (value == null) ? Object.class : value.getClass();
> {code}
> This bug and the of populating data gives an exception: 
> java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to 
> java.lang.String,
> when accessing test.get("123").

--
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] (BEANUTILS-393) BeanUtilsBean sets a wrong type to value when mapped key is set

2013-02-24 Thread Benedikt Ritter (JIRA)

[ 
https://issues.apache.org/jira/browse/BEANUTILS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585362#comment-13585362
 ] 

Benedikt Ritter commented on BEANUTILS-393:
---

Hi Krolikowski,

can you please provide a JUnit test that shows erroneous behavior and the patch 
you propose as SVN patch file?

TIA!
Benedikt

> BeanUtilsBean sets a wrong type to value when mapped key is set
> ---
>
> Key: BEANUTILS-393
> URL: https://issues.apache.org/jira/browse/BEANUTILS-393
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.8.3
> Environment: any
>Reporter: Krolikowski
>
> In my opinion line no 968 in org.apache.commons.beanutils.BeanUtilsBean sets 
> the wrong value to "type" variable.
> Look:
> {code:title=BeanUtilsBean.java}
> if (descriptor instanceof MappedPropertyDescriptor) {
> if (((MappedPropertyDescriptor) 
> descriptor).getMappedWriteMethod() == null) {
> if (log.isDebugEnabled()) {
> log.debug("Skipping read-only property");
> }
> return; // Read-only, skip this property setter
> }
> type = ((MappedPropertyDescriptor) descriptor).
> getMappedPropertyType();
> } else if (index >= 0 && descriptor instanceof 
> IndexedPropertyDescriptor) {
> if (((IndexedPropertyDescriptor) 
> descriptor).getIndexedWriteMethod() == null) {
> if (log.isDebugEnabled()) {
> log.debug("Skipping read-only property");
> }
> return; // Read-only, skip this property setter
> }
> type = ((IndexedPropertyDescriptor) descriptor).
> getIndexedPropertyType();
> } else if (key != null) {
> if (descriptor.getReadMethod() == null) {
> if (log.isDebugEnabled()) {
> log.debug("Skipping read-only property");
> }
> return; // Read-only, skip this property setter
> }
> type = (value == null) ? Object.class : value.getClass();  // 
> here is the bug, imho!!!
> } else {
> if (descriptor.getWriteMethod() == null) {
> if (log.isDebugEnabled()) {
> log.debug("Skipping read-only property");
> }
> return; // Read-only, skip this property setter
> }
> type = descriptor.getPropertyType();
> }
> {code}
> For example: Variable "value" can be an instance of String[]. It will have 
> this value if there is a property "test" type of Hashmap in 
> bean and a property "test(123)" will come from the form. Variable "value" 
> will have a value String[] {"123"}. 
> The variable "type" should get in this case a value of String.class, not 
> String[].class (not an array), what happens in this line:
> {code}
> type = (value == null) ? Object.class : value.getClass();
> {code}
> This bug and the of populating data gives an exception: 
> java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to 
> java.lang.String,
> when accessing test.get("123").

--
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] (BEANUTILS-366) MemoryLeakTestCase fails for IBM JDK 1.6

2013-02-24 Thread Benedikt Ritter (JIRA)

[ 
https://issues.apache.org/jira/browse/BEANUTILS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585361#comment-13585361
 ] 

Benedikt Ritter commented on BEANUTILS-366:
---

If I run mvn test, MemoryLeaksTestCase.testConvertUtils_converters_memoryLeak 
fails. My Environment ist:
{code}
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: D:\Entwicklung\maven\3.0.3
Java version: 1.7.0_13, vendor: Oracle Corporation
Java home: D:\Entwicklung\Java\jdk1.7.0_13-x64\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
{code}
If I use the JUnit Runner from eclipse this test will pass but 
testWrapDynaClass_dynaClasses_memoryLeak fails.

> MemoryLeakTestCase fails for IBM JDK 1.6
> 
>
> Key: BEANUTILS-366
> URL: https://issues.apache.org/jira/browse/BEANUTILS-366
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.8.1
>Reporter: Niall Pemberton
>
> The following tests in MemoryLeakTestCase  fail when run with IBM JDK 1.6:
> testPropertyUtilsBean_descriptorsCache_memoryLeak()
> testPropertyUtilsBean_mappedDescriptorsCache_memoryLeak()
> testWrapDynaClass_dynaClasses_memoryLeak()
> See http://commons.markmail.org/message/gogzevkklnqwrrc2
> Just as a NOTE - those tests also fail using Sun's JDK versions 1.3 and 1.4 
> (the tests don't execute unless the JDK version is 1.5+)

--
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-526) Support loading from and saving to DOM nodes

2013-02-24 Thread Oliver Kopp (JIRA)

 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Kopp updated CONFIGURATION-526:
--

Attachment: pom.xml.patch

Thank you for the offer, please find attached a patch for pom.xml

> Support loading from and saving to DOM nodes
> 
>
> Key: CONFIGURATION-526
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-526
> Project: Commons Configuration
>  Issue Type: New Feature
>Reporter: Oliver Kopp
>Priority: Minor
>  Labels: patch
> Fix For: 2.0
>
> Attachments: add-DOM-load-and-save-to-XMLPropertiesConfiguration.txt, 
> pom.xml.patch
>
>
> I'm loading a complex XML document, where properties are are nested using the 
> Java 1.5 properties XML format. This is in contrast of the issue 
> CONFIGURATION-209, where an XML-based format has been introduced. I require 
> following signatures:
>   void load(Element element) throws ConfigurationException
>   void save(Document document, Node parent)
> Please find attached a patch implementing this requirement.

--
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] (BEANUTILS-427) Configure Checkstyle to check for tailing white spaces and white spaces on empty lines

2013-02-24 Thread Benedikt Ritter (JIRA)

[ 
https://issues.apache.org/jira/browse/BEANUTILS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585359#comment-13585359
 ] 

Benedikt Ritter commented on BEANUTILS-427:
---

I have added a check locally:
{code}




{code}
It results in 723 violations. Maybe this is to noisy. Actually this is, why the 
trailing whitespaces checker is deactivated in maven_checks.

> Configure Checkstyle to check for tailing white spaces and white spaces on 
> empty lines
> --
>
> Key: BEANUTILS-427
> URL: https://issues.apache.org/jira/browse/BEANUTILS-427
> Project: Commons BeanUtils
>  Issue Type: Improvement
>Affects Versions: 1.8.3
>Reporter: Benedikt Ritter
>Priority: Minor
> Fix For: 1.8.4
>
>
> While working on BeanUtils I have recognized that some classes contain 
> tailing white spaces and white spaces on empty lines. Checkstyle should be 
> configured to check for this.

--
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] (BEANUTILS-408) MethodUtils.invokeMethod() throws NullPointerException when args==null

2013-02-24 Thread Benedikt Ritter (JIRA)

 [ 
https://issues.apache.org/jira/browse/BEANUTILS-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter resolved BEANUTILS-408.
---

Resolution: Fixed

Fixed for invokeMethod, invokeExactMethod, invokeStaticMethod and 
invokeExactStaticMethod in r1449465.

> MethodUtils.invokeMethod() throws NullPointerException when args==null
> --
>
> Key: BEANUTILS-408
> URL: https://issues.apache.org/jira/browse/BEANUTILS-408
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.8.3
> Environment: Using Beanutils 1.8.3
>Reporter: Federico Carbonetti
> Fix For: 1.8.4
>
>
> When you invoke MethodUtils.invokeExactMethod(object, methodName, args) with 
> args==null you get a NullPointerException: 
> java.lang.NullPointerException 
> at 
> org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:352)
> at 
> org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:315)
> ... 
> Reason is: public static Object invokeExactMethod(Object object, String 
> methodName, Object arg) gets invoked (see r. 305 below) and the null wrapped 
> into an array before invoking public static Object invokeExactMethod(Object 
> object, String methodName, Object[] args); 
> 286 /** 
> 287 * Invoke a method whose parameter type matches exactly the object 
> 288 * type. 
> 289 * 
> 290 *  This is a convenient wrapper for 
> 291 * {@link #invokeExactMethod(Object object,String methodName,Object [] 
> args)}. 
> 292 *  
> 293 * 
> 294 * @param object invoke method on this object 
> 295 * @param methodName get method with this name 
> 296 * @param arg use this argument 
> 297 * @return The value returned by the invoked method 
> 298 * 
> 299 * @throws NoSuchMethodException if there is no such accessible method 
> 300 * @throws InvocationTargetException wraps an exception thrown by the 
> 301 * method invoked 
> 302 * @throws IllegalAccessException if the requested method is not 
> accessible 
> 303 * via reflection 
> 304 */ 
> 305 public static Object invokeExactMethod( 
> 306 Object object, 
> 307 String methodName, 
> 308 Object arg) 
> 309 throws 
> 310 NoSuchMethodException, 
> 311 IllegalAccessException, 
> 312 InvocationTargetException { 
> 313 
> 314 Object[] args = {arg}; 
> 315 return invokeExactMethod(object, methodName, args); 
> 316 
> 317 } 
> 318 
> 319 
> 320 /** 
> 321 * Invoke a method whose parameter types match exactly the object 
> 322 * types. 
> 323 * 
> 324 *  This uses reflection to invoke the method obtained from a call to 
> 325 * getAccessibleMethod(). 
> 326 * 
> 327 * @param object invoke method on this object 
> 328 * @param methodName get method with this name 
> 329 * @param args use these arguments - treat null as empty array 
> 330 * @return The value returned by the invoked method 
> 331 * 
> 332 * @throws NoSuchMethodException if there is no such accessible method 
> 333 * @throws InvocationTargetException wraps an exception thrown by the 
> 334 * method invoked 
> 335 * @throws IllegalAccessException if the requested method is not 
> accessible 
> 336 * via reflection 
> 337 */ 
> 338 public static Object invokeExactMethod( 
> 339 Object object, 
> 340 String methodName, 
> 341 Object[] args) 
> 342 throws 
> 343 NoSuchMethodException, 
> 344 IllegalAccessException, 
> 345 InvocationTargetException { 
> 346 if (args == null) { 
> 347 args = EMPTY_OBJECT_ARRAY; 
> 348 } 
> 349 int arguments = args.length; 
> 350 Class[] parameterTypes = new Class[arguments]; 
> 351 for (int i = 0; i < arguments; i++) { 
> 352 parameterTypes[i] = args[i].getClass(); 
> 353 } 
> 354 return invokeExactMethod(object, methodName, args, parameterTypes); 
> 355 
> 356 }

--
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] (BEANUTILS-408) MethodUtils.invokeMethod() throws NullPointerException when args==null

2013-02-24 Thread Benedikt Ritter (JIRA)

 [ 
https://issues.apache.org/jira/browse/BEANUTILS-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated BEANUTILS-408:
--

Summary: MethodUtils.invokeMethod() throws NullPointerException when 
args==null  (was: MethodUtils.invokeSetterMethods() throws NullPointerException 
when args==null)

> MethodUtils.invokeMethod() throws NullPointerException when args==null
> --
>
> Key: BEANUTILS-408
> URL: https://issues.apache.org/jira/browse/BEANUTILS-408
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.8.3
> Environment: Using Beanutils 1.8.3
>Reporter: Federico Carbonetti
> Fix For: 1.8.4
>
>
> When you invoke MethodUtils.invokeExactMethod(object, methodName, args) with 
> args==null you get a NullPointerException: 
> java.lang.NullPointerException 
> at 
> org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:352)
> at 
> org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:315)
> ... 
> Reason is: public static Object invokeExactMethod(Object object, String 
> methodName, Object arg) gets invoked (see r. 305 below) and the null wrapped 
> into an array before invoking public static Object invokeExactMethod(Object 
> object, String methodName, Object[] args); 
> 286 /** 
> 287 * Invoke a method whose parameter type matches exactly the object 
> 288 * type. 
> 289 * 
> 290 *  This is a convenient wrapper for 
> 291 * {@link #invokeExactMethod(Object object,String methodName,Object [] 
> args)}. 
> 292 *  
> 293 * 
> 294 * @param object invoke method on this object 
> 295 * @param methodName get method with this name 
> 296 * @param arg use this argument 
> 297 * @return The value returned by the invoked method 
> 298 * 
> 299 * @throws NoSuchMethodException if there is no such accessible method 
> 300 * @throws InvocationTargetException wraps an exception thrown by the 
> 301 * method invoked 
> 302 * @throws IllegalAccessException if the requested method is not 
> accessible 
> 303 * via reflection 
> 304 */ 
> 305 public static Object invokeExactMethod( 
> 306 Object object, 
> 307 String methodName, 
> 308 Object arg) 
> 309 throws 
> 310 NoSuchMethodException, 
> 311 IllegalAccessException, 
> 312 InvocationTargetException { 
> 313 
> 314 Object[] args = {arg}; 
> 315 return invokeExactMethod(object, methodName, args); 
> 316 
> 317 } 
> 318 
> 319 
> 320 /** 
> 321 * Invoke a method whose parameter types match exactly the object 
> 322 * types. 
> 323 * 
> 324 *  This uses reflection to invoke the method obtained from a call to 
> 325 * getAccessibleMethod(). 
> 326 * 
> 327 * @param object invoke method on this object 
> 328 * @param methodName get method with this name 
> 329 * @param args use these arguments - treat null as empty array 
> 330 * @return The value returned by the invoked method 
> 331 * 
> 332 * @throws NoSuchMethodException if there is no such accessible method 
> 333 * @throws InvocationTargetException wraps an exception thrown by the 
> 334 * method invoked 
> 335 * @throws IllegalAccessException if the requested method is not 
> accessible 
> 336 * via reflection 
> 337 */ 
> 338 public static Object invokeExactMethod( 
> 339 Object object, 
> 340 String methodName, 
> 341 Object[] args) 
> 342 throws 
> 343 NoSuchMethodException, 
> 344 IllegalAccessException, 
> 345 InvocationTargetException { 
> 346 if (args == null) { 
> 347 args = EMPTY_OBJECT_ARRAY; 
> 348 } 
> 349 int arguments = args.length; 
> 350 Class[] parameterTypes = new Class[arguments]; 
> 351 for (int i = 0; i < arguments; i++) { 
> 352 parameterTypes[i] = args[i].getClass(); 
> 353 } 
> 354 return invokeExactMethod(object, methodName, args, parameterTypes); 
> 355 
> 356 }

--
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] (BEANUTILS-408) MethodUtils.invokeMethod() throws NullPointerException when args==null

2013-02-24 Thread Benedikt Ritter (JIRA)

[ 
https://issues.apache.org/jira/browse/BEANUTILS-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585352#comment-13585352
 ] 

Benedikt Ritter commented on BEANUTILS-408:
---

This also applies for the invokeStaticMethod() methods.

> MethodUtils.invokeMethod() throws NullPointerException when args==null
> --
>
> Key: BEANUTILS-408
> URL: https://issues.apache.org/jira/browse/BEANUTILS-408
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.8.3
> Environment: Using Beanutils 1.8.3
>Reporter: Federico Carbonetti
> Fix For: 1.8.4
>
>
> When you invoke MethodUtils.invokeExactMethod(object, methodName, args) with 
> args==null you get a NullPointerException: 
> java.lang.NullPointerException 
> at 
> org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:352)
> at 
> org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:315)
> ... 
> Reason is: public static Object invokeExactMethod(Object object, String 
> methodName, Object arg) gets invoked (see r. 305 below) and the null wrapped 
> into an array before invoking public static Object invokeExactMethod(Object 
> object, String methodName, Object[] args); 
> 286 /** 
> 287 * Invoke a method whose parameter type matches exactly the object 
> 288 * type. 
> 289 * 
> 290 *  This is a convenient wrapper for 
> 291 * {@link #invokeExactMethod(Object object,String methodName,Object [] 
> args)}. 
> 292 *  
> 293 * 
> 294 * @param object invoke method on this object 
> 295 * @param methodName get method with this name 
> 296 * @param arg use this argument 
> 297 * @return The value returned by the invoked method 
> 298 * 
> 299 * @throws NoSuchMethodException if there is no such accessible method 
> 300 * @throws InvocationTargetException wraps an exception thrown by the 
> 301 * method invoked 
> 302 * @throws IllegalAccessException if the requested method is not 
> accessible 
> 303 * via reflection 
> 304 */ 
> 305 public static Object invokeExactMethod( 
> 306 Object object, 
> 307 String methodName, 
> 308 Object arg) 
> 309 throws 
> 310 NoSuchMethodException, 
> 311 IllegalAccessException, 
> 312 InvocationTargetException { 
> 313 
> 314 Object[] args = {arg}; 
> 315 return invokeExactMethod(object, methodName, args); 
> 316 
> 317 } 
> 318 
> 319 
> 320 /** 
> 321 * Invoke a method whose parameter types match exactly the object 
> 322 * types. 
> 323 * 
> 324 *  This uses reflection to invoke the method obtained from a call to 
> 325 * getAccessibleMethod(). 
> 326 * 
> 327 * @param object invoke method on this object 
> 328 * @param methodName get method with this name 
> 329 * @param args use these arguments - treat null as empty array 
> 330 * @return The value returned by the invoked method 
> 331 * 
> 332 * @throws NoSuchMethodException if there is no such accessible method 
> 333 * @throws InvocationTargetException wraps an exception thrown by the 
> 334 * method invoked 
> 335 * @throws IllegalAccessException if the requested method is not 
> accessible 
> 336 * via reflection 
> 337 */ 
> 338 public static Object invokeExactMethod( 
> 339 Object object, 
> 340 String methodName, 
> 341 Object[] args) 
> 342 throws 
> 343 NoSuchMethodException, 
> 344 IllegalAccessException, 
> 345 InvocationTargetException { 
> 346 if (args == null) { 
> 347 args = EMPTY_OBJECT_ARRAY; 
> 348 } 
> 349 int arguments = args.length; 
> 350 Class[] parameterTypes = new Class[arguments]; 
> 351 for (int i = 0; i < arguments; i++) { 
> 352 parameterTypes[i] = args[i].getClass(); 
> 353 } 
> 354 return invokeExactMethod(object, methodName, args, parameterTypes); 
> 355 
> 356 }

--
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] (BEANUTILS-426) ConstructorUtils.invokeConstructor(Class klass, Object arg) throws NullPointerException when arg==null

2013-02-24 Thread Benedikt Ritter (JIRA)

 [ 
https://issues.apache.org/jira/browse/BEANUTILS-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter resolved BEANUTILS-426.
---

Resolution: Fixed

Fixed for invokeExactConstrcutor(Class, Object) in r1449460.

> ConstructorUtils.invokeConstructor(Class klass, Object arg) throws 
> NullPointerException when arg==null
> --
>
> Key: BEANUTILS-426
> URL: https://issues.apache.org/jira/browse/BEANUTILS-426
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.8.3
> Environment: Using Beanutils 1.8.3
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
> Fix For: 1.8.4
>
>
> ConstructorUtils.invokeConstructor(Class klass, Object arg) can not handle 
> null passed as arg. It should check if arg is null and then simply pass null 
> to ConstructorUtils.invokeConstructor(Class klass, Object[] args) which will 
> result in calling the default constructor.

--
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] [Reopened] (BEANUTILS-426) ConstructorUtils.invokeConstructor(Class klass, Object arg) throws NullPointerException when arg==null

2013-02-24 Thread Benedikt Ritter (JIRA)

 [ 
https://issues.apache.org/jira/browse/BEANUTILS-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter reopened BEANUTILS-426:
---


Has also to be fixed for invokeExactConstructor(Class, Object).

> ConstructorUtils.invokeConstructor(Class klass, Object arg) throws 
> NullPointerException when arg==null
> --
>
> Key: BEANUTILS-426
> URL: https://issues.apache.org/jira/browse/BEANUTILS-426
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.8.3
> Environment: Using Beanutils 1.8.3
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
> Fix For: 1.8.4
>
>
> ConstructorUtils.invokeConstructor(Class klass, Object arg) can not handle 
> null passed as arg. It should check if arg is null and then simply pass null 
> to ConstructorUtils.invokeConstructor(Class klass, Object[] args) which will 
> result in calling the default constructor.

--
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] (BEANUTILS-426) ConstructorUtils.invokeConstructor(Class klass, Object arg) throws NullPointerException when arg==null

2013-02-24 Thread Benedikt Ritter (JIRA)

 [ 
https://issues.apache.org/jira/browse/BEANUTILS-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter resolved BEANUTILS-426.
---

Resolution: Fixed

Fixed in r1449456.

> ConstructorUtils.invokeConstructor(Class klass, Object arg) throws 
> NullPointerException when arg==null
> --
>
> Key: BEANUTILS-426
> URL: https://issues.apache.org/jira/browse/BEANUTILS-426
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.8.3
> Environment: Using Beanutils 1.8.3
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
> Fix For: 1.8.4
>
>
> ConstructorUtils.invokeConstructor(Class klass, Object arg) can not handle 
> null passed as arg. It should check if arg is null and then simply pass null 
> to ConstructorUtils.invokeConstructor(Class klass, Object[] args) which will 
> result in calling the default constructor.

--
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] (BEANUTILS-427) Configure Checkstyle to check for tailing white spaces and white spaces on empty lines

2013-02-24 Thread Benedikt Ritter (JIRA)
Benedikt Ritter created BEANUTILS-427:
-

 Summary: Configure Checkstyle to check for tailing white spaces 
and white spaces on empty lines
 Key: BEANUTILS-427
 URL: https://issues.apache.org/jira/browse/BEANUTILS-427
 Project: Commons BeanUtils
  Issue Type: Improvement
Affects Versions: 1.8.3
Reporter: Benedikt Ritter
Priority: Minor
 Fix For: 1.8.4


While working on BeanUtils I have recognized that some classes contain tailing 
white spaces and white spaces on empty lines. Checkstyle should be configured 
to check for this.

--
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] (BEANUTILS-426) ConstructorUtils.invokeConstructor(Class klass, Object arg) throws NullPointerException when arg==null

2013-02-24 Thread Benedikt Ritter (JIRA)

 [ 
https://issues.apache.org/jira/browse/BEANUTILS-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated BEANUTILS-426:
--

Description: ConstructorUtils.invokeConstructor(Class klass, Object arg) 
can not handle null passed as arg. It should check if arg is null and then 
simply pass null to ConstructorUtils.invokeConstructor(Class klass, Object[] 
args) which will result in calling the default constructor.  (was: When you 
invoke MethodUtils.invokeExactMethod(object, methodName, args) with args==null 
you get a NullPointerException:

java.lang.NullPointerException
at 
org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:352)
at 
org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:315)
...


Reason is: public static Object invokeExactMethod(Object object, String 
methodName, Object arg) gets invoked (see r. 305 below) and the null wrapped 
into an array before invoking public static Object invokeExactMethod(Object 
object, String methodName, Object[] args);



286/**
287 * Invoke a method whose parameter type matches exactly the object
288 * type.
289 *
290 *  This is a convenient wrapper for
291 * {@link #invokeExactMethod(Object object,String methodName,Object 
[] args)}.
292 * 
293 *
294 * @param object invoke method on this object
295 * @param methodName get method with this name
296 * @param arg use this argument
297 * @return The value returned by the invoked method
298 *
299 * @throws NoSuchMethodException if there is no such accessible 
method
300 * @throws InvocationTargetException wraps an exception thrown by the
301 *  method invoked
302 * @throws IllegalAccessException if the requested method is not 
accessible
303 *  via reflection
304 */
305public static Object invokeExactMethod(
306Object object,
307String methodName,
308Object arg)
309throws
310NoSuchMethodException,
311IllegalAccessException,
312InvocationTargetException {
313
314Object[] args = {arg};
315return invokeExactMethod(object, methodName, args);
316
317}
318
319
320/**
321 * Invoke a method whose parameter types match exactly the object
322 * types.
323 *
324 *  This uses reflection to invoke the method obtained from a 
call to
325 * getAccessibleMethod().
326 *
327 * @param object invoke method on this object
328 * @param methodName get method with this name
329 * @param args use these arguments - treat null as empty array
330 * @return The value returned by the invoked method
331 *
332 * @throws NoSuchMethodException if there is no such accessible 
method
333 * @throws InvocationTargetException wraps an exception thrown by the
334 *  method invoked
335 * @throws IllegalAccessException if the requested method is not 
accessible
336 *  via reflection
337 */
338public static Object invokeExactMethod(
339Object object,
340String methodName,
341Object[] args)
342throws
343NoSuchMethodException,
344IllegalAccessException,
345InvocationTargetException {
346if (args == null) {
347args = EMPTY_OBJECT_ARRAY;
348}  
349int arguments = args.length;
350Class[] parameterTypes = new Class[arguments];
351for (int i = 0; i < arguments; i++) {
352parameterTypes[i] = args[i].getClass();
353}
354return invokeExactMethod(object, methodName, args, 
parameterTypes);
355
356})

> ConstructorUtils.invokeConstructor(Class klass, Object arg) throws 
> NullPointerException when arg==null
> --
>
> Key: BEANUTILS-426
> URL: https://issues.apache.org/jira/browse/BEANUTILS-426
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.8.3
> Environment: Using Beanutils 1.8.3
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
> Fix For: 1.8.4
>
>
> ConstructorUtils.invokeConstructor(Class klass, Object arg) can not handle 
> null passed as arg. It should check if arg is null and then simply pass null 
> to ConstructorUtils.invokeConstructor(Class klass, Object[] args) which will 
> result in calling the default constructor.

--
This message is a

[jira] [Updated] (BEANUTILS-408) MethodUtils.invokeSetterMethods() throws NullPointerException when args==null

2013-02-24 Thread Benedikt Ritter (JIRA)

 [ 
https://issues.apache.org/jira/browse/BEANUTILS-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated BEANUTILS-408:
--

Description: 
When you invoke MethodUtils.invokeExactMethod(object, methodName, args) with 
args==null you get a NullPointerException: 

java.lang.NullPointerException 
at 
org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:352)
at 
org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:315)
... 


Reason is: public static Object invokeExactMethod(Object object, String 
methodName, Object arg) gets invoked (see r. 305 below) and the null wrapped 
into an array before invoking public static Object invokeExactMethod(Object 
object, String methodName, Object[] args); 



286 /** 
287 * Invoke a method whose parameter type matches exactly the object 
288 * type. 
289 * 
290 *  This is a convenient wrapper for 
291 * {@link #invokeExactMethod(Object object,String methodName,Object [] 
args)}. 
292 *  
293 * 
294 * @param object invoke method on this object 
295 * @param methodName get method with this name 
296 * @param arg use this argument 
297 * @return The value returned by the invoked method 
298 * 
299 * @throws NoSuchMethodException if there is no such accessible method 
300 * @throws InvocationTargetException wraps an exception thrown by the 
301 * method invoked 
302 * @throws IllegalAccessException if the requested method is not accessible 
303 * via reflection 
304 */ 
305 public static Object invokeExactMethod( 
306 Object object, 
307 String methodName, 
308 Object arg) 
309 throws 
310 NoSuchMethodException, 
311 IllegalAccessException, 
312 InvocationTargetException { 
313 
314 Object[] args = {arg}; 
315 return invokeExactMethod(object, methodName, args); 
316 
317 } 
318 
319 
320 /** 
321 * Invoke a method whose parameter types match exactly the object 
322 * types. 
323 * 
324 *  This uses reflection to invoke the method obtained from a call to 
325 * getAccessibleMethod(). 
326 * 
327 * @param object invoke method on this object 
328 * @param methodName get method with this name 
329 * @param args use these arguments - treat null as empty array 
330 * @return The value returned by the invoked method 
331 * 
332 * @throws NoSuchMethodException if there is no such accessible method 
333 * @throws InvocationTargetException wraps an exception thrown by the 
334 * method invoked 
335 * @throws IllegalAccessException if the requested method is not accessible 
336 * via reflection 
337 */ 
338 public static Object invokeExactMethod( 
339 Object object, 
340 String methodName, 
341 Object[] args) 
342 throws 
343 NoSuchMethodException, 
344 IllegalAccessException, 
345 InvocationTargetException { 
346 if (args == null) { 
347 args = EMPTY_OBJECT_ARRAY; 
348 } 
349 int arguments = args.length; 
350 Class[] parameterTypes = new Class[arguments]; 
351 for (int i = 0; i < arguments; i++) { 
352 parameterTypes[i] = args[i].getClass(); 
353 } 
354 return invokeExactMethod(object, methodName, args, parameterTypes); 
355 
356 }

  was:ConstructorUtils.invokeConstructor(Class klass, Object arg) can not 
handle null passed as arg. It should check if arg is null and then simply pass 
null to ConstructorUtils.invokeConstructor(Class klass, Object[] args) which 
will result in calling the default constructor.


> MethodUtils.invokeSetterMethods() throws NullPointerException when args==null
> -
>
> Key: BEANUTILS-408
> URL: https://issues.apache.org/jira/browse/BEANUTILS-408
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.8.3
> Environment: Using Beanutils 1.8.3
>Reporter: Federico Carbonetti
> Fix For: 1.8.4
>
>
> When you invoke MethodUtils.invokeExactMethod(object, methodName, args) with 
> args==null you get a NullPointerException: 
> java.lang.NullPointerException 
> at 
> org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:352)
> at 
> org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:315)
> ... 
> Reason is: public static Object invokeExactMethod(Object object, String 
> methodName, Object arg) gets invoked (see r. 305 below) and the null wrapped 
> into an array before invoking public static Object invokeExactMethod(Object 
> object, String methodName, Object[] args); 
> 286 /** 
> 287 * Invoke a method whose parameter type matches exactly the object 
> 288 * type. 
> 289 * 
> 290 *  This is a convenient wrapper for 
> 291 * {@link #invokeExactMethod(Object object,String methodName,Object [] 
> args)}. 
> 292 *  
> 293 * 
> 294 * @param object invoke method on this object 
> 295 * @param methodName get method with this name 
> 296 * @param arg use this argument 
> 297 * @

[jira] [Updated] (BEANUTILS-408) MethodUtils.invokeSetterMethods() throws NullPointerException when args==null

2013-02-24 Thread Benedikt Ritter (JIRA)

 [ 
https://issues.apache.org/jira/browse/BEANUTILS-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated BEANUTILS-408:
--

Description: ConstructorUtils.invokeConstructor(Class klass, Object arg) 
can not handle null passed as arg. It should check if arg is null and then 
simply pass null to ConstructorUtils.invokeConstructor(Class klass, Object[] 
args) which will result in calling the default constructor.  (was: When you 
invoke MethodUtils.invokeExactMethod(object, methodName, args) with args==null 
you get a NullPointerException:

java.lang.NullPointerException
at 
org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:352)
at 
org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:315)
...


Reason is: public static Object invokeExactMethod(Object object, String 
methodName, Object arg) gets invoked (see r. 305 below) and the null wrapped 
into an array before invoking public static Object invokeExactMethod(Object 
object, String methodName, Object[] args);



286/**
287 * Invoke a method whose parameter type matches exactly the object
288 * type.
289 *
290 *  This is a convenient wrapper for
291 * {@link #invokeExactMethod(Object object,String methodName,Object 
[] args)}.
292 * 
293 *
294 * @param object invoke method on this object
295 * @param methodName get method with this name
296 * @param arg use this argument
297 * @return The value returned by the invoked method
298 *
299 * @throws NoSuchMethodException if there is no such accessible 
method
300 * @throws InvocationTargetException wraps an exception thrown by the
301 *  method invoked
302 * @throws IllegalAccessException if the requested method is not 
accessible
303 *  via reflection
304 */
305public static Object invokeExactMethod(
306Object object,
307String methodName,
308Object arg)
309throws
310NoSuchMethodException,
311IllegalAccessException,
312InvocationTargetException {
313
314Object[] args = {arg};
315return invokeExactMethod(object, methodName, args);
316
317}
318
319
320/**
321 * Invoke a method whose parameter types match exactly the object
322 * types.
323 *
324 *  This uses reflection to invoke the method obtained from a 
call to
325 * getAccessibleMethod().
326 *
327 * @param object invoke method on this object
328 * @param methodName get method with this name
329 * @param args use these arguments - treat null as empty array
330 * @return The value returned by the invoked method
331 *
332 * @throws NoSuchMethodException if there is no such accessible 
method
333 * @throws InvocationTargetException wraps an exception thrown by the
334 *  method invoked
335 * @throws IllegalAccessException if the requested method is not 
accessible
336 *  via reflection
337 */
338public static Object invokeExactMethod(
339Object object,
340String methodName,
341Object[] args)
342throws
343NoSuchMethodException,
344IllegalAccessException,
345InvocationTargetException {
346if (args == null) {
347args = EMPTY_OBJECT_ARRAY;
348}  
349int arguments = args.length;
350Class[] parameterTypes = new Class[arguments];
351for (int i = 0; i < arguments; i++) {
352parameterTypes[i] = args[i].getClass();
353}
354return invokeExactMethod(object, methodName, args, 
parameterTypes);
355
356})

> MethodUtils.invokeSetterMethods() throws NullPointerException when args==null
> -
>
> Key: BEANUTILS-408
> URL: https://issues.apache.org/jira/browse/BEANUTILS-408
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.8.3
> Environment: Using Beanutils 1.8.3
>Reporter: Federico Carbonetti
> Fix For: 1.8.4
>
>
> ConstructorUtils.invokeConstructor(Class klass, Object arg) can not handle 
> null passed as arg. It should check if arg is null and then simply pass null 
> to ConstructorUtils.invokeConstructor(Class klass, Object[] args) which will 
> result in calling the default constructor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact you

[jira] [Commented] (BEANUTILS-408) MethodUtils.invokeSetterMethods() throws NullPointerException when args==null

2013-02-24 Thread Benedikt Ritter (JIRA)

[ 
https://issues.apache.org/jira/browse/BEANUTILS-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585345#comment-13585345
 ] 

Benedikt Ritter commented on BEANUTILS-408:
---

The same applies to ConstructorUtils.invokeConstructor(Class, Object). I'm 
creating a separate issue for this.

> MethodUtils.invokeSetterMethods() throws NullPointerException when args==null
> -
>
> Key: BEANUTILS-408
> URL: https://issues.apache.org/jira/browse/BEANUTILS-408
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.8.3
> Environment: Using Beanutils 1.8.3
>Reporter: Federico Carbonetti
> Fix For: 1.8.4
>
>
> When you invoke MethodUtils.invokeExactMethod(object, methodName, args) with 
> args==null you get a NullPointerException:
> java.lang.NullPointerException
>   at 
> org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:352)
>   at 
> org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:315)
>   ...
> Reason is: public static Object invokeExactMethod(Object object, String 
> methodName, Object arg) gets invoked (see r. 305 below) and the null wrapped 
> into an array before invoking public static Object invokeExactMethod(Object 
> object, String methodName, Object[] args);
> 286/**
> 287 * Invoke a method whose parameter type matches exactly the 
> object
> 288 * type.
> 289 *
> 290 *  This is a convenient wrapper for
> 291 * {@link #invokeExactMethod(Object object,String 
> methodName,Object [] args)}.
> 292 * 
> 293 *
> 294 * @param object invoke method on this object
> 295 * @param methodName get method with this name
> 296 * @param arg use this argument
> 297 * @return The value returned by the invoked method
> 298 *
> 299 * @throws NoSuchMethodException if there is no such accessible 
> method
> 300 * @throws InvocationTargetException wraps an exception thrown by 
> the
> 301 *  method invoked
> 302 * @throws IllegalAccessException if the requested method is not 
> accessible
> 303 *  via reflection
> 304 */
> 305public static Object invokeExactMethod(
> 306Object object,
> 307String methodName,
> 308Object arg)
> 309throws
> 310NoSuchMethodException,
> 311IllegalAccessException,
> 312InvocationTargetException {
> 313
> 314Object[] args = {arg};
> 315return invokeExactMethod(object, methodName, args);
> 316
> 317}
> 318
> 319
> 320/**
> 321 * Invoke a method whose parameter types match exactly the 
> object
> 322 * types.
> 323 *
> 324 *  This uses reflection to invoke the method obtained from a 
> call to
> 325 * getAccessibleMethod().
> 326 *
> 327 * @param object invoke method on this object
> 328 * @param methodName get method with this name
> 329 * @param args use these arguments - treat null as empty array
> 330 * @return The value returned by the invoked method
> 331 *
> 332 * @throws NoSuchMethodException if there is no such accessible 
> method
> 333 * @throws InvocationTargetException wraps an exception thrown by 
> the
> 334 *  method invoked
> 335 * @throws IllegalAccessException if the requested method is not 
> accessible
> 336 *  via reflection
> 337 */
> 338public static Object invokeExactMethod(
> 339Object object,
> 340String methodName,
> 341Object[] args)
> 342throws
> 343NoSuchMethodException,
> 344IllegalAccessException,
> 345InvocationTargetException {
> 346if (args == null) {
> 347args = EMPTY_OBJECT_ARRAY;
> 348}  
> 349int arguments = args.length;
> 350Class[] parameterTypes = new Class[arguments];
> 351for (int i = 0; i < arguments; i++) {
> 352parameterTypes[i] = args[i].getClass();
> 353}
> 354return invokeExactMethod(object, methodName, args, 
> parameterTypes);
> 355
> 356}

--
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] (BEANUTILS-426) ConstructorUtils.invokeConstructor(Class klass, Object arg) throws NullPointerException when arg==null

2013-02-24 Thread Benedikt Ritter (JIRA)

 [ 
https://issues.apache.org/jira/browse/BEANUTILS-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated BEANUTILS-426:
--

Reporter: Benedikt Ritter  (was: Federico Carbonetti)

> ConstructorUtils.invokeConstructor(Class klass, Object arg) throws 
> NullPointerException when arg==null
> --
>
> Key: BEANUTILS-426
> URL: https://issues.apache.org/jira/browse/BEANUTILS-426
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.8.3
> Environment: Using Beanutils 1.8.3
>Reporter: Benedikt Ritter
> Fix For: 1.8.4
>
>
> When you invoke MethodUtils.invokeExactMethod(object, methodName, args) with 
> args==null you get a NullPointerException:
> java.lang.NullPointerException
>   at 
> org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:352)
>   at 
> org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:315)
>   ...
> Reason is: public static Object invokeExactMethod(Object object, String 
> methodName, Object arg) gets invoked (see r. 305 below) and the null wrapped 
> into an array before invoking public static Object invokeExactMethod(Object 
> object, String methodName, Object[] args);
> 286/**
> 287 * Invoke a method whose parameter type matches exactly the 
> object
> 288 * type.
> 289 *
> 290 *  This is a convenient wrapper for
> 291 * {@link #invokeExactMethod(Object object,String 
> methodName,Object [] args)}.
> 292 * 
> 293 *
> 294 * @param object invoke method on this object
> 295 * @param methodName get method with this name
> 296 * @param arg use this argument
> 297 * @return The value returned by the invoked method
> 298 *
> 299 * @throws NoSuchMethodException if there is no such accessible 
> method
> 300 * @throws InvocationTargetException wraps an exception thrown by 
> the
> 301 *  method invoked
> 302 * @throws IllegalAccessException if the requested method is not 
> accessible
> 303 *  via reflection
> 304 */
> 305public static Object invokeExactMethod(
> 306Object object,
> 307String methodName,
> 308Object arg)
> 309throws
> 310NoSuchMethodException,
> 311IllegalAccessException,
> 312InvocationTargetException {
> 313
> 314Object[] args = {arg};
> 315return invokeExactMethod(object, methodName, args);
> 316
> 317}
> 318
> 319
> 320/**
> 321 * Invoke a method whose parameter types match exactly the 
> object
> 322 * types.
> 323 *
> 324 *  This uses reflection to invoke the method obtained from a 
> call to
> 325 * getAccessibleMethod().
> 326 *
> 327 * @param object invoke method on this object
> 328 * @param methodName get method with this name
> 329 * @param args use these arguments - treat null as empty array
> 330 * @return The value returned by the invoked method
> 331 *
> 332 * @throws NoSuchMethodException if there is no such accessible 
> method
> 333 * @throws InvocationTargetException wraps an exception thrown by 
> the
> 334 *  method invoked
> 335 * @throws IllegalAccessException if the requested method is not 
> accessible
> 336 *  via reflection
> 337 */
> 338public static Object invokeExactMethod(
> 339Object object,
> 340String methodName,
> 341Object[] args)
> 342throws
> 343NoSuchMethodException,
> 344IllegalAccessException,
> 345InvocationTargetException {
> 346if (args == null) {
> 347args = EMPTY_OBJECT_ARRAY;
> 348}  
> 349int arguments = args.length;
> 350Class[] parameterTypes = new Class[arguments];
> 351for (int i = 0; i < arguments; i++) {
> 352parameterTypes[i] = args[i].getClass();
> 353}
> 354return invokeExactMethod(object, methodName, args, 
> parameterTypes);
> 355
> 356}

--
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] (BEANUTILS-426) ConstructorUtils.invokeConstructor(Class klass, Object arg) throws NullPointerException when arg==null

2013-02-24 Thread Benedikt Ritter (JIRA)
Benedikt Ritter created BEANUTILS-426:
-

 Summary: ConstructorUtils.invokeConstructor(Class klass, Object 
arg) throws NullPointerException when arg==null
 Key: BEANUTILS-426
 URL: https://issues.apache.org/jira/browse/BEANUTILS-426
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Bean / Property Utils
Affects Versions: 1.8.3
 Environment: Using Beanutils 1.8.3
Reporter: Federico Carbonetti
 Fix For: 1.8.4


When you invoke MethodUtils.invokeExactMethod(object, methodName, args) with 
args==null you get a NullPointerException:

java.lang.NullPointerException
at 
org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:352)
at 
org.apache.commons.beanutils.MethodUtils.invokeExactMethod(MethodUtils.java:315)
...


Reason is: public static Object invokeExactMethod(Object object, String 
methodName, Object arg) gets invoked (see r. 305 below) and the null wrapped 
into an array before invoking public static Object invokeExactMethod(Object 
object, String methodName, Object[] args);



286/**
287 * Invoke a method whose parameter type matches exactly the object
288 * type.
289 *
290 *  This is a convenient wrapper for
291 * {@link #invokeExactMethod(Object object,String methodName,Object 
[] args)}.
292 * 
293 *
294 * @param object invoke method on this object
295 * @param methodName get method with this name
296 * @param arg use this argument
297 * @return The value returned by the invoked method
298 *
299 * @throws NoSuchMethodException if there is no such accessible 
method
300 * @throws InvocationTargetException wraps an exception thrown by the
301 *  method invoked
302 * @throws IllegalAccessException if the requested method is not 
accessible
303 *  via reflection
304 */
305public static Object invokeExactMethod(
306Object object,
307String methodName,
308Object arg)
309throws
310NoSuchMethodException,
311IllegalAccessException,
312InvocationTargetException {
313
314Object[] args = {arg};
315return invokeExactMethod(object, methodName, args);
316
317}
318
319
320/**
321 * Invoke a method whose parameter types match exactly the object
322 * types.
323 *
324 *  This uses reflection to invoke the method obtained from a 
call to
325 * getAccessibleMethod().
326 *
327 * @param object invoke method on this object
328 * @param methodName get method with this name
329 * @param args use these arguments - treat null as empty array
330 * @return The value returned by the invoked method
331 *
332 * @throws NoSuchMethodException if there is no such accessible 
method
333 * @throws InvocationTargetException wraps an exception thrown by the
334 *  method invoked
335 * @throws IllegalAccessException if the requested method is not 
accessible
336 *  via reflection
337 */
338public static Object invokeExactMethod(
339Object object,
340String methodName,
341Object[] args)
342throws
343NoSuchMethodException,
344IllegalAccessException,
345InvocationTargetException {
346if (args == null) {
347args = EMPTY_OBJECT_ARRAY;
348}  
349int arguments = args.length;
350Class[] parameterTypes = new Class[arguments];
351for (int i = 0; i < arguments; i++) {
352parameterTypes[i] = args[i].getClass();
353}
354return invokeExactMethod(object, methodName, args, 
parameterTypes);
355
356}

--
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] (BEANUTILS-409) BeanUtils - 'describe' method returning Incorrect array value

2013-02-24 Thread Benedikt Ritter (JIRA)

[ 
https://issues.apache.org/jira/browse/BEANUTILS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585343#comment-13585343
 ] 

Benedikt Ritter commented on BEANUTILS-409:
---

Hello Senthil,

I've started a discussion about this issue on the ML [1]. I'll comment here as 
soon as I get feedback.

[1] http://markmail.org/message/5k53gqakfpt2r7xl

> BeanUtils - 'describe' method returning Incorrect array value
> -
>
> Key: BEANUTILS-409
> URL: https://issues.apache.org/jira/browse/BEANUTILS-409
> Project: Commons BeanUtils
>  Issue Type: Bug
>Affects Versions: 1.8.3
> Environment: commons-beanutils 1.8.3, jdk 1.6.0_20
>Reporter: benny
>Assignee: Benedikt Ritter
>Priority: Critical
>  Labels: describe
> Fix For: 1.8.4
>
> Attachments: BEANUTILS-409-Test.patch
>
>
> I want to convert a bean class to a map (key=the name of the member,value=the 
> value of the member).
> I'm using the method BeanUtils.describe(beanClass);
> (I'm using commons-beanutils 1.8.3, jdk 1.6.0_20, on commons-beanutils 1.5 it 
> works)
> The problem is that the return value is incorrect, (the map contain only the 
> first item from the array),
> the code:
> public class Demo { 
> private ArrayList myList = new ArrayList(); 
> public Demo() { 
> myList.add("first_value"); 
> myList.add("second_value"); 
> } 
>  
> public ArrayList getMyList() { 
> return myList; 
> } 
>  
> public void setMyList(ArrayList myList) { 
> this.myList = myList; 
> } 
>  
> public static void main(String[] args) { 
> Demo myBean = new Demo(); 
> try { 
> Map describe = BeanUtils.describe(myBean); 
> Iterator it = describe.entrySet().iterator(); 
> while (it.hasNext()) { 
> Map.Entry pairs = (Map.Entry) it.next(); 
> System.out.println(String.format("key=%s,value=%s", 
> (String) pairs.getKey(), (String) pairs.getValue())); 
>  
> } 
> } catch (Exception e) { 
> e.printStackTrace(); 
> } 
> } 
> } 
>  •The expected output:
>  
> key=myList,value=[first_value,second_value]
> key=class,value=class $Demo
>  •But the real output is:
>  
> key=myList,value=[first_value]
> key=class,value=class $Demo
> As you can see the array contains two values but the output(and the map) 
> contains only one,why??

--
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