commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <b...@systemoutprintln.de>
Subject Re: [SANDBOX][BeanUtils2] Regarding BeanAccessor.populate()
Date Tue, 07 Feb 2012 14:47:53 GMT
Hi Simo,

I've read your email twice yesterday evening and again today. Sorry, but 
I honestly do not understand, what you are talking about :-)
I assume, that you are referring to my comment on svn commit r1241124 on 
moving Assertions to a new package?! (rather then the behavior of 
populate())

If so, I would say, yes you're right when saying, that exposing the 
minimal possible API is a good thing. At least it is a good thing for 
users. OTOH for developers it is more complicated to understand the code 
if everything is contained in just one package.

I think we can live with an internal package. Everybody should know, 
that it is not intended to be used outside the library.
A nice thing about OSGi Bundles is that you can explicitly specify which 
packages should be visible to other bundles. Looking at the generated 
MANIFEST after calling mvn clean test, I can see that the internal 
package will be exported to.
Is there any possibility to configure the build, so that it generates a 
MANIFEST, that does not export the internal package?

Regards,
Benedikt


Am 06.02.2012 21:31, schrieb Simone Tripodi:
> 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


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


Mime
View raw message