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 <b...@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 >> <b...@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<simonetrip...@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 >>>>> <b...@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-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
