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 Wed, 08 Feb 2012 20:24:09 GMT
Hi Benedikt,

having test dependencies is fine, the "restriction" is just for the
main distribution.

looking forward to apply more from you!
alles gute,
-Simo

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



On Wed, Feb 8, 2012 at 7:48 PM, Benedikt Ritter
<bene@systemoutprintln.de> wrote:
> Hey Simo,
>
> no hurry! :-)
> I'm just figuring how to implement the tests for populate(). For example I
> want do do something like (properties is an empty map in this case):
>
> @Test
> public void populateEmpty()
>    throws Exception
> {
>    on( target ).populate( properties );
>    assertTrue( target.equals( new TestBean() ) );
> }
>
> The problem is, that equals is not implemented on TestBean. I wanted to
> implement it myself, but that would take a lot of boilerplate code (checking
> if properties are null, before invoking equals on them etc.) The nicest way
> would be use EqualsBuilder from commons.lang. Can we add lang as a
> dependency in the test scope?
>
> If not, what is your recommendation for implementing the populateEmpty test?
> I could implement asserts for each and every property, but again that would
> be a lot of boilerplate, that obscures the test. An alternative would be to
> write assertEquals(TestBean expected, TestBean actual) that has all that
> stuff in it.
>
> Regards,
> Benedikt
>
>
> Am 07.02.2012 20:34, schrieb Simone Tripodi:
>
>> 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
>
>
>
> ---------------------------------------------------------------------
> 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