You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oodt.apache.org by Imesha Sudasingha <im...@cse.mrt.ac.lk> on 2018/06/03 11:12:22 UTC
[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-route-java-util-logging-logger-jul-to-logback-using-slf4j
Cheers,
Imesha
Re: [DISCUSSION] Logging in OODT
Posted by Imesha Sudasingha <im...@cse.mrt.ac.lk>.
Hi Valerie,
I haven't though on webapps yet. Only considering file manager, resource
manager, crawler and workflow manager for now.
Even if OPSUI's backend logging changed, nothing will affect the UI or most
probably the code (if we are just redirecting JUL logs to SLF4J, no code
level changes are necessary).
So the short answer is "No, there won't be any backward incompatible
changes".
Regards,
Imesha
On 9 June 2018 at 01:43, BW <we...@apache.org> wrote:
> +1
>
> On Fri, Jun 8, 2018 at 8:37 AM Mallder, Valerie <
> Valerie.Mallder@jhuapl.edu>
> wrote:
>
> > Hi Imesha,
> >
> > Will the OPSUI and all of the webapps be changed as well?
> >
> > Thanks,
> > Valerie
> >
> > -----Original Message-----
> > From: Imesha Sudasingha [mailto:imesha.13@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 <Va...@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.13@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 <ma...@apache.org> wrote:
> > >
> > > > I think this is a great approach and am +1 for it.
> > > >
> > > >
> > > >
> > > > Cheers,
> > > >
> > > > Chris
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > From: Imesha Sudasingha <im...@cse.mrt.ac.lk>
> > > > Reply-To: <de...@oodt.apache.org>
> > > > Date: Sunday, June 3, 2018 at 4:13 AM
> > > > To: dev <de...@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
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
Re: [DISCUSSION] Logging in OODT
Posted by BW <we...@apache.org>.
+1
On Fri, Jun 8, 2018 at 8:37 AM Mallder, Valerie <Va...@jhuapl.edu>
wrote:
> Hi Imesha,
>
> Will the OPSUI and all of the webapps be changed as well?
>
> Thanks,
> Valerie
>
> -----Original Message-----
> From: Imesha Sudasingha [mailto:imesha.13@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 <Va...@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.13@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 <ma...@apache.org> wrote:
> >
> > > I think this is a great approach and am +1 for it.
> > >
> > >
> > >
> > > Cheers,
> > >
> > > Chris
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > From: Imesha Sudasingha <im...@cse.mrt.ac.lk>
> > > Reply-To: <de...@oodt.apache.org>
> > > Date: Sunday, June 3, 2018 at 4:13 AM
> > > To: dev <de...@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
> > >
> > >
> > >
> > >
> >
>
RE: [DISCUSSION] Logging in OODT
Posted by "Mallder, Valerie" <Va...@jhuapl.edu>.
Hi Imesha,
Will the OPSUI and all of the webapps be changed as well?
Thanks,
Valerie
-----Original Message-----
From: Imesha Sudasingha [mailto:imesha.13@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 <Va...@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.13@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 <ma...@apache.org> wrote:
>
> > I think this is a great approach and am +1 for it.
> >
> >
> >
> > Cheers,
> >
> > Chris
> >
> >
> >
> >
> >
> >
> >
> > From: Imesha Sudasingha <im...@cse.mrt.ac.lk>
> > Reply-To: <de...@oodt.apache.org>
> > Date: Sunday, June 3, 2018 at 4:13 AM
> > To: dev <de...@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
> >
> >
> >
> >
>
Re: [DISCUSSION] Logging in OODT
Posted by "Mattmann, Chris A (1761)" <ch...@jpl.nasa.gov>.
Yes enough time has elapsed proceed thanks
Sent from my iPhone
> On Jun 7, 2018, at 9:46 PM, Imesha Sudasingha <im...@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 <Va...@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.13@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 <ma...@apache.org> wrote:
>>>
>>> I think this is a great approach and am +1 for it.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Chris
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: Imesha Sudasingha <im...@cse.mrt.ac.lk>
>>> Reply-To: <de...@oodt.apache.org>
>>> Date: Sunday, June 3, 2018 at 4:13 AM
>>> To: dev <de...@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
>>>
>>>
>>>
>>>
>>
Re: [DISCUSSION] Logging in OODT
Posted by Imesha Sudasingha <im...@cse.mrt.ac.lk>.
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 <Va...@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.13@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 <ma...@apache.org> wrote:
>
> > I think this is a great approach and am +1 for it.
> >
> >
> >
> > Cheers,
> >
> > Chris
> >
> >
> >
> >
> >
> >
> >
> > From: Imesha Sudasingha <im...@cse.mrt.ac.lk>
> > Reply-To: <de...@oodt.apache.org>
> > Date: Sunday, June 3, 2018 at 4:13 AM
> > To: dev <de...@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
> >
> >
> >
> >
>
RE: [DISCUSSION] Logging in OODT
Posted by "Mallder, Valerie" <Va...@jhuapl.edu>.
Thanks Imesha! I appreciate you taking the time to answer my question. This is very helpful. :)
-----Original Message-----
From: Imesha Sudasingha [mailto:imesha.13@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 <ma...@apache.org> wrote:
> I think this is a great approach and am +1 for it.
>
>
>
> Cheers,
>
> Chris
>
>
>
>
>
>
>
> From: Imesha Sudasingha <im...@cse.mrt.ac.lk>
> Reply-To: <de...@oodt.apache.org>
> Date: Sunday, June 3, 2018 at 4:13 AM
> To: dev <de...@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
>
>
>
>
Re: [DISCUSSION] Logging in OODT
Posted by Imesha Sudasingha <im...@cse.mrt.ac.lk>.
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 <ma...@apache.org> wrote:
> I think this is a great approach and am +1 for it.
>
>
>
> Cheers,
>
> Chris
>
>
>
>
>
>
>
> From: Imesha Sudasingha <im...@cse.mrt.ac.lk>
> Reply-To: <de...@oodt.apache.org>
> Date: Sunday, June 3, 2018 at 4:13 AM
> To: dev <de...@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
>
>
>
>
Re: [DISCUSSION] Logging in OODT
Posted by Chris Mattmann <ma...@apache.org>.
I think this is a great approach and am +1 for it.
Cheers,
Chris
From: Imesha Sudasingha <im...@cse.mrt.ac.lk>
Reply-To: <de...@oodt.apache.org>
Date: Sunday, June 3, 2018 at 4:13 AM
To: dev <de...@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-route-java-util-logging-logger-jul-to-logback-using-slf4j
Cheers,
Imesha
RE: [DISCUSSION] Logging in OODT
Posted by "Mallder, Valerie" <Va...@jhuapl.edu>.
Hi Imesha,
Can you give me a code example of what you find inconvenient about JUL? What does log4j2 do differently? I'm not intimately familiar with it.
Thanks,
Valerie
-----Original Message-----
From: Imesha Sudasingha [mailto:imesha.13@cse.mrt.ac.lk]
Sent: Sunday, June 03, 2018 7:12 AM
To: dev
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-route-java-util-logging-logger-jul-to-logback-using-slf4j
Cheers,
Imesha