logging and moving goodness from Akka

253 views
Skip to first unread message

Sam Halliday

unread,
Apr 8, 2013, 5:59:42 PM4/8/13
to scala...@googlegroups.com
Hi all,

After spending 5 months working on real world commercial Scala / Akka / Spray, I wrote up some lessons learnt


One of the biggest lessons was how to get Logging set up in Scala. This is basically a mess at the moment (although there is already improvement in SBT and Specs2 as a result of the above) because there is no adopted logging API standard ... but the Akka LoggingAdapter could be it.

I'd really like you all to consider adopting the Akka LoggingAdapter trait as part of Scala Library, and providing a Java Util Logging (JUL) backend (there is one in akka-contrib... could do with a rename) for people to use out of the box.

I raised this as a ticket in the Akka issue tracker and they feel this is something they would support:


... all it needs is some consensus on the Scala side.


My concern is that logging in Scala is going to go the route of Java and we're going to end up with loads of conflicting third party libs all doing something that is essentially trivial. Compound that with the myriad of Java backends (SLF4J sometimes causes more problems than it creates) and things get really ugly.


I don't really care much for pushing JUL itself (it works, but don't ever look inside it or you might scream!). I would just like solidarity in one client-side logging API. JUL has the advantage that it is already shipped with J2SE, but I'd be equally happy if you went with SLF4J... compatibility with legacy Java libs is essential.

Best regards,
Sam

Francois

unread,
Apr 9, 2013, 4:55:59 AM4/9/13
to scala...@googlegroups.com, Sam Halliday
Scala Logging[1] seems nice and supported by Typesafe - OK, I don't use
it (for now), because when my project started 4 years ago, it simply
didn't exist yet, and so I use Lift Logging, which is quite the same
from an user point of view. So perhaps in a near future, we will update
to scalalogging.

Could you explained why you didn't use that, or what are the things that
are not good with that library ? (genuine question, I'm really
interested in the answer because as I said, I'm wondering if we
shouldn't use that).

Thanks,

[1] https://github.com/typesafehub/scalalogging


--
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com

Sam Halliday

unread,
Apr 9, 2013, 1:36:32 PM4/9/13
to Francois, scala...@googlegroups.com
Francois,

Consistency is the answer. It is cleaner to have one client API. Using Lift in lift, Akka Logging and Scala logging elsewhere is not an answer.

Kind regards,
Sam Halliday

--
Sent from my iPhone

Francois

unread,
Apr 10, 2013, 5:06:17 AM4/10/13
to Sam Halliday, scala...@googlegroups.com
Le 09/04/2013 19:36, Sam Halliday a écrit :
> Francois,
>
> Consistency is the answer. It is cleaner to have one client API. Using Lift in lift, Akka Logging and Scala logging elsewhere is not an answer.

OK, I didn't make myself clear: I was asking about Scala logging, not
Lift one. Of course consistency is important, and is why we are thinking
about swapping to Scala logging.
So, the question should have been: why Scala logging can not be the one
client API to rules them all ? Why didn't you use it ?

Cheers,

Samuel Halliday

unread,
Apr 10, 2013, 5:31:51 AM4/10/13
to Francois, scala...@googlegroups.com
Francois,

It can't be used (currently) in Akka... It has its own logging system. There needs to be one client API that everyone adopts. I personally don't care which one.

My solution was to create an adapter that allowed me to use the Akka logging API outside of Akka, but for this to be future proof, that trait really needs to live in Scala library.

There are already a lot of people familiar with the Akka logging API, whereas Scala-logging seems to be a noble effort that hasn't caught on. Scala logging also implies third party dependencies.

Sent from my iPad

Sam Halliday

unread,
Apr 18, 2013, 4:58:04 AM4/18/13
to scala...@googlegroups.com, Francois
Hi all,

I was wondering if anybody had given this any more consideration as a SIP?
Reply all
Reply to author
Forward
0 new messages