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 16:56:54 GMT
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


Mime
View raw message