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