Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of simone.tripodi@gmail.com
 designates 209.85.216.50 as permitted sender)
MIME-Version: 1.0
Sender: simone.tripodi@gmail.com
In-Reply-To: <4F313999.2000503@systemoutprintln.de>
References: <4F2E893C.90008@systemoutprintln.de>
	<CAAqLGLOOpoyZKiELh7grYOsgxJrtXV1tK1VL_TJ1mCAjGPdwGQ@mail.gmail.com>
	<CAAqLGLPP8gV2MHq4hLTrofhwZ_m12achfb0mi-pJWe2MfKs6KA@mail.gmail.com>
	<4F313999.2000503@systemoutprintln.de>
Date: Tue, 7 Feb 2012 16:19:08 +0100
Message-ID: 
 <CAAqLGLPLosrKBjd4_=DUH+2kMh9eAnpZwr6pm4AxZ-fRVtzjng@mail.gmail.com>
Subject: Re: [SANDBOX][BeanUtils2] Regarding BeanAccessor.populate()
From: Simone Tripodi <simonetripodi@apache.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 minim=
al
> 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 everythin=
g
> 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 packag=
e
> 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
<bene@systemoutprintln.de> wrote:
> Hi Simo,
>

>
> If so, I would say, yes you're right when saying, that exposing the minim=
al
> 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 everythin=
g
> 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 packag=
e
> 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>
>> =C2=A0wrote:
>>>
>>> Hi Benedikt,
>>>
>>> let's keep the `skip readonly property` behavior ATM, that is
>>> something =C2=A0BeanUtils 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> =C2=A0wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm working on populate and tried to stick to the convention of throwi=
ng
>>>> 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 o=
f
>>>> 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> =C2=A0properties ) throws
>>>> IllegalAccessException, IllegalArgumentException,
>>>> InvocationTargetException,
>>>> NoSuchMethodException, IntrospectionException
>>>> {
>>>> =C2=A0 =C2=A0checkNotNull( properties, "Can not populate null!" );
>>>> =C2=A0 =C2=A0for ( String propertyName : properties.keySet() )
>>>> =C2=A0 =C2=A0{
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0checkNotNull( propertyName, "Null is not an=
 allowed property
>>>> key!" );
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0setProperty( propertyName ).withValue( prop=
erties.get(
>>>> propertyName )
>>>> );
>>>> =C2=A0 =C2=A0}
>>>> }
>>>>
>>>> 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