Yes enough time has elapsed proceed thanks Sent from my iPhone
> On Jun 7, 2018, at 9:46 PM, Imesha Sudasingha <imesha...@cse.mrt.ac.lk> wrote: > > 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 >>> >>> >>> >>> >>
