Hi Imesha, Will the OPSUI and all of the webapps be changed as well?
Thanks, Valerie -----Original Message----- From: Imesha Sudasingha [mailto:imesha...@cse.mrt.ac.lk] Sent: Friday, June 08, 2018 12:45 AM To: dev Subject: Re: [DISCUSSION] Logging in OODT Hi Valerie! You are welcome. I assume all others are ok with this as well? Cheers, Imesha On 5 June 2018 at 18:43, Mallder, Valerie <valerie.mall...@jhuapl.edu> wrote: > Thanks Imesha! I appreciate you taking the time to answer my question. > This is very helpful. :) > > -----Original Message----- > From: Imesha Sudasingha [mailto:imesha...@cse.mrt.ac.lk] > Sent: Tuesday, June 05, 2018 12:23 AM > To: dev > Subject: Re: [DISCUSSION] Logging in OODT > > 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 > > > > > > > > >
