On 23 May 2014, at 18:22, Chris Pratt wrote:
I'm preparing to start working on the logging for Struts 3.0, so we
need to
come to some consensus. As I see it, the leading options are:
1. Don't do anything
2. Switch to SLF4j (or Log4j2)
3. Use Onyx as is
4. Use Onyx as an Object Aware Facade directly to SLF4j (or Log4j2)
I am sure you have posted links before, but could you repost links to
the Onxy project.
I am unable to find the right page with google.
My preference would actually be #4. Onyx has some nice readability
and
performance benefits over using SLF4j/Log4j2 directly
I can't believe it has performance benefits compared to async loggers of
log4j2:
http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html
that I think are
worth the minimal effort. Please weigh in with your opinion before I
get
too deep into this.
Personally I would prefer Log4j2. I am biased as I am involved in that
project.
However this is not marketing, I really believe this is so far the best
logging framework you can have atm (I haven't checked Onyx).
Also I like the ASF and believe we are developing here for a reason. For
the same
reason I always prefer other ASF projects.
If we do not want Log4j2 for some reason (it's currently RC1 - I say its
stable
and until we get S3 out it will be GA, but others may think different)
then
I definitely prefer slf4j. It has quite a market share and is commonly
accepted
by people.
We need to have good reasons to not use what anybody else use.
As I find slf4j/log4j2 syntax nice to read too and I doubt about
performance
benefits I would love to hear more arguments pro-Onyx.
In short, my current preference is #2 with Log4j2, but if necessary even
with slf4j.
And I am willing to invest some time here too, esp if I could budget
this on my log4j2 budget :-)
Cheers
Christian
(*Chris*)
On Fri, May 23, 2014 at 7:17 AM, Dave Newton <davelnew...@gmail.com>
wrote:
Just my $0.02:
I'd prefer to see stuff that other people implement and have more
eyes on
take precedence over framework code.
Similar to how XW has/had string utils duped by commons, etc, it just
doesn't make sense to maintain that kind of boilerplate when it's
already
implemented, and implemented pretty well.
Dave
On Fri, May 23, 2014 at 9:37 AM, Christian Grobmeier
<grobme...@gmail.com
wrote:
On 23 May 2014, at 11:58, Lukasz Lenart wrote:
Yes, we can break everything in 3.x but ... do we want to start from
scratch?
It's not from scratch, is removing something from our codebase and
use
something which already exists.
And what's wrong in tiny logging facade? I've said it already, I
will
say it again: not all ppl are using Log4j or SLF4j or jul - it's
the
worst thing if you must handle configuration of two or three
different
logging libraries because each framework is using a different one.
First, we are a tiny active team. Why do we re-implement tiny
facades
when they exist? I think with the less man-power we have we can
surely
do better and more necessary things than reinventing the wheel.
Surely, not all ppl use log4j or slf4j or jul. But most do. I can't
help
but believe that there are only a handful people who still write
their
own
logging thing.
Please see this non-representative survey from ZeroTurnaround:
http://zeroturnaround.com/rebellabs/the-state-of-logging-in-java-2013/
Looks like everybody is using *something*, except 7% of participants
who is doing their own thing. It also says slf4j and log4j are the
most
used
logging frameworks.
Sure, logging has something to do with configuration. If you want
to get out of this, then use the simple logging implementation which
comes with slf4j. If you need more, configure something in addition.
Maybe Java logging is a mess, but I believe it's not to Struts to
solve
it. Instead I would offer something which the most people use (maybe
slf4j) or
something which we believe in (maybe log4j2).
Right now Struts2 doesn't force users to use given logging library,
it
can be configured to use whatever user is using in his project -
thus
is huge advantage and I don't want to loose it.
You have the same with slf4j. Why is having our own custom thing
better
than something which is widely accepted and adopted?
With slf4j you can:
- do not configure anything, go with slf4j
- do configure something, go with the framework you like
The same is true for the new log4j2 facade.
Thanks for the discussion!
2014-05-22 18:28 GMT+02:00 Christian Grobmeier
<grobme...@gmail.com>:
Hi all,
with Struts 3.x we are allowed to "break things" and it is
expected
that
we
do major steps.
Personally I would like to remove any custom made logging layer
and move on to a more standard one. Performance is not an issue,
when
logging
is done right:
http://www.grobmeier.de/log4j-2-performance-close-to-insane-
20072013.html
I consider commons-logging almost dead. It will not be developed
much
further, at least
not when looking at recent activity of the past years.
I think slf4j is stable and well maintained. You can even use
log4j2
with
it.
Saying log4j2 I am pretty much biased and need to tell you that
log4j2
also
provides a logging interface similar to slf4j with which you can
switch
implementations.
In no case I would go to anything exotic or jul. The latter one
often
needs
wrappers
to work as wanted.
That being said, I only see slf4j and log4j. If we want to stick
in the
ASF
world
we can use the log4j2 interfaces and explain how to integrate in
example
logback.
That would be my preferred choice. Also I think log4j2 provides
more
features and
is pretty much better maintained (my personal opinion)
If we want to use something which is longer on the market, then
slf4j.
cheers
On 22 May 2014, at 9:19, Chris Pratt wrote:
You are correct, it delegates the actual logging to a logging
engine,
currently either Log4j, Logback, java.util.logging or to SLF4j.
(*Chris*)
On Wed, May 21, 2014 at 10:10 PM, Lukasz Lenart
<lukaszlen...@apache.org>wrote:
@Chris
Do I get it right - Onyx is just logging facade not the
full-blow
logging library?
2014-05-17 8:52 GMT+02:00 Lukasz Lenart
<lukaszlen...@apache.org>:
Some were already addressed, another thing is that across the
framework we are using different semantic inside logging
messages,
ie:
"Value [#0] was excluded by pattern [#1]" and re-writing all
these
doesn't make sense. Right now XWork logging facade is very thin
-
one
class implementing Logger interface and another implementing
LoggerFactory - the rest is delegated to given logging library.
Besides that, users don't care what kind of logging library
framework
is using - till it doesn't interfere with the one used in their
apps
or clashes with logging layers from other frameworks. Switching
entirely to SLF4j can break few apps and we'll get a lot of
complains
why (not the first time ;-)
My plan looks like this:
- add checking if given log level is enabled inside logging
methods
- start migrating code to the new semantic (removing if
(LOG.isXxxEnabled())
- migrate the rest of logging calls to use parameter
substitution
- (or start with this before previous step) use Onyx instead of
current LoggerUtils
- change order of discovering logging libs on the classpath and
put
SLF4j on top
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
2014-05-15 23:14 GMT+02:00 Chris Pratt
<thechrispr...@gmail.com>:
What is your reluctance to using SLF4j. It seems like the
right
technology
for the problem.
(*Chris*)
P.S. ICLA on the way
On Wed, May 14, 2014 at 11:16 PM, Lukasz Lenart <
lukaszlen...@apache.org>wrote:
2014-05-14 21:51 GMT+02:00 Chris Pratt
<thechrispr...@gmail.com>:
Yes, we could use Onyx's interface mechanism, but I think
SLF4j's
is
probably more stable and definitely more supported. So I'd
probably
recommend that we extract the SLF4j support object and use
it
directly
(or
at least make it the default). If it's something that
you're
interested
in, I'd have to fill out the forms to become a committer on
Struts.
Where
would I find that information?
I'm not sure if this the right move, switching to SLF4j over
our
custom solution. Please can we explore this topic a bit?
The first step to become a committer is to fill ICLA
http://www.apache.org/licenses/#clas
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
---
http://www.grobmeier.de
The Zen Programmer: http://bit.ly/12lC6DL
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
---
http://www.grobmeier.de
The Zen Programmer: http://bit.ly/12lC6DL
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
--
e: davelnew...@gmail.com
m: 908-380-8699
s: davelnewton_skype
t: @dave_newton <https://twitter.com/dave_newton>
b: Bucky Bits <http://buckybits.blogspot.com/>
g: davelnewton <https://github.com/davelnewton>
so: Dave Newton <http://stackoverflow.com/users/438992/dave-newton>
---
http://www.grobmeier.de
The Zen Programmer: http://bit.ly/12lC6DL
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
