On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
On Fri, Sep 25, 2015 at 5:09 PM, Gilles
<gil...@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.
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?
Gilles
[1] http://commons.apache.org/releases/versioning.html
[2] http://commons.apache.org/proper/commons-math/proposal.html
Thomas
If there are now well-formed answers proving that the fear was
unfounded, that is also a change.
IMO, logging is quite important for any "non-obvious" code.[1]
[I'm again stating that, in that respect, CM is not like the other
"Commmons" components.]
Several times, I've been obliged to create a modified version of CM
to introduce "print" statements (poor man's logging!) in order to
figure out why my code did not do what it was supposed to.
It also makes a code easier to debug while developing or modifying
it
(without resorting to poor man's logging, then deleting the "print",
then reinstating them, then deleting them again, ad nauseam).
Gilles
[1] No quality or complexity judgment implied.
Phil
Gilles
Thomas
On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ole.er...@gmail.com>
wrote:
Hello,
We have been discussing various ways to view what's happening
internally
with algorithms, and the topic of including SLF4J has come up.
I know that
this was discussed earlier and it was decided that CM is a low
level
dependency, therefore it should minimize the transitive
dependencies that
it introduces. The Java community has adopted many means of
dealing with
potential logging conflicts, so I'm requesting that we use SLF4J
for
logging.
I know that JBoss introduced its own logging system, and this
made me a
bit nervous about this suggestion, so I looked up strategies for
switching
their logger out with SLF4J:
http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
The general process I go through when working with many
dependencies that
might use commons-logging instead of SLF4J looks something like
this:
http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
With JDK9 individual modules can define their own isolated set
of
dependencies. At this point the fix should be a permanent. If
someone has
has a very intricate scenario that we have not yet seen, they
could use
(And probably should use) OSGi to isolate dependencies.
WDYT?
Cheers,
- Ole
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
