Re: [Lift] New logging code is in master
On Mon, Mar 1, 2010 at 12:20 AM, David Pollak feeder.of.the.be...@gmail.com wrote: Excellent! We have the deprecations turned off in the pom.xml file by default... but gotta turn the deprecation warnings on post M3. Not sure what this means? Do the generated jars on scala-tools not contain deprecation info or does the compilation of Lift itself not show deprecation warnings? If the former, this would explain what I see. If the latter, I added args arg -deprecation /arg /args to my own pom and would expect this to show the warnings /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] New logging code is in master
Finally! Great job, Jeppe. - IRC On 28/02/10 9:44 PM, Jeppe Nejsum Madsen wrote: The new logging code is now in master and should be fully usable. Therefore, the existing logging code has been deprecated. I've added a Wiki article here: http://wiki.github.com/dpp/liftweb/logging-in-lift /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] New logging code is in master
Excellent! We have the deprecations turned off in the pom.xml file by default... but gotta turn the deprecation warnings on post M3. On Sun, Feb 28, 2010 at 8:14 AM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote: The new logging code is now in master and should be fully usable. Therefore, the existing logging code has been deprecated. I've added a Wiki article here: http://wiki.github.com/dpp/liftweb/logging-in-lift /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.comliftweb%2bunsubscr...@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 -- 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] New logging code
On 14 February 2010 20:10, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Makes sense, and that was actually close to what I had initially: The Logger trait was called LiftLogger, but this clashed with the current LiftLogger. This name (Logger in current code) probably doesn't matter too much as it's usually not needed in client code. But AbstractLogger doesn't sound very nice :-) Even if (probably) not needed, we should try to name it the best possible way. Changing now causes no pain at all, but later ... you know. 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.
Re: [Lift] New logging code
On Mon, Feb 15, 2010 at 9:17 AM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: On 14 February 2010 20:10, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Makes sense, and that was actually close to what I had initially: The Logger trait was called LiftLogger, but this clashed with the current LiftLogger. This name (Logger in current code) probably doesn't matter too much as it's usually not needed in client code. But AbstractLogger doesn't sound very nice :-) Even if (probably) not needed, we should try to name it the best possible way. Changing now causes no pain at all, but later ... you know. Agreed. Suggestions? /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] New logging code
On 15 February 2010 09:45, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Even if (probably) not needed, we should try to name it the best possible way. Changing now causes no pain at all, but later ... you know. Agreed. Suggestions? I already made mine, just to make sure everyone has a chance to see them: Like *Iterable* and *Iterator* lets call the trait that offers the logging methods (info, warn, etc.) *Logger* and the trait that gives access to a * Logger* should be called *Loggable*. 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.
Re: [Lift] New logging code
On Mon, Feb 15, 2010 at 9:52 AM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: On 15 February 2010 09:45, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Even if (probably) not needed, we should try to name it the best possible way. Changing now causes no pain at all, but later ... you know. Agreed. Suggestions? I already made mine, just to make sure everyone has a chance to see them: Like Iterable and Iterator lets call the trait that offers the logging methods (info, warn, etc.) Logger and the trait that gives access to a Logger should be called Loggable. I know, but before there was an extra (abstract) trait Logger which was what I asked about :-). But this is a moot point now, it has been eliminated and naming is now as you proposed above For convenience: 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 /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] New logging code
On 15/02/10 7:46 PM, Jeppe Nejsum Madsen wrote: On Mon, Feb 15, 2010 at 9:52 AM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: On 15 February 2010 09:45, Jeppe Nejsum Madsenje...@ingolfs.dk wrote: Even if (probably) not needed, we should try to name it the best possible way. Changing now causes no pain at all, but later ... you know. Agreed. Suggestions? I already made mine, just to make sure everyone has a chance to see them: Like Iterable and Iterator lets call the trait that offers the logging methods (info, warn, etc.) Logger and the trait that gives access to a Logger should be called Loggable. I know, but before there was an extra (abstract) trait Logger which was what I asked about :-). But this is a moot point now, it has been eliminated and naming is now as you proposed above For convenience: 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? /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] New logging code
On Mon, Feb 15, 2010 at 9:57 PM, Indrajit Raychaudhuri indraj...@gmail.com 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 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] New logging code
I don't think it's theoretically possible to have the same trait instance
recognize which superclass that it was mixed in to is doing the logging.
Because if A mixes in T, and B extends A and also mixes in T, T is not
really mixed in twice. For the same reason using a type parameter would not
help because any given class can only have one type value.
The closest thing I can think of is using the stack trace to find the method
calling the logging method, and figuring out which trait it comes from. In
other words, not a solution.
If it's important, you may want the logging method to take an implicit
parameter, say of type
case class LoggerName(name: String)
Then your trait can provide a default implicit, but I'm guessing if a
subclass has it's own (say private) implicit val, it would be used.
To determine if this is true, try:
case class N(s: String)
trait T {
implicit val x = N(t)
def m(implicit p: N) = println(p)
}
class A extends T {
private implicit val y = N(a)
m
}
class B extends A {
private implicit val z = N(b)
m
}
new T {}
new A
new B
2010/2/15 Jeppe Nejsum Madsen je...@ingolfs.dk
On Mon, Feb 15, 2010 at 9:57 PM, Indrajit Raychaudhuri
indraj...@gmail.com 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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
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] New logging code
On 14 February 2010 14:40, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
Hi,
I've tried to keep it as simple as possible, really just a Scala layer
on top of the SLF4J api.
I think that's a very good decision!
Note that no backend (log4j or logback) configuration is included. This
has to go into lift-util to use runmode etc.
You can have your choice of a nested logger:
object MyObj extends Logging {
logger.info(nested Hello)
}
or direct access:
object MyObj extends Loggable {
info(direct Hello)
}
Thoughts?
I really like to have Logging and Loggable, but I would call them vice versa
and change Logging to Logger. As an example think of Iterable and Iterator.
In general an Xable gives you access to an X. Hence we should have Loggable
with a method logger that returns a Logger and we should have Logger to mix
in all the logging methods. Why change from Logging to Logger? Because we
should call it what it is, not what it does.
Cheers,
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.
Re: [Lift] New logging code
On Sun, Feb 14, 2010 at 5:59 PM, Heiko Seeberger
heiko.seeber...@googlemail.com wrote:
On 14 February 2010 14:40, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
Hi,
I've tried to keep it as simple as possible, really just a Scala layer
on top of the SLF4J api.
I think that's a very good decision!
Note that no backend (log4j or logback) configuration is included. This
has to go into lift-util to use runmode etc.
You can have your choice of a nested logger:
object MyObj extends Logging {
logger.info(nested Hello)
}
or direct access:
object MyObj extends Loggable {
info(direct Hello)
}
Thoughts?
I really like to have Logging and Loggable, but I would call them vice versa
and change Logging to Logger. As an example think of Iterable and Iterator.
In general an Xable gives you access to an X. Hence we should have Loggable
with a method logger that returns a Logger and we should have Logger to mix
in all the logging methods. Why change from Logging to Logger? Because we
should call it what it is, not what it does.
Makes sense, and that was actually close to what I had initially: The
Logger trait was called LiftLogger, but this clashed with the current
LiftLogger.
This name (Logger in current code) probably doesn't matter too much as
it's usually not needed in client code. But AbstractLogger doesn't
sound very nice :-)
/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.
