[osgi logging] part 2 – LogServices vs classic Logger

This is part 2 of my blogseries about ‘Logging in OSGI Enterprise Applications‘ – you’ll find all parts here.

OSGI Log Services vs ‘classic’ Logging

There are some important differences you should be aware of before taking your decision:

• How do you log ? There are not so much differences at a first look:
  • OSGI Log Services: logService.log(LogService.LOG_INFO, “Hello “+user.getName()+” is logging!”)
  • Equinox Extended Log Services: logger.log(LogService.LOG_INFO, “Hello “+user.getName()+” is logging!”)
  • Apache Commons Logging: logger.info(“Hello “+user.getName()+” is logging!”)
  • SLF4J / Logback: logger.info(“Hello {} is logging!”, user.getName())
• When will a message be logged ?
  • Using OSGI Log Services all messages are always logged, which meant the OSGI Log Services will provide your Log Entries to all Log Reader Services, where you then decide what to do with this message.
  • Using ‘classic’ Logging the Log Implementation decides from your configuration if a message from this logger at a specific level should be logged or not. If not, then nothing happens and if using a modern implementation like SLF4J / Logback then there’s no String  concatenation done to construct the log message. Logback understands parameterized Log messages, tests first if the message should be logged and then constructs the message. Other Implementations always do the String concatenation – thats the reason why you found constructs like if logger.isDebugEnabled() then… where’s no need to use it with SLF4J/Logback (read more here about parameterized log messages)
• What will be logged ?
  • Using OSGI Log Services you’re best integrated into OSGI world and have access to BundleContext and ServiceReferences.
  • Extended OSGI Log Services also give you the Loggername (normaly the Classname from where you logged)
  • ‘classic’ Logging has no infomations about Bundles or ServiceReferences, but knows things like MDC (Mapped Diagnostic Context – a Thread-local Map to add Sessiondata or so)
  • SLF4J/Logback has also Marker Support. Markers are a tree of Strings – I use Markers to store the Bundle from where the Log message comes.

Here’s a short comparision about the content of a LogEntry:

How to decide what to use ?

Its not always easy to decide, whats your best choice – perhaps some questions can help:

• You’re developing an OSGI Application without many ‘other’ frameworks / tools integrated?
• You have your own Logging – Backend (perhaps sending all  Log Entries to a RDBMS Log Server) ?

→ OSGI LogService + OSGI LogReaderService seems to be a good choice

• You’re developing an OSGI Application without many ‘other’ frameworks / tools integrated?
• You like the flexibility of different Appenders from ‘classic’ Logging Frameworks (RDBMS, SMTP, Files, …) ?

→ OSGI LogService + OSGI LogReaderService  …or… → ‘classic’ Logging

• You already integrate other Bundles using ‘classic’ Logging ?
• Or you expect to use those bundles in the future ?
• You need flexibility of Appenders ?

→ ‘classic’ Logging is perhaps your way to go

How to get all under the same umbrella ?

Here’s an example how it could look like:

An interesting part is the LogListener – in my blog series from 2008 I used a ServiceTracker, now I’m using DeclarativeServices (DS).

you’ll find the overview of this blog series here. stay tuned… part3 follows…