Hi Valerie, For example, let's say we wanted to log that the file manager started on a given port by a given user. This will be written,
in java util logging, *logger.log(Level.INFO, "File manager started at port: " + port + " by " + username + "successfully");* in SLF4J API, *logger.info <http://logger.info>("File manager started at port {} by {} successfully", port, username);* As you can see, JUL requires many string concatenations which makes it hard to write (for the programmer because he have to type many + and " marks. Compared to that, SLF4J API is easy to use and arguably more readable. And SLF4J API implementations usually support printing complex objects like lists, maps and sets rather than just calling #toString() method which will print class name and object ID. Those features will come in handy for debugging purposes. In addition to that, SLF4J implementations are better when it comes to performance. Because those log lines are formatted at the runtime only if the corresponding logging level is activated. But in JUL, no matter what the logging level is. those string concatenations needs to take place before checking the log level. From performance point of view, string concatenation is an expensive operation when we have lots of logs. Hope you got it. Thanks! Hi Chris, Yes, thanks! Imesha On 5 June 2018 at 08:10, Chris Mattmann <mattm...@apache.org> wrote: > I think this is a great approach and am +1 for it. > > > > Cheers, > > Chris > > > > > > > > From: Imesha Sudasingha <imesha...@cse.mrt.ac.lk> > Reply-To: <dev@oodt.apache.org> > Date: Sunday, June 3, 2018 at 4:13 AM > To: dev <dev@oodt.apache.org> > Subject: [DISCUSSION] Logging in OODT > > > > Hi All, > > > > When I was working on stabilizing Avro RPC versions of file manager, > > workflow manager and resource manager, it became extremely difficult to > > debug due to lack of logging in OODT. Therefore, we need more logging > > support throughout the project. Personally, I find *java.util.Logging > (JUL)* > > not convenient to use since it requires explicit string concatenation when > > logging. > > > > As a solution, I suggest to use SLF4J which has already been used partially > > in same components in OODT. Therefore, I have re-opened an existing issue > > [1] related to this and created few sub tasks. I want to know your opinion > > on following, > > > > 1. As for now, we can redirect [2] JUL logs to SLF4J logs by adding a new > > handler to existing logging.properties files. Will that be ok? In future we > > can completely remove JUL log lines. > > > > 2. Will there be any backward compatibility issue if we add log4j2 along > > with log4j2.xml's to distributions from 1.9 onwards? > > > > What are your thoughts? > > > > [1] https://issues.apache.org/jira/browse/OODT-693 > > [2] > > https://stackoverflow.com/questions/6020545/send-redirect-ro > ute-java-util-logging-logger-jul-to-logback-using-slf4j > > > > Cheers, > > Imesha > > > >
