You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Benedikt Ritter <be...@systemoutprintln.de> on 2012/02/05 14:50:52 UTC
[SANDBOX][BeanUtils2] Regarding BeanAccessor.populate()
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
Re: [SANDBOX][BeanUtils2] Regarding BeanAccessor.populate()
Posted by Simone Tripodi <si...@apache.org>.
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
<be...@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
>> <be...@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
>>>> <be...@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<si...@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
>>>>>>> <be...@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
Re: [SANDBOX][BeanUtils2] Regarding BeanAccessor.populate()
Posted by Benedikt Ritter <be...@systemoutprintln.de>.
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
> <be...@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
>>> <be...@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<si...@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
>>>>>> <be...@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
Re: [SANDBOX][BeanUtils2] Regarding BeanAccessor.populate()
Posted by Simone Tripodi <si...@apache.org>.
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
<be...@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
>> <be...@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<si...@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
>>>>> <be...@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
Re: [SANDBOX][BeanUtils2] Regarding BeanAccessor.populate()
Posted by Benedikt Ritter <be...@systemoutprintln.de>.
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
> <be...@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<si...@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
>>>> <be...@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
Re: [SANDBOX][BeanUtils2] Regarding BeanAccessor.populate()
Posted by Simone Tripodi <si...@apache.org>.
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 ;)
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
<be...@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<si...@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
>>> <be...@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
Re: [SANDBOX][BeanUtils2] Regarding BeanAccessor.populate()
Posted by Benedikt Ritter <be...@systemoutprintln.de>.
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<si...@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
>> <be...@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
Re: [SANDBOX][BeanUtils2] Regarding BeanAccessor.populate()
Posted by Simone Tripodi <si...@apache.org>.
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 <si...@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
> <be...@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
Re: [SANDBOX][BeanUtils2] Regarding BeanAccessor.populate()
Posted by Simone Tripodi <si...@apache.org>.
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
<be...@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