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 Wed, 08 Feb 2012 18:48:40 GMT
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


Mime
View raw message