On Mon, Feb 15, 2010 at 9:57 PM, Indrajit Raychaudhuri <[email protected]> wrote:
>> http://github.com/dpp/liftweb/blob/add01980aa81875617f38260d710e0558c7ae1b1/framework/lift-base/lift-common/src/main/scala/net/liftweb/common/Logging.scala >> >> One issue remains, which I don't know how to handle (if possible at >> all): The current mixins use the dynamic type of an instance to >> determine the logger name. This may not always be the preferred way. >> E.g: >> >> trait PaymentSystem extends Logger >> trait FullfillmentSystem extends Logger >> >> object MyStore extends PaymentSystem with FullfillmentSystem with Logger >> >> Now everything in the subsystems will be logged with the MyStore >> logger which is not how I would like to see it. The only solution I've >> found so far is to not use the mixins and create private loggers in >> the subsystem, where the static type is known. E.g. val logger = >> Logger(classOf[PaymentSystem]) >> >> But this kind of restricts the usage of the mixins. Any thoughts on >> this issue is appreciated.... > > The restriction might be worthwhile in this case for the sake of > predictability. Having class/object specific logger is to be able to filter > in/out the logs (via configuration) at deployment time. It should not be too > sensitive to minor rearrangement of mixins in the code. > > Would it be overcomplicated to make the Logger trait typed? Not sure I follow? Logger is already a trait...Or did you mean something else? Having thought a little more about this, it seems like both solutions (mixin and private loggers) has their uses: Mixins as convenience for application services that should not be subclassed and private loggers for reusable components . /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.
