Potential breakage: Choosing the default Lift logging backend
Jeppe Nejsum Madsen
(Moved from committers list)
Hi,
A fix is on RB (http://reviewboard.liftweb.net/r/198/) for Issue 309
that changes the Lift internal logging to always go through Slf4j (a
logging facade that provides a uniform logging interface to different
logging backends such as Log4j and logback)
Since slf4j-api.jar is only a facade, an actual logging backend (such as
log4j) needs to be included in an app. A decision remains as to what the
best solution is for specifying this dependency and configure the
backend. There are 2 options as I see it:
1) Include the slf4j-log4j12 as runtime dependency in lift-util. This
also includes the log4j.jar. Log4j is configured automatically, as in
the current code.
Pros: No changes to client code or poms
Cons: Need to explicitly exclude slf4j-log4j12 dependency if another
backend than log4j (such as logback) is needed.
2) Don't include any logging backends, but the user is forced to make a
decision before the app will log anything.
Pros: No need to exclude anything if using another backend than log4j.
Cons: People need to update their poms. The configuration of log4j would
have to depend on dynamic classloading if we are to avoid code changes.
The current patch implements 1) as I like the fact that some default
exists, even though it makes it a bit harder for people to switch
backends.
2) is the cleanest solution since the choice of logging backend is made
explicit. But this requires people to change their poms in order to get
any logging.
Thoughts?
/Jeppe
Heiko Seeberger
2) is the cleanest solution since the choice of logging backend is made
explicit. But this requires people to change their poms in order to get
any logging.
Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
Jeppe Nejsum Madsen
> Hi,
>
> On 5 February 2010 22:11, Jeppe Nejsum Madsen <je...@ingolfs.dk> wrote:
>
>>
>> 2) is the cleanest solution since the choice of logging backend is made
>> explicit. But this requires people to change their poms in order to get
>> any logging.
>>
>
> Let's go for 2) because in real-world projects people will have to adjust
> the POM anyway. E.g. for persistence modules or for 3rd party libs.
After some thoughts, I agree.
One issue remains: Configuration of the actual logging backend (ie log4j
or logback) to load e.g. prod, test & dev configs.
We can either
1) Try to be smart and figure out which backend is available and
configure it automatically. This (I learned :-) doesn't sit too well
with OSGi and is not really the Lift way.
2) Require backend specific configuration in Boot. This is the Lift way,
but it's a breaking change
Opinions?
/Jeppe
Timothy Perrett
Certainly 2 has to be the way to go. We can add stuff to the
archetypes to ease this process for users. Moreover, we could add
specific lift modules that carried the right dependencies and boot
wire up to save the users writing boilerplate. i.e.:
+ lift-logging
\ - lift-log4j
\ - lift-logback
The overhead of this would be negligible. Thoughts?
Cheers, Tim
On Feb 6, 11:28 am, Jeppe Nejsum Madsen <je...@ingolfs.dk> wrote:
David Pollak
Jeppe,
Certainly 2 has to be the way to go. We can add stuff to the
archetypes to ease this process for users. Moreover, we could add
specific lift modules that carried the right dependencies and boot
wire up to save the users writing boilerplate. i.e.:
+ lift-logging
\ - lift-log4j
\ - lift-logback
The overhead of this would be negligible. Thoughts?
If we're going to require #2, then I'd like to see some code breakage so that people don't passively upgrade to 2.0-M3 then have their logging magically break.
Cheers, Tim
On Feb 6, 11:28 am, Jeppe Nejsum Madsen <je...@ingolfs.dk> wrote:
> > On 5 February 2010 22:11, Jeppe Nejsum Madsen <je...@ingolfs.dk> wrote:
>
> >> 2) is the cleanest solution since the choice of logging backend is made
> >> explicit. But this requires people to change their poms in order to get
> >> any logging.
>
> > Let's go for 2) because in real-world projects people will have to adjust
> > the POM anyway. E.g. for persistence modules or for 3rd party libs.
>
> After some thoughts, I agree.
>
> One issue remains: Configuration of the actual logging backend (ie log4j
> or logback) to load e.g. prod, test & dev configs.
>
> We can either
>
> 1) Try to be smart and figure out which backend is available and
> configure it automatically. This (I learned :-) doesn't sit too well
> with OSGi and is not really the Lift way.
>
> 2) Require backend specific configuration in Boot. This is the Lift way,
> but it's a breaking change
>
> Opinions?
>
> /Jeppe
--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
Jeppe Nejsum Madsen
> On Sat, Feb 6, 2010 at 5:42 AM, Timothy Perrett <tim...@getintheloop.eu>wrote:
>
>> Jeppe,
>>
>> Certainly 2 has to be the way to go. We can add stuff to the
>> archetypes to ease this process for users. Moreover, we could add
>> specific lift modules that carried the right dependencies and boot
>> wire up to save the users writing boilerplate. i.e.:
>>
>> + lift-logging
>> \ - lift-log4j
>> \ - lift-logback
>>
>> The overhead of this would be negligible. Thoughts?
>>
>
> If we're going to require #2, then I'd like to see some code breakage so
> that people don't passively upgrade to 2.0-M3 then have their logging
> magically break.
Not sure if you've reached the bottom of your inbox yet, but just in
case you missed this:
The current code on the branch fails to boot (with the standard Slf4j
error messages about missing log config) if no logging dependencies are
included.
As I wrote earlier, I can't see a way to break compilation on upgrade
(unless we rename Log & LogBoot), since it's just code like this
Log.info("hello world")
But if somebody has suggestions, I'm all ears :-)
/Jeppe