myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: slf4j and myfaces
Date Fri, 05 Jun 2009 18:56:04 GMT
>JCL and slf4j ARE ready-to-use logging wrappers.

+1

regards,
gerhard

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2009/6/5 Manfred Geiler <manfred.geiler@gmail.com>

> On Fri, Jun 5, 2009 at 19:49, Mario Ivankovits <mario@ops.co.at> wrote:
> > Hi!
> >
> > Could one please eloberate a little bit more in detail what the pros are
> of
> > slf4j?
>
> Pros:
> No class loader ambiguousness (as you mentioned)
> You get what you define (especially when using maven):
> compile-dependency to slf4j-api
> runtime-dependency to slf4j-adapter of YOUR choice
> --> that's it!
>
> No wild guessing like with JCL: Use Log4j if it is anywhere in the
> (web container) classpath, else use Java logging... What, if I want to
> use Java logging although there is Log4j in the classpath?!
> "Someone dropped a log4j.jar in the tomcat/lib folder. Oh no, not again..."
> Yes, I know commons-logging.properties solves this, but that's
> awful... (BTW, I hate properties files in the root package namespace!)
>
>
> > Notice, I switched to it in our company project - but always using the
> > commons-logging api and just used the slf4j-over-cl wrapper. This is
> > something wich is possible for each and ever user of myfaces already,
> just
> > by adjusting the depencendcies correctly.
>
> Guess, you meant the jcl-over-slf4j.jar bridge, right? That's the part
> that reroutes JCL calls to the slf4j API.
> Yes, that is a possible solution, but keep in mind that this is kind
> of a hack. It is actually a reimplementation of the JCL API
> (namespace) that routes all calls to SLF4J.
> It's meant as runtime solution for legacy libs. Using it as compile
> time dependency might be a shortcut, but my feeling says it's not the
> nicest solution.
>
>
> > Lately I even switched to my own logging wrapper, but this is another
> story.
> > In the end, everything still uses the cl API which is proven to work
> fine.
> > (I created the org.apache.commons.logging package structure with my own
> > classes - which for sure is not possible for myfaces!).
>
> yet another logging wrapper.... WHY do so many people feel they must
> write such a thing? JCL and slf4j ARE ready-to-use logging wrappers.
> So???
>
>
> > I still think, that using the cl api is the best we can do for our users.
> If
> > they then use cl as implementation - and if this is considered "good" -
> is
> > another story, but nothing WE should anticipate.
>
> They CAN use JCL if myfaces uses slf4j. They just define a
> slf4j-jcl-x.x.x.jar runtime-dependency and everything is fine.
>
>
> > As far as I can say the cl api is rock solid, just the class-loader stuff
> is
> > a pain. But (again AFAIK), slf4j does not solve it, it just does not deal
> > with it.
>
> slf4j DOES solve the problem by avoiding highly sophisticated classloader
> magic!
>
>
> > Before we start using any other logging api I'd suggest to build our own
> > thin myfaces-logging wrapper where one then can easily plug in log4j, cl,
> > jul (java utils ogging) or whatever - we do not even have to provide any
> > other impl than for jul.
>
> yet another logging wrapper... (see above)
>
> How would you implement such a pluggable wrapper? Yet another
> (mandatory) config parameter. System property? Servlet context param?
> Come on!
> What about this: looking for existing well-known logging
> implementations and define some priority rules... Dejavu. See the
> problem?
>
>
> > As a plus, this then will remove a dependency - a dependency to any
> logging
> > framework - which - in terms of dependencies can be considered as a
> "good"
> > thing, no?
>
> You buy this "good" thing by re-implementing SLF4J and/or JCL.
> Serious. I cannot imagine a "wrapper" (actually a "facade", right?)
> implementation that is versatile for the developers and pluggable for
> the users and has less source code than any of the well-known logging
> facade APIs (slf4j and jcl). They both are actually meant to heal the
> java world from proprietary "yet another logging facades/wrappers"!
>
>
> +1 for using SLF4J as logging facade for future MyFaces developments
> (JSF 2.0, ...)
> +0 for replacing JCL by SLF4J for all existing code (if someone is
> volunteering to do the job I have no problem with that...)
>
>
> --Manfred
>

Mime
View raw message