Re: [osgi-dev] How to use LoggerFactory with DS?

Mon, 09 Apr 2018 06:16:29 -0700

Yes, this is the way to use the new Logger API with DS < 1.4. DS 1.4 has specific support to call to the getLogger method for the component so that you can use field and constructor injection. But to use the new Logger API with DS 1.3 and lower, you will need to method inject the LoggerFactory and call the getLogger method in the bind method.
--

BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargr...@us.ibm.com
 
 
----- Original message -----
From: "Fauth Dirk \(AA-AS/EIS2-EU\) via osgi-dev" <osgi-dev@mail.osgi.org>
Sent by: osgi-dev-boun...@mail.osgi.org
To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Cc:
Subject: [osgi-dev] How to use LoggerFactory with DS?
Date: Mon, Apr 9, 2018 6:56 AM
 

Hi,

 

as with R7 the LogService is deprecated and instead the LoggerFactory should be used, I wanted to start integrating the LoggerFactory in the Eclipse Platform. But there is not much information about how the usage should be.

 

From what I understand so far, the idea is similar to SLF4J that a Logger instance is created via LoggerFactory. The Logger provides API for logging similar to SLF4J, even with placeholder parameters and exception logging (I like that pretty much).

 

But there is one thing I am not sure if I understand everything correctly. With SLF4J the LoggerFactory is static and the best practice is to create one Logger instance per class by using the LoggerFactory on a static field. This is done to reduce the needed amount of memory for cases where a lot of instances are created of a type. With OSGi R7 the LoggerFactory is a service and not a static helper class. So for DS I need to specify a reference. But actually I don’t want the LoggerFactory, I want a Logger. And I don’t want to create a Logger instance per log statement. I therefore thought of the following pattern for getting an OSGi Logger in my component:

 

@Component

public class StringInverterImpl implements StringInverter {

 

       private Logger logger;

   

       @Override

       public String invert(String input) {

             logger.info("received {} to invert", input);

             return new StringBuilder(input).reverse().toString();

       }

 

       @Reference

       void setLoggerFactory(LoggerFactory factory) {

             this.logger = factory.getLogger(getClass());

       }

}

 

So I have a mandatory reference to LoggerFactory, and once the reference is set, I use it to get the Logger instance. Since the reference is static and mandatory I don’t need to take care if the LoggerFactory comes and goes at runtime. And as the service instance typically only exists once, there is also no memory overhead with this. For multi-instance components created by a factory, this could even have the advantage to create a Logger with a name that corresponds to the instance. Which would in turn make the log outputs more speaking in terms of knowing which component instance created the log output.

 

Would this be the recommended way of using logging in R7? Are my observations correct or do I misunderstand something?

 

I would be happy to even write a small blog post about that topic if nobody else is currently writing something with regards to logging in R7.

 

Mit freundlichen Grüßen / Best regards

Dirk Fauth

Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | www.bosch.com
Tel. +49 7153 666-1155 | dirk.fa...@de.bosch.com

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner,
Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Markus Heyn, Dr. Dirk Hoheisel,
Christoph Kübel, Uwe Raschke, Peter Tyroller


 

_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to