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 Tue, 07 Feb 2012 19:34:11 GMT
Excellent :)

I'll take care to apply your patches tomorrow, unfortunately I have
still some task to complete today :/

alles gute,
-Simo

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



On Tue, Feb 7, 2012 at 5:56 PM, Benedikt Ritter
<bene@systemoutprintln.de> wrote:
> Am 07.02.2012 16:19, schrieb Simone Tripodi:
>
>> Hola,
>>
>>> 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())
>>
>>
>> yes indeed, I replied to your last message
>>
>>>
>>> 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.
>>>
>>
>> :| complicated?!? do you see how small is the actual the codebase?
>> have you never raw Hibernate or Spring2.X source code? :)
>>
>>>
>>> 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?
>>>
>>
>> yes, there are few configuration properties that have to be set, see
>> the parent pom if you're interested on providing the patch ;)
>
>
> done ;)
>
>
>>
>> alles gute!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Tue, Feb 7, 2012 at 3:47 PM, Benedikt Ritter
>> <bene@systemoutprintln.de>  wrote:
>>>
>>> Hi Simo,
>>>
>>
>>>
>>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> 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