You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Bruno P. Kinoshita" <br...@yahoo.com.br> on 2013/10/31 02:12:32 UTC
Re: [functor] Keep Serializable in [functor] or drop it?
Hi all,
I posted it in the mailing list some time ago and now I will have time to work on this during the next days. I've flled FUNCTOR-29 to work on this. Let me know if there are any objections to this.
Thanks!
[1] https://issues.apache.org/jira/browse/FUNCTOR-29
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com
----- Original Message -----
> From: Bruno P. Kinoshita <ki...@apache.org>
> To: Commons List <de...@commons.apache.org>
> Cc:
> Sent: Monday, February 11, 2013 9:24 PM
> Subject: Re: [functor] Keep Serializable in [functor] or drop it?
>
> Hi all,
>
> Any objections to removing serialization from [functor]? Here's why I think
> we should drop it:
>
> * It's been discussed in the mailing list in the past about other components
> dropping support to serialization, I think [math] already had problems
> maintaining compatibility+serialization [1]
>
> * There are classes that create internal objects that, although not exposed to
> the users, would have to be serialized or treated before being serialized. e.g.:
> IsEquivalent has a Comparator field, that is passed in the constructor. When no
> comparator is given, it uses a comparator that is bundled in [functor]
> (ComparableComparator) that implements Serializable. But if a user wrote code
> like the below, it would raise an exception:
>
> IsEquivalent<Double> isEq = new IsEquivalent<Double>(new
> Comparator<Double>() { // not serializable
> public int compare(Double o1, Double o2) {
> return (o1>o2 ? -1 : (o1==o2 ? 0 : 1));
> }
> });
> System.out.println(isEq.test(1.0, 2.0));
> System.out.println(isEq.test(1.0, 1.0));
> try {
> ByteArrayOutputStream bos = new ByteArrayOutputStream();
> ObjectOutputStream out = new ObjectOutputStream(bos);
>
> out.writeObject(isEq);
> } catch (Exception e) {
> throw new AssertionError(e);
> }
>
> * A user may create a recursive function with several levels (think of thousands
> of levels for this example, and see RecursiveEvaluation too). This could cause a
> StackOverFlow since "the default serialization procedure performs a
> recursive traversal of the object graph" (Bloch).
>
> * Also, there are classes in aggregator that don't support serialization yet
> (see o.a.c.functor.aggregator).
>
> Thoughts on this? I've removed the serialization feature from [functor] in
> my GitHub mirror, and the only major change required was removing existing tests
> that handled serialization. Thus, the number of tests decreased to less than
> 1000 (we have now _only_ ~900 :-).
>
> Most of the existing classes have a paragraph about serialization, but some
> don't (e.g.: IsEquivalent). If we don't drop serialization, I'll fix
> that in the classes missing that paragraph. I intend to use [functor] with
> Jenkins plug-ins, where serialization (and commons-jelly!) is used a lot (it
> sends objects to the slaves), but I prefer to write proxies or some other trick
> to serialize my functions, than have to deal with problems with different
> versions of [functor] :-)
>
> Thanks!
>
> [1] http://markmail.org/thread/3dpionbxkzyktrno
>
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
>
> ----- Original Message -----
>> From: Bruno P. Kinoshita <br...@yahoo.com.br>
>> To: Commons Developers List <de...@commons.apache.org>
>> Cc:
>> Sent: Monday, April 9, 2012 1:55 PM
>> Subject: [functor] Keep Serializable in [functor] or drop it?
>>
>> Hi all,
>>
>> I was writing some tests for [functor] when I found that one of my tests
> was
>> failing with a NotSerializableException. The test uses a class that extends
>
>> PredicatedLoop. This class contains a Procedure and a Predicate member
> fields,
>> which are not serializable.
>>
>> I remember seeing some discussion about keeping serialization support in
> the
>> API, or dropping it and letting the user handle this in his code.
>>
>> Should we keep it or drop it? :)
>>
>> If we decide to keep it:
>>
>> - PredicatedLoop serializable but some of its members are not. We could
> make
>> them implement Serializable or use writeObject and readObject. If we went
> with
>> the former, a series of other changes would be required as well (Limit and
>> Offset don't implement equals or hashcode, for instance, and are used
> in
>> some tests of algorithms). The latter choice would require attention in
> case
>> someone changed the object members (adding/removing/...).
>>
>> - Probably there are other classes in the same situation, then these
> classes
>> would have to be updated as well.
>>
>> If we decide to drop the serialization support in [functor] API:
>>
>> - Users would have to handle serialization in their code.
>>
>> - We would have to refactor many functors
>>
>> - The BaseFunctorTest methods related to serialization would be removed
>>
>> - Javadoc would have to be updated in some classes as well
>>
>> Many thanks in advance.
>>
>> -- Bruno P. Kinoshita
>> http://www.kinoshita.eti.br
>> http://www.tupilabs.com
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [functor] Keep Serializable in [functor] or drop it?
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br>.
Done! Thanks!
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com
----- Original Message -----
> From: Matt Benson <gu...@gmail.com>
> To: Commons Developers List <de...@commons.apache.org>
> Cc:
> Sent: Thursday, October 31, 2013 1:09 PM
> Subject: Re: [functor] Keep Serializable in [functor] or drop it?
>
> Sure, go ahead. :)
>
> Matt
>
>
>
> On Thu, Oct 31, 2013 at 1:25 AM, Benedikt Ritter <br...@apache.org>
> wrote:
>
>> Makes sense for me t dro serialization support for 1.0. If users really
>> demand it, it can be added afterwards.
>>
>> Benedikt
>>
>> 2013/10/31 Bruno P. Kinoshita <br...@yahoo.com.br>
>>
>> > Hi all,
>> >
>> > I posted it in the mailing list some time ago and now I will have time
> to
>> > work on this during the next days. I've flled FUNCTOR-29 to work
> on this.
>> > Let me know if there are any objections to this.
>> >
>> > Thanks!
>> >
>> > [1] https://issues.apache.org/jira/browse/FUNCTOR-29
>> >
>> > Bruno P. Kinoshita
>> > http://kinoshita.eti.br
>> > http://tupilabs.com
>> >
>> >
>> > ----- Original Message -----
>> > > From: Bruno P. Kinoshita <ki...@apache.org>
>> > > To: Commons List <de...@commons.apache.org>
>> > > Cc:
>> > > Sent: Monday, February 11, 2013 9:24 PM
>> > > Subject: Re: [functor] Keep Serializable in [functor] or drop it?
>> > >
>> > > Hi all,
>> > >
>> > > Any objections to removing serialization from [functor]?
> Here's why I
>> > think
>> > > we should drop it:
>> > >
>> > > * It's been discussed in the mailing list in the past about
> other
>> > components
>> > > dropping support to serialization, I think [math] already had
> problems
>> > > maintaining compatibility+serialization [1]
>> > >
>> > > * There are classes that create internal objects that, although
> not
>> > exposed to
>> > > the users, would have to be serialized or treated before being
>> > serialized. e.g.:
>> > > IsEquivalent has a Comparator field, that is passed in the
> constructor.
>> > When no
>> > > comparator is given, it uses a comparator that is bundled in
> [functor]
>> > > (ComparableComparator) that implements Serializable. But if a
> user
>> wrote
>> > code
>> > > like the below, it would raise an exception:
>> > >
>> > > IsEquivalent<Double> isEq = new
> IsEquivalent<Double>(new
>> > > Comparator<Double>() { // not serializable
>> > > public int compare(Double o1, Double o2) {
>> > > return (o1>o2 ? -1 : (o1==o2 ? 0 : 1));
>> > > }
>> > > });
>> > > System.out.println(isEq.test(1.0, 2.0));
>> > > System.out.println(isEq.test(1.0, 1.0));
>> > > try {
>> > > ByteArrayOutputStream bos = new
> ByteArrayOutputStream();
>> > > ObjectOutputStream out = new ObjectOutputStream(bos);
>> > >
>> > > out.writeObject(isEq);
>> > > } catch (Exception e) {
>> > > throw new AssertionError(e);
>> > > }
>> > >
>> > > * A user may create a recursive function with several levels
> (think of
>> > thousands
>> > > of levels for this example, and see RecursiveEvaluation too).
> This
>> could
>> > cause a
>> > > StackOverFlow since "the default serialization procedure
> performs a
>> > > recursive traversal of the object graph" (Bloch).
>> > >
>> > > * Also, there are classes in aggregator that don't support
>> serialization
>> > yet
>> > > (see o.a.c.functor.aggregator).
>> > >
>> > > Thoughts on this? I've removed the serialization feature from
> [functor]
>> > in
>> > > my GitHub mirror, and the only major change required was removing
>> > existing tests
>> > > that handled serialization. Thus, the number of tests decreased
> to less
>> > than
>> > > 1000 (we have now _only_ ~900 :-).
>> > >
>> > > Most of the existing classes have a paragraph about
> serialization, but
>> > some
>> > > don't (e.g.: IsEquivalent). If we don't drop
> serialization, I'll fix
>> > > that in the classes missing that paragraph. I intend to use
> [functor]
>> > with
>> > > Jenkins plug-ins, where serialization (and commons-jelly!) is
> used a
>> lot
>> > (it
>> > > sends objects to the slaves), but I prefer to write proxies or
> some
>> > other trick
>> > > to serialize my functions, than have to deal with problems with
>> different
>> > > versions of [functor] :-)
>> > >
>> > > Thanks!
>> > >
>> > > [1] http://markmail.org/thread/3dpionbxkzyktrno
>> > >
>> > > Bruno P. Kinoshita
>> > > http://kinoshita.eti.br
>> > > http://tupilabs.com
>> > >
>> > >
>> > > ----- Original Message -----
>> > >> From: Bruno P. Kinoshita <br...@yahoo.com.br>
>> > >> To: Commons Developers List <de...@commons.apache.org>
>> > >> Cc:
>> > >> Sent: Monday, April 9, 2012 1:55 PM
>> > >> Subject: [functor] Keep Serializable in [functor] or drop
> it?
>> > >>
>> > >> Hi all,
>> > >>
>> > >> I was writing some tests for [functor] when I found that one
> of my
>> > tests
>> > > was
>> > >> failing with a NotSerializableException. The test uses a
> class that
>> > extends
>> > >
>> > >> PredicatedLoop. This class contains a Procedure and a
> Predicate
>> member
>> > > fields,
>> > >> which are not serializable.
>> > >>
>> > >> I remember seeing some discussion about keeping
> serialization support
>> > in
>> > > the
>> > >> API, or dropping it and letting the user handle this in his
> code.
>> > >>
>> > >> Should we keep it or drop it? :)
>> > >>
>> > >> If we decide to keep it:
>> > >>
>> > >> - PredicatedLoop serializable but some of its members are
> not. We
>> could
>> > > make
>> > >> them implement Serializable or use writeObject and
> readObject. If we
>> > went
>> > > with
>> > >> the former, a series of other changes would be required as
> well
>> (Limit
>> > and
>> > >> Offset don't implement equals or hashcode, for instance,
> and are used
>> > > in
>> > >> some tests of algorithms). The latter choice would require
> attention
>> in
>> > > case
>> > >> someone changed the object members (adding/removing/...).
>> > >>
>> > >> - Probably there are other classes in the same situation,
> then these
>> > > classes
>> > >> would have to be updated as well.
>> > >>
>> > >> If we decide to drop the serialization support in [functor]
> API:
>> > >>
>> > >> - Users would have to handle serialization in their code.
>> > >>
>> > >> - We would have to refactor many functors
>> > >>
>> > >> - The BaseFunctorTest methods related to serialization would
> be
>> removed
>> > >>
>> > >> - Javadoc would have to be updated in some classes as well
>> > >>
>> > >> Many thanks in advance.
>> > >>
>> > >> -- Bruno P. Kinoshita
>> > >> http://www.kinoshita.eti.br
>> > >> http://www.tupilabs.com
>> > >>
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [functor] Keep Serializable in [functor] or drop it?
Posted by Matt Benson <gu...@gmail.com>.
Sure, go ahead. :)
Matt
On Thu, Oct 31, 2013 at 1:25 AM, Benedikt Ritter <br...@apache.org> wrote:
> Makes sense for me t dro serialization support for 1.0. If users really
> demand it, it can be added afterwards.
>
> Benedikt
>
> 2013/10/31 Bruno P. Kinoshita <br...@yahoo.com.br>
>
> > Hi all,
> >
> > I posted it in the mailing list some time ago and now I will have time to
> > work on this during the next days. I've flled FUNCTOR-29 to work on this.
> > Let me know if there are any objections to this.
> >
> > Thanks!
> >
> > [1] https://issues.apache.org/jira/browse/FUNCTOR-29
> >
> > Bruno P. Kinoshita
> > http://kinoshita.eti.br
> > http://tupilabs.com
> >
> >
> > ----- Original Message -----
> > > From: Bruno P. Kinoshita <ki...@apache.org>
> > > To: Commons List <de...@commons.apache.org>
> > > Cc:
> > > Sent: Monday, February 11, 2013 9:24 PM
> > > Subject: Re: [functor] Keep Serializable in [functor] or drop it?
> > >
> > > Hi all,
> > >
> > > Any objections to removing serialization from [functor]? Here's why I
> > think
> > > we should drop it:
> > >
> > > * It's been discussed in the mailing list in the past about other
> > components
> > > dropping support to serialization, I think [math] already had problems
> > > maintaining compatibility+serialization [1]
> > >
> > > * There are classes that create internal objects that, although not
> > exposed to
> > > the users, would have to be serialized or treated before being
> > serialized. e.g.:
> > > IsEquivalent has a Comparator field, that is passed in the constructor.
> > When no
> > > comparator is given, it uses a comparator that is bundled in [functor]
> > > (ComparableComparator) that implements Serializable. But if a user
> wrote
> > code
> > > like the below, it would raise an exception:
> > >
> > > IsEquivalent<Double> isEq = new IsEquivalent<Double>(new
> > > Comparator<Double>() { // not serializable
> > > public int compare(Double o1, Double o2) {
> > > return (o1>o2 ? -1 : (o1==o2 ? 0 : 1));
> > > }
> > > });
> > > System.out.println(isEq.test(1.0, 2.0));
> > > System.out.println(isEq.test(1.0, 1.0));
> > > try {
> > > ByteArrayOutputStream bos = new ByteArrayOutputStream();
> > > ObjectOutputStream out = new ObjectOutputStream(bos);
> > >
> > > out.writeObject(isEq);
> > > } catch (Exception e) {
> > > throw new AssertionError(e);
> > > }
> > >
> > > * A user may create a recursive function with several levels (think of
> > thousands
> > > of levels for this example, and see RecursiveEvaluation too). This
> could
> > cause a
> > > StackOverFlow since "the default serialization procedure performs a
> > > recursive traversal of the object graph" (Bloch).
> > >
> > > * Also, there are classes in aggregator that don't support
> serialization
> > yet
> > > (see o.a.c.functor.aggregator).
> > >
> > > Thoughts on this? I've removed the serialization feature from [functor]
> > in
> > > my GitHub mirror, and the only major change required was removing
> > existing tests
> > > that handled serialization. Thus, the number of tests decreased to less
> > than
> > > 1000 (we have now _only_ ~900 :-).
> > >
> > > Most of the existing classes have a paragraph about serialization, but
> > some
> > > don't (e.g.: IsEquivalent). If we don't drop serialization, I'll fix
> > > that in the classes missing that paragraph. I intend to use [functor]
> > with
> > > Jenkins plug-ins, where serialization (and commons-jelly!) is used a
> lot
> > (it
> > > sends objects to the slaves), but I prefer to write proxies or some
> > other trick
> > > to serialize my functions, than have to deal with problems with
> different
> > > versions of [functor] :-)
> > >
> > > Thanks!
> > >
> > > [1] http://markmail.org/thread/3dpionbxkzyktrno
> > >
> > > Bruno P. Kinoshita
> > > http://kinoshita.eti.br
> > > http://tupilabs.com
> > >
> > >
> > > ----- Original Message -----
> > >> From: Bruno P. Kinoshita <br...@yahoo.com.br>
> > >> To: Commons Developers List <de...@commons.apache.org>
> > >> Cc:
> > >> Sent: Monday, April 9, 2012 1:55 PM
> > >> Subject: [functor] Keep Serializable in [functor] or drop it?
> > >>
> > >> Hi all,
> > >>
> > >> I was writing some tests for [functor] when I found that one of my
> > tests
> > > was
> > >> failing with a NotSerializableException. The test uses a class that
> > extends
> > >
> > >> PredicatedLoop. This class contains a Procedure and a Predicate
> member
> > > fields,
> > >> which are not serializable.
> > >>
> > >> I remember seeing some discussion about keeping serialization support
> > in
> > > the
> > >> API, or dropping it and letting the user handle this in his code.
> > >>
> > >> Should we keep it or drop it? :)
> > >>
> > >> If we decide to keep it:
> > >>
> > >> - PredicatedLoop serializable but some of its members are not. We
> could
> > > make
> > >> them implement Serializable or use writeObject and readObject. If we
> > went
> > > with
> > >> the former, a series of other changes would be required as well
> (Limit
> > and
> > >> Offset don't implement equals or hashcode, for instance, and are used
> > > in
> > >> some tests of algorithms). The latter choice would require attention
> in
> > > case
> > >> someone changed the object members (adding/removing/...).
> > >>
> > >> - Probably there are other classes in the same situation, then these
> > > classes
> > >> would have to be updated as well.
> > >>
> > >> If we decide to drop the serialization support in [functor] API:
> > >>
> > >> - Users would have to handle serialization in their code.
> > >>
> > >> - We would have to refactor many functors
> > >>
> > >> - The BaseFunctorTest methods related to serialization would be
> removed
> > >>
> > >> - Javadoc would have to be updated in some classes as well
> > >>
> > >> Many thanks in advance.
> > >>
> > >> -- Bruno P. Kinoshita
> > >> http://www.kinoshita.eti.br
> > >> http://www.tupilabs.com
> > >>
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
Re: [functor] Keep Serializable in [functor] or drop it?
Posted by Benedikt Ritter <br...@apache.org>.
Makes sense for me t dro serialization support for 1.0. If users really
demand it, it can be added afterwards.
Benedikt
2013/10/31 Bruno P. Kinoshita <br...@yahoo.com.br>
> Hi all,
>
> I posted it in the mailing list some time ago and now I will have time to
> work on this during the next days. I've flled FUNCTOR-29 to work on this.
> Let me know if there are any objections to this.
>
> Thanks!
>
> [1] https://issues.apache.org/jira/browse/FUNCTOR-29
>
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
>
> ----- Original Message -----
> > From: Bruno P. Kinoshita <ki...@apache.org>
> > To: Commons List <de...@commons.apache.org>
> > Cc:
> > Sent: Monday, February 11, 2013 9:24 PM
> > Subject: Re: [functor] Keep Serializable in [functor] or drop it?
> >
> > Hi all,
> >
> > Any objections to removing serialization from [functor]? Here's why I
> think
> > we should drop it:
> >
> > * It's been discussed in the mailing list in the past about other
> components
> > dropping support to serialization, I think [math] already had problems
> > maintaining compatibility+serialization [1]
> >
> > * There are classes that create internal objects that, although not
> exposed to
> > the users, would have to be serialized or treated before being
> serialized. e.g.:
> > IsEquivalent has a Comparator field, that is passed in the constructor.
> When no
> > comparator is given, it uses a comparator that is bundled in [functor]
> > (ComparableComparator) that implements Serializable. But if a user wrote
> code
> > like the below, it would raise an exception:
> >
> > IsEquivalent<Double> isEq = new IsEquivalent<Double>(new
> > Comparator<Double>() { // not serializable
> > public int compare(Double o1, Double o2) {
> > return (o1>o2 ? -1 : (o1==o2 ? 0 : 1));
> > }
> > });
> > System.out.println(isEq.test(1.0, 2.0));
> > System.out.println(isEq.test(1.0, 1.0));
> > try {
> > ByteArrayOutputStream bos = new ByteArrayOutputStream();
> > ObjectOutputStream out = new ObjectOutputStream(bos);
> >
> > out.writeObject(isEq);
> > } catch (Exception e) {
> > throw new AssertionError(e);
> > }
> >
> > * A user may create a recursive function with several levels (think of
> thousands
> > of levels for this example, and see RecursiveEvaluation too). This could
> cause a
> > StackOverFlow since "the default serialization procedure performs a
> > recursive traversal of the object graph" (Bloch).
> >
> > * Also, there are classes in aggregator that don't support serialization
> yet
> > (see o.a.c.functor.aggregator).
> >
> > Thoughts on this? I've removed the serialization feature from [functor]
> in
> > my GitHub mirror, and the only major change required was removing
> existing tests
> > that handled serialization. Thus, the number of tests decreased to less
> than
> > 1000 (we have now _only_ ~900 :-).
> >
> > Most of the existing classes have a paragraph about serialization, but
> some
> > don't (e.g.: IsEquivalent). If we don't drop serialization, I'll fix
> > that in the classes missing that paragraph. I intend to use [functor]
> with
> > Jenkins plug-ins, where serialization (and commons-jelly!) is used a lot
> (it
> > sends objects to the slaves), but I prefer to write proxies or some
> other trick
> > to serialize my functions, than have to deal with problems with different
> > versions of [functor] :-)
> >
> > Thanks!
> >
> > [1] http://markmail.org/thread/3dpionbxkzyktrno
> >
> > Bruno P. Kinoshita
> > http://kinoshita.eti.br
> > http://tupilabs.com
> >
> >
> > ----- Original Message -----
> >> From: Bruno P. Kinoshita <br...@yahoo.com.br>
> >> To: Commons Developers List <de...@commons.apache.org>
> >> Cc:
> >> Sent: Monday, April 9, 2012 1:55 PM
> >> Subject: [functor] Keep Serializable in [functor] or drop it?
> >>
> >> Hi all,
> >>
> >> I was writing some tests for [functor] when I found that one of my
> tests
> > was
> >> failing with a NotSerializableException. The test uses a class that
> extends
> >
> >> PredicatedLoop. This class contains a Procedure and a Predicate member
> > fields,
> >> which are not serializable.
> >>
> >> I remember seeing some discussion about keeping serialization support
> in
> > the
> >> API, or dropping it and letting the user handle this in his code.
> >>
> >> Should we keep it or drop it? :)
> >>
> >> If we decide to keep it:
> >>
> >> - PredicatedLoop serializable but some of its members are not. We could
> > make
> >> them implement Serializable or use writeObject and readObject. If we
> went
> > with
> >> the former, a series of other changes would be required as well (Limit
> and
> >> Offset don't implement equals or hashcode, for instance, and are used
> > in
> >> some tests of algorithms). The latter choice would require attention in
> > case
> >> someone changed the object members (adding/removing/...).
> >>
> >> - Probably there are other classes in the same situation, then these
> > classes
> >> would have to be updated as well.
> >>
> >> If we decide to drop the serialization support in [functor] API:
> >>
> >> - Users would have to handle serialization in their code.
> >>
> >> - We would have to refactor many functors
> >>
> >> - The BaseFunctorTest methods related to serialization would be removed
> >>
> >> - Javadoc would have to be updated in some classes as well
> >>
> >> Many thanks in advance.
> >>
> >> -- Bruno P. Kinoshita
> >> http://www.kinoshita.eti.br
> >> http://www.tupilabs.com
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter