I should be able to add the dot syntax to the existing xwork logger (I'll
have to research further to be sure). One other change I would suggest is
changing the order of the logging engine discovery. If you test for log4j
before you test for slf4j, then there's no way to use slf4j as the api with
log4j as it's engine, since Struts will find the log4j jar and stop
looking. So I'd suggest changing the order to:
1. slf4j
2. log4j
3. jdk logger
to prevent that problem. Luckily Ceki has done a good job of making sure
SLF4j is backward compatible, so it should be safe to use the latest SLF4j
library, but there is always a concern when using libraries.
(*Chris*)
On Thu, May 15, 2014 at 3:15 AM, Lukasz Lenart <lukaszlen...@apache.org>wrote:
> 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
>
>
