commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <benerit...@gmail.com>
Subject Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src: main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Date Mon, 02 Sep 2013 17:49:08 GMT
Hey,

sorry if I missunderstood your opinions (Gary and James).
So do we call for a [VOTE]? I've never seen a vote thread for design
related decisions so far.

Benedikt


2013/9/2 James Carman <james@carmanconsulting.com>

> I meant re-visit the decision to make sure we took everything into
> consideration when choosing which way to go in this case.  I say we
> leave [lang] alone at this point.
>
>
> On Mon, Sep 2, 2013 at 11:41 AM, Matt Benson <gudnabrsam@gmail.com> wrote:
> > How do you mean, "revisit?" I think changing [lang] at this late date
> would
> > be more trouble than it's worth.
> >
> > Matt
> > On Sep 1, 2013 1:31 PM, "James Carman" <james@carmanconsulting.com>
> wrote:
> >
> >> I favor IAE, but I want to make sure we re-visit the decision made for
> >> [lang] when it chose to use NPE instead.
> >>
> >> On Sun, Sep 1, 2013 at 1:37 PM, Gary Gregory <garydgregory@gmail.com>
> >> wrote:
> >> > It feels to me that this misrepresents the ideas expressed here, or at
> >> > least mine ;) I am neither indifferent or favor NPE. I favor IAE, so
> >> > does that mean I am nor "most people". If a person make these kinds of
> >> > statement, we might as well VOTE or argue-discuss some more...!
> >> >
> >> > Gary
> >> >
> >> > On Sep 1, 2013, at 10:46, Benedikt Ritter <britter@apache.org> wrote:
> >> >
> >> >> Look's like most people are either indifferent or favor NPE. So, do
> we
> >> >> change this for [CSV]? The important thing is to give users an
> >> expressive
> >> >> message.
> >> >>
> >> >> Benedikt
> >> >>
> >> >>
> >> >>
> >> >> 2013/8/30 Gary Gregory <garydgregory@gmail.com>
> >> >>
> >> >>> Surprisingly, a lot. At work, we have a lot of
> frameworky/plugin-type
> >> of
> >> >>> code where we run operations on collections of things and we do
not
> >> want
> >> >>> "expected" errors to torpedo the whole processing flow, so we do
> catch
> >> >>> things like IAE and ISE. We do try to avoid catching Exception
if we
> >> can
> >> >>> help it.
> >> >>>
> >> >>> Gary
> >> >>>
> >> >>>
> >> >>> On Fri, Aug 30, 2013 at 2:32 PM, Matt Benson <gudnabrsam@gmail.com>
> >> wrote:
> >> >>>
> >> >>>> How often do you really want to catch these?
> >> >>>>
> >> >>>> Matt
> >> >>>>
> >> >>>>
> >> >>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <
> garydgregory@gmail.com
> >> >>>>> wrote:
> >> >>>>
> >> >>>>> Another perspective to think about is whether you want
to write
> code
> >> >>>> like:
> >> >>>>>
> >> >>>>> try {
> >> >>>>>  // la-di-da
> >> >>>>> } catch (NullPointerException e) {
> >> >>>>>  // garbage in!
> >> >>>>> }
> >> >>>>>
> >> >>>>> or:
> >> >>>>>
> >> >>>>> try {
> >> >>>>>  // doo-wap-doo-wap
> >> >>>>> } catch (IllegalArugumentException e) {
> >> >>>>>  // garbage in!
> >> >>>>> }
> >> >>>>>
> >> >>>>> Catching NPE just smells funny to me.
> >> >>>>>
> >> >>>>> Gary
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> On Fri, Aug 30, 2013 at 1:06 PM, sebb <sebbaz@gmail.com>
wrote:
> >> >>>>>
> >> >>>>>> The fact that NPE is documented in Bloch is quite important.
> >> >>>>>>
> >> >>>>>> Whatever we do choose, we should make sure to document
all th
> >> reasons
> >> >>>>>> (pros and cons) somewhere other than just the mailing
list!
> >> >>>>>>
> >> >>>>>> On 30 August 2013 17:30, Matt Benson <gudnabrsam@gmail.com>
> wrote:
> >> >>>>>>> The discussion for [lang], none of whose participants
have
> weighed
> >> >>> in
> >> >>>>>> here,
> >> >>>>>>> took place in late 2009 (so perhaps a little longer
ago than I
> >> >>>> thought)
> >> >>>>>> and
> >> >>>>>>> is archived at [1].  IMO Paul B. makes some pretty
compelling
> >> >>>> arguments
> >> >>>>>> in
> >> >>>>>>> [2].
> >> >>>>>>>
> >> >>>>>>> Matt
> >> >>>>>>>
> >> >>>>>>> [1] http://markmail.org/thread/7gw7xzrc3c3ul74c
> >> >>>>>>> [2] http://markmail.org/message/wmc4jh4pmhjjtxdf
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> On Fri, Aug 30, 2013 at 11:13 AM, sebb <sebbaz@gmail.com>
> wrote:
> >> >>>>>>>
> >> >>>>>>>> The JDK Javadoc says of NPE:
> >> >>>>>>>>
> >> >>>>>>>> * Applications should throw instances of this
class to indicate
> >> >>>>>>>> * other illegal uses of the <code>null</code>
object.
> >> >>>>>>>>
> >> >>>>>>>> and of IAE:
> >> >>>>>>>>
> >> >>>>>>>> * Thrown to indicate that a method has been
passed an illegal
> or
> >> >>>>>>>> * inappropriate argument.
> >> >>>>>>>>
> >> >>>>>>>> That says to me that we should throw IAE here.
> >> >>>>>>>>
> >> >>>>>>>> The JDK does use NPE for parameter checks,
but it also uses
> IAE,
> >> >>> for
> >> >>>>>>>> example:
> >> >>>>>>>>
> >> >>>>>>>> javax.management.monitor.Monitor.addObservedObject
> >> >>>>>>>> java.rmi.activation.ActivationDesc.ActivationDesc
> >> >>>>>>>> javax.management.relation.RoleList.add
> >> >>>>>>>> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
> >> >>>>>>>>
> >> >>>>>>>> On 30 August 2013 16:50, Adrian Crum <
> >> >>>>>> adrian.crum@sandglass-software.com>
> >> >>>>>>>> wrote:
> >> >>>>>>>>> I've seen a lot of discussions on NPE versus
IAE, and in the
> end
> >> >>>>> they
> >> >>>>>> all
> >> >>>>>>>>> condense down to what Matt stated here:
Those who favor NPE
> cite
> >> >>>> the
> >> >>>>>> JDK
> >> >>>>>>>>> classes as a pattern to follow, and those
who favor IAE say it
> >> >>> is
> >> >>>> a
> >> >>>>>>>> better
> >> >>>>>>>>> description of the problem. From my perspective,
both are
> valid
> >> >>>>>>>> viewpoints,
> >> >>>>>>>>> and a project simply needs to choose one.
In the end, the
> choice
> >> >>>> is
> >> >>>>>>>> neither
> >> >>>>>>>>> "right" nor "wrong" - it is just a choice.
> >> >>>>>>>>>
> >> >>>>>>>>> -Adrian
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> On 8/30/2013 8:07 AM, Matt Benson wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>> Let me stir the pot:
> >> >>>>>>>>>>   At a fundamental level I agree that
a required *argument*
> >> >>>> should
> >> >>>>>>>> throw
> >> >>>>>>>>>> an
> >> >>>>>>>>>> IllegalArgumentException when null
is supplied.  However,
> ISTR
> >> >>>> the
> >> >>>>>>>>>> decision
> >> >>>>>>>>>> to do otherwise in [lang] having been
discussed on-list in
> the
> >> >>>>>>>>>> not-so-distant past, and the result
of that discussion being
> >> >>> that
> >> >>>>>> NPE is
> >> >>>>>>>>>> usually the result in the core JDK
classes.  So I wouldn't
> >> >>>>>> characterize
> >> >>>>>>>>>> the
> >> >>>>>>>>>> situation as "[lang] *just happens*
to throw NPE."  Now,
> [lang]
> >> >>>> is
> >> >>>>>> in a
> >> >>>>>>>>>> slightly unique situation as its stated
mission is to
> >> >>> complement
> >> >>>>> Java
> >> >>>>>>>> SE,
> >> >>>>>>>>>> so it could be argued that [lang] is
under greater pressure
> to
> >> >>>>>> conform
> >> >>>>>>>> for
> >> >>>>>>>>>> that reason.  But my personal preference,
in light of the
> >> >>>> standing
> >> >>>>>>>>>> decision
> >> >>>>>>>>>> with [lang], would be for consistency
throughout Commons
> >> >>>> components
> >> >>>>>>>>>> *despite* the fact that at a purely
semantic level I agree
> with
> >> >>>> the
> >> >>>>>>>>>> arguments in favor of IllegalArgumentException.
> >> >>>>>>>>>>
> >> >>>>>>>>>> To summarize, +1 for NullPointerException
from me.
> >> >>>>>>>>>>
> >> >>>>>>>>>> Matt
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt
Ritter <
> >> >>>>> britter@apache.org
> >> >>>>>>>
> >> >>>>>>>>>> wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>>> 2013/8/30 sebb <sebbaz@gmail.com>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>> On 30 August 2013 15:19, Benedikt
Ritter <
> britter@apache.org
> >> >>>>
> >> >>>>>> wrote:
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> I've removed the generics
in r1518974, thanks for spotting
> >> >>>> that
> >> >>>>>> sebb.
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> Regarding the exception
to throw I'm indifferent. The
> >> >>>> important
> >> >>>>>> thing
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> is
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> to
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> fail early.
> >> >>>>>>>>>>>> ... and with a helpful message.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>> I personally thing that
NPE should be reserved for
> signaling
> >> >>>>> that
> >> >>>>>>>> some
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> code
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> tried to invoke a method
on a null reference.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> +1
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>> In our case null is illegal
because we know that some code
> >> >>>> later
> >> >>>>>> on
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> would
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> break if we accept a null
reference. So
> >> >>> IllegalStateException
> >> >>>>>> makes
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> sense.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> s/IllegalStateException /IllegalArgumentException/
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> +1
> >> >>>>>>>>>>> Sorry, I meant IAE of corse.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>>> Imaging having a method
that accepts an int and only
> >> >>> positive
> >> >>>>> ints
> >> >>>>>>>> are
> >> >>>>>>>>>>>>> valid. You would throw
an IllegalArgumentException if a
> >> >>>> negative
> >> >>>>>> int
> >> >>>>>>>> is
> >> >>>>>>>>>>>>> passed to that method and
not a NegativeIntegerException
> (or
> >> >>>>> what
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> ever).
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> But James has a point.
If [LANG] uses NPE maybe we should
> >> >>>> stick
> >> >>>>> to
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> this.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> I don't think we have to do
the same as LANG, so long as
> the
> >> >>>>>> Javadoc
> >> >>>>>>>> is
> >> >>>>>>>>>>>> clear.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>> Feel free to change it.
I'll leave it for now since there
> >> >>>>> doesn't
> >> >>>>>>>> seem
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> to
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> be consensus?!
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> Unless there are other reasons
than "LANG happens to use
> >> >>> NPE" I
> >> >>>>>> think
> >> >>>>>>>>>>>> we should stick with IAE, as
it more clearly indicates the
> >> >>> the
> >> >>>>>> problem
> >> >>>>>>>>>>>> is not within the method throwing
it.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> The problem with using NPE
to flag parameter errors is that
> >> >>> it
> >> >>>>>>>>>>>> confuses the user as to the
likely cause.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> Leave NPEs to the runtime system.
> >> >>>>>>>>>>> agreed.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>>> Benedikt
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> 2013/8/30 James Carman
<james@carmanconsulting.com>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> Well, the problem with
using NPE is that we as Java
> >> >>>> developers
> >> >>>>>> have
> >> >>>>>>>>>>>>>> learned through the
years that NPE typically is an "oh
> >> >>> crap"
> >> >>>>>>>>>>>>>> situation, where something
is terribly wrong (we hate
> >> >>> seeing
> >> >>>>>> those).
> >> >>>>>>>>>>>>>> Thus, our users may
have knee-jerk reactions and not even
> >> >>>> know
> >> >>>>> to
> >> >>>>>>>>>>>>>> inspect the message
for the real cause.  IAE is less
> >> >>>> alarming,
> >> >>>>>> IMHO.
> >> >>>>>>>>>>>>>> Just my $0.02, but
we've been doing it that way for a
> long
> >> >>>> time
> >> >>>>>> in
> >> >>>>>>>>>>>>>> [lang], so be it.
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> On Fri, Aug 30, 2013
at 9:01 AM, sebb <sebbaz@gmail.com>
> >> >>>>> wrote:
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> AFAIK "accidental"
NPEs don't have a message associated
> >> >>> with
> >> >>>>>> them.
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> So provided that
the assertion generates the NPE with a
> >> >>>>> suitable
> >> >>>>>>>>>>>>>>> message (e.g.as
currently done for the IAE) then it
> >> >>>> *should*
> >> >>>>> be
> >> >>>>>>>>>>>>>>> possible for the
end user to distinguish the two cases.
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> I am slightly in
favour of retaining IAE as the cause is
> >> >>>>> obvious
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> with
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> needing to look
at the NPE message.
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> ==
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> Horrible hack:
- if you want to use NPE, you could wrap
> an
> >> >>>> IAE
> >> >>>>>> in
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> the
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> NPE:
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> npe = new NPE(msg);
> >> >>>>>>>>>>>>>>> npe.initCause(new
IAE(msg));
> >> >>>>>>>>>>>>>>> throw npe;
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> Or vice-vera, of
course!
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> Not sure that gains
anything, but it does make the stack
> >> >>>> trace
> >> >>>>>> look
> >> >>>>>>>>>>>>>>> more impressive!
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> On 30 August 2013
13:42, James Carman <
> >> >>>>>> james@carmanconsulting.com>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> wrote:
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> Commons Lang's
Validate.notNull() throws NPEs.  I don't
> >> >>>> know
> >> >>>>>> that
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> I've
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> necessarily
agreed with that, but at some point a
> >> >>> decision
> >> >>>>> was
> >> >>>>>>>> made
> >> >>>>>>>>>>>>>>>> that null constraint
violations should throw NPEs.
>  Food
> >> >>>> for
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> thought.
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> On Fri, Aug
30, 2013 at 8:32 AM, Gary Gregory <
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> garydgregory@gmail.com>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> wrote:
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> On Fri,
Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> ebourg@apache.org>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> wrote:
> >> >>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>
+        if (parameter == null) {
> >> >>>>>>>>>>>>>>>>>>>>
+            throw new
> >> >>>>> IllegalArgumentException("Parameter
> >> >>>>>> '"
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> +
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>> parameterName
+ "' must not be null!");
> >> >>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>
+        }
> >> >>>>>>>>>>>>>>>>>>>>
+    }
> >> >>>>>>>>>>>>>>>>>>>>
+}
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>> Isn't
a null value supposed to throw a NPE ?
> >> >>>>>>>>>>>>>>>>> Not always
IMO. When I see an NPE I assume something
> is
> >> >>>> very
> >> >>>>>>>> wrong
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> and
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> that
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> it could
be a bug in the impl OR a call site,
> somewhere
> >> >>> on
> >> >>>>> the
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> code
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> path.
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> With an
IAE, I know for sure it's a problem in the
> call
> >> >>>> site
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> (which
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> could
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> be a bug
of course).
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> I does
not help that the JRE/JDK is inconsistent, so
> >> >>> it's
> >> >>>>>> hard to
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> find
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> examples.
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> Gary
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>> Emmanuel
Bourg
> >> >>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>> To
unsubscribe, e-mail:
> >> >>>> dev-unsubscribe@commons.apache.org
> >> >>>>>>>>>>>>>>>>>> For
additional commands, e-mail:
> >> >>>>> dev-help@commons.apache.org
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> --
> >> >>>>>>>>>>>>>>>>> E-Mail:
garydgregory@gmail.com | ggregory@apache.org
> >> >>>>>>>>>>>>>>>>> Java Persistence
with Hibernate, Second Edition<
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> http://www.manning.com/bauer3/>
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> JUnit in
Action, Second Edition <
> >> >>>>>>>> http://www.manning.com/tahchiev/
> >> >>>>>>>>>>>>>>>>> Spring
Batch in Action <
> >> >>> http://www.manning.com/templier/>
> >> >>>>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
> >> >>>>>>>>>>>>>>>>> Home: http://garygregory.com/
> >> >>>>>>>>>>>>>>>>> Tweet!
http://twitter.com/GaryGregory
> >> >>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> 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
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> --
> >> >>>>>>>>>>>>> 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
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> --
> >> >>>>>>>>>>> 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
> >> >>>>
> ---------------------------------------------------------------------
> >> >>>>>>>> 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
> >> >>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >>>>> Java Persistence with Hibernate, Second Edition<
> >> >>>>> http://www.manning.com/bauer3/>
> >> >>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/
> >
> >> >>>>> Spring Batch in Action <http://www.manning.com/templier/>
> >> >>>>> Blog: http://garygregory.wordpress.com
> >> >>>>> Home: http://garygregory.com/
> >> >>>>> Tweet! http://twitter.com/GaryGregory
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >>> Java Persistence with Hibernate, Second Edition<
> >> >>> http://www.manning.com/bauer3/>
> >> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> >>> Spring Batch in Action <http://www.manning.com/templier/>
> >> >>> Blog: http://garygregory.wordpress.com
> >> >>> Home: http://garygregory.com/
> >> >>> Tweet! http://twitter.com/GaryGregory
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> 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
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message