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
