Re: [Lift] Potential breakage: Choosing the default Lift logging backend
Heiko Seeberger writes: > Hi, > > On 5 February 2010 22:11, Jeppe Nejsum Madsen 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Potential breakage: Choosing the default Lift logging backend
Hi, On 5 February 2010 22:11, Jeppe Nejsum Madsen 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. Heiko Work: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Potential breakage: Choosing the default Lift logging backend
(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 -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
