commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [SANDBOX][BeanUtils2] Regarding BeanAccessor.populate()
Date Mon, 06 Feb 2012 20:31:23 GMT
anyway, just for the record: the reason is just because I introduced a
new package that needs to access to same methods, otherwise there
wouldn't have been any reason to expose it.
do you see a valid motivation?
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Sun, Feb 5, 2012 at 9:27 PM, Simone Tripodi <simonetripodi@apache.org> wrote:
> Hi Benedikt,
>
> let's keep the `skip readonly property` behavior ATM, that is
> something  BeanUtils users are already used to.
> Same for null key, skip them.
>
> Moreover, iterate over properties.entrySet()[1] instead of keySet().
>
> all the best,
> -Simo
>
> [1] http://docs.oracle.com/javase/6/docs/api/java/util/Map.html#entrySet()
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sun, Feb 5, 2012 at 2:50 PM, Benedikt Ritter
> <bene@systemoutprintln.de> wrote:
>> Hi,
>>
>> I'm working on populate and tried to stick to the convention of throwing
>> exceptions for illegal inputs:
>>
>> * passing null will cause NullPointerException
>> * passing an empty Map will have no effect
>> * passing a Map with null keys will cause NullPointerException
>> * passing a Map with null values will set those properties to null
>> * passing a Map with null values for primitive properties will cause a
>> IllegalArgumentException
>>
>> But this is in contrast to BeanUtils1. Looking at the implementation of
>> BeanUtilsBean.populate() I can see that:
>>
>> * passing null does nothing
>> * passing an empty map does nothing
>> * Null keys will be ignored
>>
>> Now I think, that throwing exceptions is better than just accepting every
>> value. Am I right with that?
>>
>> Also, I'm wondering how populate should behave if a value for a read only
>> property is passed. Looking at BeanUtils1 I've seen that
>> BeanUtilsBean.populate() just ignores those properties (line 974 in
>> BeanUtilsBean).
>> Currently I've a pretty straight forward implementation:
>>
>> public void populate( Map<String, Object> properties ) throws
>> IllegalAccessException, IllegalArgumentException, InvocationTargetException,
>> NoSuchMethodException, IntrospectionException
>> {
>>    checkNotNull( properties, "Can not populate null!" );
>>    for ( String propertyName : properties.keySet() )
>>    {
>>        checkNotNull( propertyName, "Null is not an allowed property key!" );
>>        setProperty( propertyName ).withValue( properties.get( propertyName )
>> );
>>    }
>> }
>>
>> Calling setProperty will result in a NoSuchMethodException been thrown, if
>> there is no setter method for a given key. I thing that is convenient
>> looking at the overall design of BeanUtils2.
>>
>> To sum this all up: How should populate() behave, if the property for a
>> given key is read only?
>>
>> Regards,
>> Benedikt
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message