2014-05-15 3:40 GMT+02:00 Chris Pratt <thechrispr...@gmail.com>:
> Then you still have to use code like:
>
> if(LOG.isDebugEnabled()) {
> LOG.debug("Action name is [#0]",action.getName());
> }
>
> Any time that the value isn't in an available primitive. With Onyx you
> could just write:
>
> LOG.debug("Action name is {0.name}",action);
>
> Which is much more readable and just as performant.
That's why I want to improve the implementations of XWork's Logger -
to get exactly the same gain
> Anyone who has an application with SLF4j, plus Log4j and other logging
> engines doesn't understand SLF4j.
>
> SLF4j provides an API for library developers to use (kind of in the old
> commons logging vein), where the back end decision can be given to the user
> of the library, but that's only the top level of SLF4j.
The same we have already in XWork logging layer, you're using one
Logger API but it depends on user which implementation to use (SLF4j,
Log4j, jul) just by dropping in given lib (or using if it's already
available).
User can also implement its own version without too much hassle.
> As I said, SLF4j provides an API, but it also provides conduits to funnel
> just about any logging information through a SINGLE logging engine, be that
> Log4j, java.util.logging, SysOut, Logback or whatever you would like. If
> you are using old libraries that haven't adopted SLF4j yet, and are using
> Log4j, commons logging or java.util.logging, you can add shims that will
> route all the information that was originally intended for that logging
> engine (i.e. java.util.logging or commons logging) through SLF4j, to the
> chosen logging engine (e.g. Log4j). And, all you have to do to install
> most shims is drop the jar file in the libs directory. That way you have
> one engine to configure, but you get control over all the logging
> information from all the libraries in your system.
The problem here is we're going to introduce a new required dependency
(SLF4j API) and this can be unacceptable for some companies (don't ask
me why, I know it's real). Another thing I just want to use what user
already is using and not tell him "add this jar, that jar and
configure it via xml" - overcomplicated.
Right now Struts will use what is already available on classpath -
Log4j, SLF4j, JDK logger - in that order. If user needs to use
specific implementation he can simple add
-Dxwork.loggerFactory=com.opensymphony.xwork2.util.logging.slf4j.Slf4jLoggerFactory
and done
http://struts.apache.org/release/2.3.x/docs/logging.html
> Weather or not you decide to go with my Onyx layer, I would strongly
> suggest moving to SLF4j.
Still not convinced, too often I saw projects that switched to SLF4j
just because (Hibernate) and now there are conflicts with different
version of SLF4j required per each product (ie. JBoss and Hibernate)
I'd rather adopt your Onyx lib to get power of extended logging capabilities.
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
