+1
Need to send a **BREAKING CHANGE** notice to lift-announce and liftweb
and update the Wiki possibly carrying the rationale behind.
Also clearly mentioning how the existing applications would behave
without making these changes (and what needs to be done to get the
existing behavior either for slf4j or log4j)
For archetypes, it would be great to offer a choice during
archetype:generate (with some comment in the generated pom.xml as well).
Thank you very much for seeing through this issue and tying the loose
end on the way!
Cheers, Indrajit
On 08/02/10 3:25 PM, Jeppe Nejsum Madsen wrote:
Hi,
Trying to tie the knots on #309 (Logging), I've committed my changes to
http://github.com/dpp/liftweb/commits/jnm_issue_309
Before updating all the examples and archetypes, I would like to get
consensus to the approach chosen now:
- Slf4j is the logging facade used internally by the LiftLogger
- No logging backends are included by default
- A logging backend must be included in a client app for Lift to boot
successfully
- If current functionality is to be matched, two things should be changed in
client code:
1) Add slf4j-log4j12 dependency
2) Add to boot: LogBoot.loggerSetup = Log4JLogBoot.setup
- Logback functionality can be included in client app:
1) Add logback-classic dependency
2) Optional: LogBoot.loggerSetup = LogbackLogBoot.setup
If this sounds right, I'll go ahead and update the remaining parts.
/Jeppe
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
