commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [Math] Utilitzation of SLF4J?
Date Mon, 28 Sep 2015 17:37:03 GMT
On Mon, Sep 28, 2015 at 10:29 AM, Siegfried Goeschl <
siegfried.goeschl@it20one.com> wrote:

> Hi folks,
>
> as far as I understand the mail thread (while not being a Commons Math
> developer)
>
> * logging could be helpful but it could be argued/reasoned that logging is
> not required for an utility package
> * there is no perfect logging framework for all use-cases and deployments
> * Apache Commons strive for minimal dependencies
>

That's not a good requirement IMO or it is not well stated, not sure. The
Log4j 2 API and Commons Logging API are both a single jar. Both need a
backing implementation.


>
> One thing I did in the past is to add a dummy singleton logger
> implementation which can be replaced by the user of the library
>

So may projects do this, and it's lame; the extra layer invariably is
either not that good and affects the quality of the logging, or grows to
imitate another logging API.

To make matters worse, it's another thing to configure and provide custom
code with to bridge to your logging framework of choice, unless the project
provides an implementation for your logging API of choice.

IOW, pick a logging API (except JUL).

Whether or not a component should log is another matter! ;-)

Gary


>
> * The dummy implementation will do nothing
> * Adding another level of indirection will not win a software engineering
> award
> * Having a singleton could be an issue if multiple parties within the
> deployed application is using Commons Math
> * Replacing the dummy logging stub with you logging framework of choice is
> a bit tedious
>
> In other words - it is not beautiful implementation but could be
> reasonable work-around to make our two camps happy (or both unhappy)
>
> Cheers,
>
> Siegfried Goeschl
>
>
> > On 27 Sep 2015, at 04:05, Romain Manni-Bucau <rmannibucau@gmail.com>
> wrote:
> >
> > Le 26 sept. 2015 15:19, "Ralph Goers" <ralph.goers@dslextreme.com> a
> écrit :
> >>
> >> Romain,
> >>
> >> Choosing JUL for a framework does a HUGE disservice to the users of your
> > framework. JUL is by far the worst logging framework design of anything
> you
> > could choose. It is like the JDK designers purposely chose to use a
> > mechanism to map their API to another implementation that really doesn’t
> > work.  SLF4J handles this by not bypassing it and using a JUL handler to
> > map everything into it, and then uses an “interesting” scheme to try to
> > make that perform well. Log4j tries to use the method documented by JUL
> but
> > it has a few problems.
> >>
> >
> > It is contextual, slf4j with its classloader handling is the worse for
> > other users...all analyzis lead to a really "common" lib shouldnt rely on
> > any logging API IMHO.
> >
> >> Ralph
> >>
> >>> On Sep 26, 2015, at 12:49 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >>>
> >>> Le 26 sept. 2015 12:07, "Luc Maisonobe" <luc@spaceroots.org <mailto:
> > luc@spaceroots.org>> a écrit :
> >>>>
> >>>> Le 26/09/2015 20:59, Ralph Goers a écrit :
> >>>>> I don’t normally participate in Math but I do feel the need to
stick
> > my
> >>> nose in here.
> >>>>> 1. You are absolutely correct to determine whether you need logging
> at
> >>> all before discussing what to choose.
> >>>>> 2. If you do decide logging is required:
> >>>>> a. Please stay away from java.util.logging. It really would be the
> >>> best solution for a framework like math except it is extremely
> > difficult to
> >>> redirect efficiently to some other logging framework. The methods used
> > by
> >>> SLF4J and Log4j are imperfect to say the least.
> >>>>> b. Log4j 1.x has reached eol. It effectively has not been supported
> >>> for 5 years.
> >>>>> c. Log4j 2 has an API that can be redirected to another logging
> >>> framework if desired.
> >>>>> d. Commons logging still works but its API is very primitive by
> >>> todays standards. That said, it does work.
> >>>>
> >>>> From what I have seen, if I ever were to choose a logging framework
> for
> >>>> any project, I agree log4j 2 is currently the best choice. I was
> >>>> impressed by slf4j a few years ago, but think now the step further is
> >>>> log4j 2 (without any accurate reason, just a rough feeling).
> >>>>
> >>>
> >>> And in 2 years foolog4j will be better. JUL is not perfect for sure but
> >>> ensures:
> >>> - no dep
> >>> - always usable
> >>> - allows to let the user integrate with the lib without having to fork
> > it
> >>> to get rid of a logging dep - think to tomee which consumes N commons
> > deps,
> >>> if all uses a different logging framework it is worse to configure and
> >>> highly inconsistent - that is why we chose jul by default
> >>>
> >>> That is for the logging framework choice.
> >>> Now commons shouldnt log much IMO otherwise it would start to loose
> > commons
> >>> in sense of shareable component cause of the integration issues it
> >>> generates in the final application.
> >>>
> >>> - Romain
> >>>
> >>>> best regards,
> >>>> Luc
> >>>>
> >>>>>
> >>>>> Ralph
> >>>>>
> >>>>>
> >>>>>> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe <luc@spaceroots.org>
> > wrote:
> >>>>>>
> >>>>>> Le 26/09/2015 18:42, Gilles a écrit :
> >>>>>>> On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:
> >>>>>>>> On 9/26/15 4:56 AM, Thomas Neidhart wrote:
> >>>>>>>>> On 09/26/2015 01:11 PM, Gilles wrote:
> >>>>>>>>>> On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart
wrote:
> >>>>>>>>>>> On 09/26/2015 02:33 AM, Gilles wrote:
> >>>>>>>>>>>> On Fri, 25 Sep 2015 16:52:26 -0700,
Hasan Diwan wrote:
> >>>>>>>>>>>>> On 25 September 2015 at 16:47, Gilles
<
> >>> gilles@harfang.homelinux.org>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Fri, 25 Sep 2015 17:30:33
+0200, Thomas Neidhart wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Fri, Sep 25, 2015 at
5:09 PM, Gilles
> >>>>>>>>>>>>>>> <gilles@harfang.homelinux.org>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Fri, 25 Sep 2015 07:28:48
-0700, Phil Steitz wrote:
> >>>>>>>>>>>>>>>> On 9/25/15 7:03 AM,
Gilles wrote:
> >>>>>>>>>>>>>>>>> On Fri, 25 Sep 2015
15:54:14 +0200, Thomas Neidhart
> wrote:
> >>>>>>>>>>>>>>>>>> Hi Ole,
> >>>>>>>>>>>>>>>>>>> for a start,
I think you are asking the wrong question.
> >>>>>>>>>>>>>>>>>>> First of
all we need to agree that we want to add some
> >>> kind of
> >>>>>>>>>>>>>>>>>>> logging
> >>>>>>>>>>>>>>>>>>> facility
to CM.
> >>>>>>>>>>>>>>>>>>> If the outcome
is positive, there are a handful of
> >>>>>>>>>>>>>>>>>>> alternatives,
> >>>>>>>>>>>>>>>>>>> some of
> >>>>>>>>>>>>>>>>>>> them more
viable than slf4j in the context of CM (e.g.
> >>> JUL or
> >>>>>>>>>>>>>>>>>>> commons-logging).
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Could someone
summarize why those alternatives were
> > deemed
> >>>>>>>>>>>>>>>>>> "more
> >>>>>>>>>>>>>>>>>> viable"?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> btw. the same
discussion has been done for other commons
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> components
as
> >>>>>>>>>>>>>>>>>>> well, and
the result usually was: do not add logging
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> What was the
rationale?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Look at the archives.
 We have discussed this multiple
> > times
> >>>>>>>>>>>>>>>>> in the
> >>>>>>>>>>>>>>>>> past in [math] and
each time came to the conclusion that
> >>> Thomas
> >>>>>>>>>>>>>>>>> succinctly states
above.  What has changed now?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> We also discussed several
times to stick with Java 5.
> >>>>>>>>>>>>>>>> Fortunately, that has
changed. [Although sticking with
> Java
> >>> 7 is
> >>>>>>>>>>>>>>>> still
> >>>>>>>>>>>>>>>> a bad decision IMHO.]
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> As for logging, IIRC,
the sole argument was "no
> dependency"
> >>>>>>>>>>>>>>>> because
> >>>>>>>>>>>>>>>> (IIRC) of the potential
"JAR hell".
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> that's not correct. The
decision to not include any
> >>>>>>>>>>>>>>> dependencies has
> >>>>>>>>>>>>>>> nothing to do with "JAR
hell".
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Although I can't find it now,
I'm pretty sure that I more
> > than
> >>> once
> >>>>>>>>>>>>>> got such an answer.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> In order to prevent JAR hell,
commons components strictly
> > stick
> >>>>>>>>>>>>>> to the
> >>>>>>>>>>>>>>> "Versioning guidelines"
[1]
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I can't see how it relates.
> >>>>>>>>>>>>>> But if you mean that no JAR
hell can emerge from using a
> >>> logging
> >>>>>>>>>>>>>> framework,
> >>>>>>>>>>>>>> then that's good news.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The no-dependency rule is more
related to the proposal of
> the
> >>>>>>>>>>>>>> component,
> >>>>>>>>>>>>>>> see [2]
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks for the reminder; in
that document, we read:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> (1) Scope of the Package
> >>>>>>>>>>>>>> [...]
> >>>>>>>>>>>>>> 5. Limited dependencies. No
external dependencies beyond
> >>> Commons
> >>>>>>>>>>>>>> components and the JDK
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> So we are fine if use "Log4j
2" as kindly offered by Gary.
> >>>>>>>>>>> log4j is not a commons component btw.
> >>>>>>>>>> Too bad for me. :-/
> >>>>>>>>>> Case resolved, then, by the argument of authority?
> >>>>>>>>> I just pointed out that log4j is not a commons component
and did
> > not
> >>>>>>>>> imply anything else.
> >>>>>>>>>
> >>>>>>>>>> "Commons" is OK but not another Apache project,
by virtue of a
> >>>>>>>>>> document that still refers to "JDK 1.2", "CVS",
"Bugzilla" (not
> > to
> >>>>>>>>>> mention that the "scope" of CM currently goes
well beyond "the
> > most
> >>>>>>>>>> common practical problems not immediately available
in the Java
> >>>>>>>>>> programming language")...
> >>>>>>>>>>
> >>>>>>>>>> What's the _technical_ rationale for accepting
this dependency
> > and
> >>>>>>>>>> not accepting that dependency?
> >>>>>>>>>>
> >>>>>>>>>>> I have not seen a single example of a useful
logging message
> > that
> >>>>>>>>>>> could
> >>>>>>>>>>> be added to commons-math, but we are already
discussing which
> >>>>>>>>>>> framework
> >>>>>>>>>>> to use.
> >>>>>>>>>> If it is not useful to you, why would you conclude
that it is
> not
> >>>>>>>>>> useful to others?
> >>>>>>>>>>
> >>>>>>>>>> At the cost of repeating myself, once more,
the use-case is not
> >>>>>>>>>> primarily about debugging CM, but sometimes
one could need to
> >>> assess
> >>>>>>>>>> how a "non-obvious" CM algorithm responds to
an application's
> >>> request.
> >>>>>>>>>> I've clearly expressed that use-case in a previous
message.
> >>>>>>>>>>
> >>>>>>>>>> Another example: I have a class that wraps a
CM root solver; it
> > is
> >>>>>>>>>> stuffed with log statements because the message
contained in the
> >>>>>>>>>> "NoBracketingException" was utterly insufficient
(and plainly
> >>>>>>>>>> misleading due the default formatting of numbers)
to figure out
> > why
> >>>>>>>>>> certain calls succeeded and others not.
> >>>>>>>>>> It's a problem (or a limitation) in the application,
but in the
> >>>>>>>>>> absence of other clues, tracing the solver could
help figure out
> > a
> >>>>>>>>>> workaround.
> >>>>>>>>>> The alternative to the "logging" approach, would
have been to
> >>> include
> >>>>>>>>>> a precondition check before calling the solver,
that would in
> >>> effect
> >>>>>>>>>> duplicate the bracketing check done inside the
solver. Given the
> >>> vast
> >>>>>>>>>> amount of cases where the code ran smoothly,
this is clearly a
> >>>>>>>>>> sub-optimal solution as compared to turning
logging on and rerun
> >>> the
> >>>>>>>>>> case that led to a crash.
> >>>>>>>>>>
> >>>>>>>>>> What can I say more about the usefulness (for
a "low-tech"
> person
> >>>>>>>>>> like me) than the intro here:
> >>>>>>>>>> http://logging.apache.org/log4j/2.x/manual/index.html
> >>>>>>>>>> ?
> >>>>>>>>>>
> >>>>>>>>>>> The examples with println debugging are
not valid imho, because
> >>> how do
> >>>>>>>>>>> you know in advance what you will need to
log in order to
> >>> successfully
> >>>>>>>>>>> debug some piece of code and such low-level
information should
> >>> not be
> >>>>>>>>>>> captured in logs anyway.
> >>>>>>>>>> Why are there several log levels?  Low-level
info can be routed
> > to
> >>>>>>>>>> "DEBUG" or "TRACE".
> >>>>>>>>>> As Ole put it quite eloquently, logging is a
safety net that we
> >>> hope
> >>>>>>>>>> we'll never need, until we do.
> >>>>>>>>>>
> >>>>>>>>>> Each layer of an application has its own notion
of what is the
> >>>>>>>>>> appropriate log level. What is "INFO" for some
low-level library
> >>>>>>>>>> will very probably not be so for most applications
that use the
> >>>>>>>>>> library.
> >>>>>>>>>> Setting levels per package or class takes care
of that: it's the
> >>>>>>>>>> library's *user* who chooses what is useful
in the current
> >>> situation,
> >>>>>>>>>> not the library's developer.
> >>>>>>>>>> In the context of that asynchronous collaboration,
the role of
> > the
> >>>>>>>>>> library's developer is to carefully choose what
*could* be
> >>>>>>>>>> interesting, if the need should arise.
> >>>>>>>>>>
> >>>>>>>>>> So, can we eventually discuss the _technical_
arguments against
> >>>>>>>>>> logging inside CM, rather than personal opinion?
> >>>>>>>>> again, what I want to see is an example what *should*
be logged
> in
> >>> the
> >>>>>>>>> case of an algorithm. Take the LevenbergMarquardtOptimizer
as an
> >>>>>>>>> example:
> >>>>>>>>>
> >>>>>>>>> * what did you log using System.out.println()?
> >>>>>>>>> * the algo computes a lot of internal data, which
of these is
> >>>>>>>>> interesting for debugging problems or for general
logging?
> >>>>>>>>> * there are various branches the algo can take,
are just some
> >>>>>>>>> interesting to log, or all of them?
> >>>>>>>>>
> >>>>>>>>> the use-cases presented so far were mainly about
debugging
> > specific
> >>>>>>>>> problems, and I am *strongly* against adding logging
information
> >>> just
> >>>>>>>>> for this purpose as you are clearly facing a dilemma
here:
> >>>>>>>>>
> >>>>>>>>> you have to log *everything* an algo does as otherwise
you might
> >>> miss
> >>>>>>>>> the part that creates problems
> >>>>>>>>>
> >>>>>>>>> but logging everything is not useful for a standard
user of the
> >>> library
> >>>>>>>>> so it contradicts the original proposal to include
logging
> >>>>>>>>>
> >>>>>>>>> Again, CM is not an application where you need to
log what it is
> >>> doing,
> >>>>>>>>> but a bunch of algorithms and utility methods to
perform certain
> >>>>>>>>> calculations. I fail to see the need to add logging.
What could
> be
> >>>>>>>>> useful, and we had requests like that in the past,
is to observe
> > the
> >>>>>>>>> state of a certain algorithm and to decide how to
proceed in
> > certain
> >>>>>>>>> cases.
> >>>>>>>>>
> >>>>>>>>> That is useful for users.
> >>>>>>>>>
> >>>>>>>>> Another useful addition would be to add more aggressive
> > assertions.
> >>> If
> >>>>>>>>> one user encounters a problem, he/she could run
the application
> > with
> >>>>>>>>> assertions enabled and spot potential problems e.g.
due to wrong
> >>> input.
> >>>>>>>>>
> >>>>>>>>> Logging is a solution for a non existing problem
imho.
> >>>>>>>>> Logging will not avoid the need to debug CM in case
of problems
> >>> imho.
> >>>>>>>>
> >>>>>>>> +1
> >>>>>>>> The other thing I would add is that the one place where
it does
> > make
> >>>>>>>> sense to dump text is in exception error messages, which
is a
> place
> >>>>>>>> where I think we could really improve things.  Fortunately,
that
> is
> >>>>>>>> fairly easily done.
> >>>>>>>>
> >>>>>>>> I have seen nothing in this thread to convince me that
adding
> >>>>>>>> logging in [math] will be net positive for either those
of us who
> >>>>>>>> maintain the component or for users.  If we are not
providing
> clear
> >>>>>>>> exception error messages and/or APIs (with complete
documentation)
> >>>>>>>> so that users can understand what they need to debug
their
> >>>>>>>> applications, then we should focus on solving those
problems.
> >>>>>>>>
> >>>>>>>> Phil
> >>>>>>>
> >>>>>>> First, you carefully do not reply to any of the concrete
arguments
> >>>>>>> given in this thread, second you give a conclusion to an
issue not
> >>>>>>> reported in this thread: exceptions and logging do not provide
the
> >>>>>>> same service.
> >>>>>>>
> >>>>>>> At least, I'd wish that people sharing their own opinion
(it's
> >>>>>>> nothing more since _zero_ technical argument against logging
have
> >>>>>>> been put forth) stop taking the collective "users" on their
side.
> >>>>>>> As for *actual* users/maintainers, Ole and I have a need,
while
> >>>>>>> Thomas and you haven't.  Those are all the facts that exist
until
> >>>>>>> now.
> >>>>>>>
> >>>>>>> In such a situation, what do we do as a project; maintain
the
> status
> >>>>>>> quo, or try for a change?
> >>>>>>> On numerous occasions over the years, the status quo was
enforced;
> >>>>>>> and I don't see that it benefited the project in terms of
new
> >>>>>>> contributors.
> >>>>>>> So I'm +1 for trying to change, for a change.
> >>>>>>
> >>>>>> I think one thing has been written in this thread that is worth
> >>>>>> noting and could be an intermediate position.
> >>>>>>
> >>>>>> It seems to me one place where we could get some useful information,
> >>>>>> and provide it to users is for iterative algorithms (both optimizers
> >>>>>> and solvers have already been mentioned, we could add ode
> integrators
> >>>>>> as well to this). For such algorithms, having some way to monitor
> how
> >>>>>> the iterations perform seem an improvement. An observer pattern
as
> >>>>>> proposed a few days ago for this kind of algorithms would be
fine.
> >>>>>> Once again, something simple and that does not attempt to be
hyper
> >>>>>> generic but rather taylored to the algorithms (i.e. most probably
> >>>>>> different observer interfaces for different algorithms types).
> >>>>>>
> >>>>>> This intermediate position would provide something to both users
> >>>>>> and developers, and it would not attempt to log everything and
> >>>>>> add a dependency (I am probably the one who opposed to logging
on
> >>>>>> the grounds of dependencies).
> >>>>>>
> >>>>>> best regards,
> >>>>>> Luc
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Gilles
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thomas
> >>>>>>>>>
> >>>>>>>>>>>>>> My long-standing mentioning
of slf4j was only because of its
> >>>>>>>>>>>>>> "weightlessness" (thanks to
the no-op implementation of its
> >>> API).
> >>>>>>>>>>>>>> If "Log4j 2" has followed this
path, good for everyone.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> No objection, then?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I'm still not clear what log4j 2
adds -- most Apache java
> >>> projects
> >>>>>>>>>>>>> seem to
> >>>>>>>>>>>>> use log4j 1.2, seems to work well.
-- H
> >>>>>>>>>>>>>
> >>>>>>>>>>>> I can only answer about "slf4j" where
the "f" stands for
> > facade:
> >>> it's
> >>>>>>>>>>>> "only"
> >>>>>>>>>>>> an API, with bridges to several logging
frameworks (log4j,
> >>> logback,
> >>>>>>>>>>>> etc.).
> >>>>>>>>>>>>
> >>>>>>>>>>>> The separation of concerns (API vs one
of several
> >>> implementations to
> >>>>>>>>>>>> choose from)
> >>>>>>>>>>>> allows the top-level application to
uniformly configure
> logging
> >>> or to
> >>>>>>>>>>>> disable it
> >>>>>>>>>>>> completely (if choosing the "no-op"
implementation).
> >>>>>>>>>>> That is virtually true for all logging frameworks,
including
> >>> log4j,
> >>>>>>>>>>> slf4j, commons-logging.
> >>>>>>>>>> Has it always been true?
> >>>>>>>>>> I'm certainly no expert; I only try to stay
clear of tools about
> >>> which
> >>>>>>>>>> people complain a lot.  A few years ago, that
was the case of
> jcl
> >>> and
> >>>>>>>>>> jul as compared to slf4j.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Gilles
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:
> >>> dev-unsubscribe@commons.apache.org>
> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> <mailto:
> >>> 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

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