myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <ma...@ops.co.at>
Subject AW: slf4j and myfaces
Date Sat, 06 Jun 2009 06:07:37 GMT
Sorry, for top-posting, but Outlook makes it too hard to do it right ;-)

Well, yet another configuration option for configuring our logging facade (yes, you are right,
it is a facade) is for sure also not a good option.

As a last note to this discussion I'd like to say, that not dealing with the class loader
issue does not mean that the webapp-reloading-memory-leak has been addressed in some way.

Anyway, if you think it (slf4j) is a good way to go, I'll not stand in between :-) 

Ciao,
Mario

-----Urspr√ľngliche Nachricht-----
Von: Manfred Geiler [mailto:manfred.geiler@gmail.com] 
Gesendet: Freitag, 05. Juni 2009 20:50
An: MyFaces Development
Betreff: Re: slf4j and myfaces

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
anfred
Mime
View raw message