Re: @Log annotation

[Matt Sicker]

An actual JSR would be great, and with the current development pace of
Java, I think it could actually be accepted.

On Thu, 19 Jul 2018 at 14:35, Rob Tompkins  wrote:

>
>
> > On Jul 19, 2018, at 2:35 PM, Ralph Goers 
> wrote:
> >
> > It has been brought up before. You can read about the JSR process at
> http://jcp.org .
>
> Seems like we’d want to make this a collaborative effort, particularly
> because they look for a collection of experts. I’ll see if I can come up
> with a draft that we could go over here.
>
> -Rob
>
> >
> > Ralph
> >
> >> On Jul 19, 2018, at 11:19 AM, Rob Tompkins  wrote:
> >>
> >> That doesn’t seem like a bad idea at all. Have you done that before or
> are you at least familiar with the process so that I could begin working on
> that?
> >>
> >> -Rob
> >>
> >>> On Jul 19, 2018, at 2:04 PM, Ralph Goers 
> wrote:
> >>>
> >>> We should really propose a new Logging JSR.  I would make sure it
> includes the ability for the compiler to provide the class name, method
> name and line number as “special” variables.
> >>>
> >>> Ralph
> >>>
>  On Jul 19, 2018, at 10:53 AM, Gary Gregory 
> wrote:
> 
>  Maybe the smallest feature we could/should start with it a
>  class-level @ClassLogger() annotation which create a static final
> Logger
>  initialized with the class name. Too bad Java does not have what
> Smalltalk
>  calls class instance variables.
> 
>  I am using "ClassLogger" like JUnit has ClassRule so it leave room for
>  a @Logger like JUnit has @Rule.
> 
>  Gary
> 
>  On Thu, Jul 19, 2018 at 11:43 AM Rob Tompkins 
> wrote:
> 
> >
> >
> >> On Jul 19, 2018, at 1:41 PM, Ralph Goers <
> ralph.go...@dslextreme.com>
> > wrote:
> >>
> >> To be clear, Log4j-core should have no required dependencies other
> than
> > Log4j-API. And we would like to keep optional dependencies to a
> minimum.
> >
> > Right that makes sense to me. Hence it being an after thought, and I
> like
> > Gary’s suggestion of a compile time dependency for the sake of
> weaving.
> >
> >>
> >> Ralph
> >>
> >>> On Jul 19, 2018, at 10:36 AM, Gary Gregory  >
> > wrote:
> >>>
> >>> eOn Thu, Jul 19, 2018 at 10:19 AM Rob Tompkins  > > wrote:
> >>>
> 
> 
> > On Jul 19, 2018, at 11:48 AM, Gary Gregory <
> garydgreg...@gmail.com>
>  wrote:
> >
> > FTR: https://projectlombok.org/features/log
> >
> > On Thu, Jul 19, 2018 at 8:48 AM Gary Gregory <
> garydgreg...@gmail.com>
>  wrote:
> >
> >>
> >>
> >> On Thu, Jul 19, 2018 at 8:26 AM Rob Tompkins <
> chtom...@gmail.com>
>  wrote:
> >>
> >>>
> >>>
>  On Jul 19, 2018, at 10:17 AM, Gary Gregory <
> garydgreg...@gmail.com
> >>
> >>> wrote:
> 
>  On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins <
> chtom...@gmail.com>
> >>> wrote:
> 
> >
> >
> >> On Jul 19, 2018, at 9:29 AM, Gary Gregory <
> > garydgreg...@gmail.com>
> > wrote:
> >>
> >> Annotation-based logging comes up once in a while here but
> we
> > have
>  not
> >> implemented it. Project Lombok does that IIRC.
> >
> > Any reason for having not yet implemented it, or just the
> standard
> >>> “time”?
> >
> 
>  It's just more "stuff" and yes, time. And also, no one's
> wanted to
> > put
> >>> the
>  time in.
> 
>  But then there are design issues and adding more "stuff" to
> the API
>  jar.
> 
>  - Would you allow @Log(level=Level.TRACE) (should be the
> default?)
> > and
>  @Log(level=Level.DEBUG)
>  - What happens if you say both?
>  - Should you be able to break it up and only say @LogEntry()
> or
> >>> @LogExit().
>  - What about @Log(file="${user.home}\foo.log")
>  - and on and on ;-)
> >>>
> >>> Definitely fair points, I think I would try to go as simple as
> > possible
> >>> in a first pass…right?
> >>>
> >>> @Log
> >>> @Log(level=X)
> >>>
> >>
> >> Well, yes. But we need to think about the scope of the
> annotation.
> > The
> >> name @Log is as broad as you can think of making the name. So
> if we
>  want to
> >> put more in there later, then we need to make sure that's the
> best
> > name.
> >>
> >> Do you think
> >>
> >> @Log()
> >>
> >> could be the default for (for example)
> >>
> >> @Log(level=Level.TRACE, entry=true, entryParameters=ALL,
> exit=true,
> >> 

Re: @Log annotation

[Rob Tompkins]

> On Jul 19, 2018, at 2:35 PM, Ralph Goers  wrote:
> 
> It has been brought up before. You can read about the JSR process at 
> http://jcp.org .

Seems like we’d want to make this a collaborative effort, particularly because 
they look for a collection of experts. I’ll see if I can come up with a draft 
that we could go over here.

-Rob

> 
> Ralph
> 
>> On Jul 19, 2018, at 11:19 AM, Rob Tompkins  wrote:
>> 
>> That doesn’t seem like a bad idea at all. Have you done that before or are 
>> you at least familiar with the process so that I could begin working on that?
>> 
>> -Rob
>> 
>>> On Jul 19, 2018, at 2:04 PM, Ralph Goers  wrote:
>>> 
>>> We should really propose a new Logging JSR.  I would make sure it includes 
>>> the ability for the compiler to provide the class name, method name and 
>>> line number as “special” variables.
>>> 
>>> Ralph
>>> 
 On Jul 19, 2018, at 10:53 AM, Gary Gregory  wrote:
 
 Maybe the smallest feature we could/should start with it a
 class-level @ClassLogger() annotation which create a static final Logger
 initialized with the class name. Too bad Java does not have what Smalltalk
 calls class instance variables.
 
 I am using "ClassLogger" like JUnit has ClassRule so it leave room for
 a @Logger like JUnit has @Rule.
 
 Gary
 
 On Thu, Jul 19, 2018 at 11:43 AM Rob Tompkins  wrote:
 
> 
> 
>> On Jul 19, 2018, at 1:41 PM, Ralph Goers 
> wrote:
>> 
>> To be clear, Log4j-core should have no required dependencies other than
> Log4j-API. And we would like to keep optional dependencies to a minimum.
> 
> Right that makes sense to me. Hence it being an after thought, and I like
> Gary’s suggestion of a compile time dependency for the sake of weaving.
> 
>> 
>> Ralph
>> 
>>> On Jul 19, 2018, at 10:36 AM, Gary Gregory 
> wrote:
>>> 
>>> eOn Thu, Jul 19, 2018 at 10:19 AM Rob Tompkins  > wrote:
>>> 
 
 
> On Jul 19, 2018, at 11:48 AM, Gary Gregory 
 wrote:
> 
> FTR: https://projectlombok.org/features/log
> 
> On Thu, Jul 19, 2018 at 8:48 AM Gary Gregory 
 wrote:
> 
>> 
>> 
>> On Thu, Jul 19, 2018 at 8:26 AM Rob Tompkins 
 wrote:
>> 
>>> 
>>> 
 On Jul 19, 2018, at 10:17 AM, Gary Gregory > 
>>> wrote:
 
 On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins 
>>> wrote:
 
> 
> 
>> On Jul 19, 2018, at 9:29 AM, Gary Gregory <
> garydgreg...@gmail.com>
> wrote:
>> 
>> Annotation-based logging comes up once in a while here but we
> have
 not
>> implemented it. Project Lombok does that IIRC.
> 
> Any reason for having not yet implemented it, or just the standard
>>> “time”?
> 
 
 It's just more "stuff" and yes, time. And also, no one's wanted to
> put
>>> the
 time in.
 
 But then there are design issues and adding more "stuff" to the API
 jar.
 
 - Would you allow @Log(level=Level.TRACE) (should be the default?)
> and
 @Log(level=Level.DEBUG)
 - What happens if you say both?
 - Should you be able to break it up and only say @LogEntry() or
>>> @LogExit().
 - What about @Log(file="${user.home}\foo.log")
 - and on and on ;-)
>>> 
>>> Definitely fair points, I think I would try to go as simple as
> possible
>>> in a first pass…right?
>>> 
>>> @Log
>>> @Log(level=X)
>>> 
>> 
>> Well, yes. But we need to think about the scope of the annotation.
> The
>> name @Log is as broad as you can think of making the name. So if we
 want to
>> put more in there later, then we need to make sure that's the best
> name.
>> 
>> Do you think
>> 
>> @Log()
>> 
>> could be the default for (for example)
>> 
>> @Log(level=Level.TRACE, entry=true, entryParameters=ALL, exit=true,
>> exitValue=true)
>> 
>> Where entryParameters (if on a method) would let me list which params
 for
>> that methods to log)
>> 
>> How do I avoid logging a password argument for example? Sounds like
> we
 can
>> do away with entryParameters if we have a @LogHide to annotate a
>> parameter.
>> 
>> I could see that as step one but we need to think about all that we
 would
>> want to do to make sure @Log is the right name. What's a name that
> says
 log
>> all 

Re: @Log annotation

[Ralph Goers]

It has been brought up before. You can read about the JSR process at 
http://jcp.org .

Ralph

> On Jul 19, 2018, at 11:19 AM, Rob Tompkins  wrote:
> 
> That doesn’t seem like a bad idea at all. Have you done that before or are 
> you at least familiar with the process so that I could begin working on that?
> 
> -Rob
> 
>> On Jul 19, 2018, at 2:04 PM, Ralph Goers  wrote:
>> 
>> We should really propose a new Logging JSR.  I would make sure it includes 
>> the ability for the compiler to provide the class name, method name and line 
>> number as “special” variables.
>> 
>> Ralph
>> 
>>> On Jul 19, 2018, at 10:53 AM, Gary Gregory  wrote:
>>> 
>>> Maybe the smallest feature we could/should start with it a
>>> class-level @ClassLogger() annotation which create a static final Logger
>>> initialized with the class name. Too bad Java does not have what Smalltalk
>>> calls class instance variables.
>>> 
>>> I am using "ClassLogger" like JUnit has ClassRule so it leave room for
>>> a @Logger like JUnit has @Rule.
>>> 
>>> Gary
>>> 
>>> On Thu, Jul 19, 2018 at 11:43 AM Rob Tompkins  wrote:
>>> 
 
 
> On Jul 19, 2018, at 1:41 PM, Ralph Goers 
 wrote:
> 
> To be clear, Log4j-core should have no required dependencies other than
 Log4j-API. And we would like to keep optional dependencies to a minimum.
 
 Right that makes sense to me. Hence it being an after thought, and I like
 Gary’s suggestion of a compile time dependency for the sake of weaving.
 
> 
> Ralph
> 
>> On Jul 19, 2018, at 10:36 AM, Gary Gregory 
 wrote:
>> 
>> eOn Thu, Jul 19, 2018 at 10:19 AM Rob Tompkins >>> > wrote:
>> 
>>> 
>>> 
 On Jul 19, 2018, at 11:48 AM, Gary Gregory 
>>> wrote:
 
 FTR: https://projectlombok.org/features/log
 
 On Thu, Jul 19, 2018 at 8:48 AM Gary Gregory 
>>> wrote:
 
> 
> 
> On Thu, Jul 19, 2018 at 8:26 AM Rob Tompkins 
>>> wrote:
> 
>> 
>> 
>>> On Jul 19, 2018, at 10:17 AM, Gary Gregory  
>> wrote:
>>> 
>>> On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins 
>> wrote:
>>> 
 
 
> On Jul 19, 2018, at 9:29 AM, Gary Gregory <
 garydgreg...@gmail.com>
 wrote:
> 
> Annotation-based logging comes up once in a while here but we
 have
>>> not
> implemented it. Project Lombok does that IIRC.
 
 Any reason for having not yet implemented it, or just the standard
>> “time”?
 
>>> 
>>> It's just more "stuff" and yes, time. And also, no one's wanted to
 put
>> the
>>> time in.
>>> 
>>> But then there are design issues and adding more "stuff" to the API
>>> jar.
>>> 
>>> - Would you allow @Log(level=Level.TRACE) (should be the default?)
 and
>>> @Log(level=Level.DEBUG)
>>> - What happens if you say both?
>>> - Should you be able to break it up and only say @LogEntry() or
>> @LogExit().
>>> - What about @Log(file="${user.home}\foo.log")
>>> - and on and on ;-)
>> 
>> Definitely fair points, I think I would try to go as simple as
 possible
>> in a first pass…right?
>> 
>> @Log
>> @Log(level=X)
>> 
> 
> Well, yes. But we need to think about the scope of the annotation.
 The
> name @Log is as broad as you can think of making the name. So if we
>>> want to
> put more in there later, then we need to make sure that's the best
 name.
> 
> Do you think
> 
> @Log()
> 
> could be the default for (for example)
> 
> @Log(level=Level.TRACE, entry=true, entryParameters=ALL, exit=true,
> exitValue=true)
> 
> Where entryParameters (if on a method) would let me list which params
>>> for
> that methods to log)
> 
> How do I avoid logging a password argument for example? Sounds like
 we
>>> can
> do away with entryParameters if we have a @LogHide to annotate a
> parameter.
> 
> I could see that as step one but we need to think about all that we
>>> would
> want to do to make sure @Log is the right name. What's a name that
 says
>>> log
> all entries and exits?  @LogEntryExit?
> 
> Overall I would think that this kind of annotated class would change
>>> that
> class' byte codes after compilation so that there are no runtime
> requirements even for annotations. I certainly would not want to
 leave
> behind clues like @LogHide to would be attackers
> 
> Thoughts?
>>> 
>>> 

Re: @Log annotation

[Rob Tompkins]

That doesn’t seem like a bad idea at all. Have you done that before or are you 
at least familiar with the process so that I could begin working on that?

-Rob

> On Jul 19, 2018, at 2:04 PM, Ralph Goers  wrote:
> 
> We should really propose a new Logging JSR.  I would make sure it includes 
> the ability for the compiler to provide the class name, method name and line 
> number as “special” variables.
> 
> Ralph
> 
>> On Jul 19, 2018, at 10:53 AM, Gary Gregory  wrote:
>> 
>> Maybe the smallest feature we could/should start with it a
>> class-level @ClassLogger() annotation which create a static final Logger
>> initialized with the class name. Too bad Java does not have what Smalltalk
>> calls class instance variables.
>> 
>> I am using "ClassLogger" like JUnit has ClassRule so it leave room for
>> a @Logger like JUnit has @Rule.
>> 
>> Gary
>> 
>> On Thu, Jul 19, 2018 at 11:43 AM Rob Tompkins  wrote:
>> 
>>> 
>>> 
 On Jul 19, 2018, at 1:41 PM, Ralph Goers 
>>> wrote:
 
 To be clear, Log4j-core should have no required dependencies other than
>>> Log4j-API. And we would like to keep optional dependencies to a minimum.
>>> 
>>> Right that makes sense to me. Hence it being an after thought, and I like
>>> Gary’s suggestion of a compile time dependency for the sake of weaving.
>>> 
 
 Ralph
 
> On Jul 19, 2018, at 10:36 AM, Gary Gregory 
>>> wrote:
> 
> eOn Thu, Jul 19, 2018 at 10:19 AM Rob Tompkins >> > wrote:
> 
>> 
>> 
>>> On Jul 19, 2018, at 11:48 AM, Gary Gregory 
>> wrote:
>>> 
>>> FTR: https://projectlombok.org/features/log
>>> 
>>> On Thu, Jul 19, 2018 at 8:48 AM Gary Gregory 
>> wrote:
>>> 
 
 
 On Thu, Jul 19, 2018 at 8:26 AM Rob Tompkins 
>> wrote:
 
> 
> 
>> On Jul 19, 2018, at 10:17 AM, Gary Gregory >>> 
> wrote:
>> 
>> On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins 
> wrote:
>> 
>>> 
>>> 
 On Jul 19, 2018, at 9:29 AM, Gary Gregory <
>>> garydgreg...@gmail.com>
>>> wrote:
 
 Annotation-based logging comes up once in a while here but we
>>> have
>> not
 implemented it. Project Lombok does that IIRC.
>>> 
>>> Any reason for having not yet implemented it, or just the standard
> “time”?
>>> 
>> 
>> It's just more "stuff" and yes, time. And also, no one's wanted to
>>> put
> the
>> time in.
>> 
>> But then there are design issues and adding more "stuff" to the API
>> jar.
>> 
>> - Would you allow @Log(level=Level.TRACE) (should be the default?)
>>> and
>> @Log(level=Level.DEBUG)
>> - What happens if you say both?
>> - Should you be able to break it up and only say @LogEntry() or
> @LogExit().
>> - What about @Log(file="${user.home}\foo.log")
>> - and on and on ;-)
> 
> Definitely fair points, I think I would try to go as simple as
>>> possible
> in a first pass…right?
> 
> @Log
> @Log(level=X)
> 
 
 Well, yes. But we need to think about the scope of the annotation.
>>> The
 name @Log is as broad as you can think of making the name. So if we
>> want to
 put more in there later, then we need to make sure that's the best
>>> name.
 
 Do you think
 
 @Log()
 
 could be the default for (for example)
 
 @Log(level=Level.TRACE, entry=true, entryParameters=ALL, exit=true,
 exitValue=true)
 
 Where entryParameters (if on a method) would let me list which params
>> for
 that methods to log)
 
 How do I avoid logging a password argument for example? Sounds like
>>> we
>> can
 do away with entryParameters if we have a @LogHide to annotate a
 parameter.
 
 I could see that as step one but we need to think about all that we
>> would
 want to do to make sure @Log is the right name. What's a name that
>>> says
>> log
 all entries and exits?  @LogEntryExit?
 
 Overall I would think that this kind of annotated class would change
>> that
 class' byte codes after compilation so that there are no runtime
 requirements even for annotations. I certainly would not want to
>>> leave
 behind clues like @LogHide to would be attackers
 
 Thoughts?
>> 
>> I think that @Log is the wrong name because it’s quite vague. Maybe
>> @LogMethodCalls, or as you suggest @LogEntryExit.
>> 
>> I like the signature you suggested @Gary.
>> 
>> @Matt - As for mechanics, I would think we would want to do compile
>>> time
>> byte code weaving. (Is there any appetite for 

Re: @Log annotation

[Ralph Goers]

We should really propose a new Logging JSR.  I would make sure it includes the 
ability for the compiler to provide the class name, method name and line number 
as “special” variables.

Ralph

> On Jul 19, 2018, at 10:53 AM, Gary Gregory  wrote:
> 
> Maybe the smallest feature we could/should start with it a
> class-level @ClassLogger() annotation which create a static final Logger
> initialized with the class name. Too bad Java does not have what Smalltalk
> calls class instance variables.
> 
> I am using "ClassLogger" like JUnit has ClassRule so it leave room for
> a @Logger like JUnit has @Rule.
> 
> Gary
> 
> On Thu, Jul 19, 2018 at 11:43 AM Rob Tompkins  wrote:
> 
>> 
>> 
>>> On Jul 19, 2018, at 1:41 PM, Ralph Goers 
>> wrote:
>>> 
>>> To be clear, Log4j-core should have no required dependencies other than
>> Log4j-API. And we would like to keep optional dependencies to a minimum.
>> 
>> Right that makes sense to me. Hence it being an after thought, and I like
>> Gary’s suggestion of a compile time dependency for the sake of weaving.
>> 
>>> 
>>> Ralph
>>> 
 On Jul 19, 2018, at 10:36 AM, Gary Gregory 
>> wrote:
 
 eOn Thu, Jul 19, 2018 at 10:19 AM Rob Tompkins > > wrote:
 
> 
> 
>> On Jul 19, 2018, at 11:48 AM, Gary Gregory 
> wrote:
>> 
>> FTR: https://projectlombok.org/features/log
>> 
>> On Thu, Jul 19, 2018 at 8:48 AM Gary Gregory 
> wrote:
>> 
>>> 
>>> 
>>> On Thu, Jul 19, 2018 at 8:26 AM Rob Tompkins 
> wrote:
>>> 
 
 
> On Jul 19, 2018, at 10:17 AM, Gary Gregory >> 
 wrote:
> 
> On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins 
 wrote:
> 
>> 
>> 
>>> On Jul 19, 2018, at 9:29 AM, Gary Gregory <
>> garydgreg...@gmail.com>
>> wrote:
>>> 
>>> Annotation-based logging comes up once in a while here but we
>> have
> not
>>> implemented it. Project Lombok does that IIRC.
>> 
>> Any reason for having not yet implemented it, or just the standard
 “time”?
>> 
> 
> It's just more "stuff" and yes, time. And also, no one's wanted to
>> put
 the
> time in.
> 
> But then there are design issues and adding more "stuff" to the API
> jar.
> 
> - Would you allow @Log(level=Level.TRACE) (should be the default?)
>> and
> @Log(level=Level.DEBUG)
> - What happens if you say both?
> - Should you be able to break it up and only say @LogEntry() or
 @LogExit().
> - What about @Log(file="${user.home}\foo.log")
> - and on and on ;-)
 
 Definitely fair points, I think I would try to go as simple as
>> possible
 in a first pass…right?
 
 @Log
 @Log(level=X)
 
>>> 
>>> Well, yes. But we need to think about the scope of the annotation.
>> The
>>> name @Log is as broad as you can think of making the name. So if we
> want to
>>> put more in there later, then we need to make sure that's the best
>> name.
>>> 
>>> Do you think
>>> 
>>> @Log()
>>> 
>>> could be the default for (for example)
>>> 
>>> @Log(level=Level.TRACE, entry=true, entryParameters=ALL, exit=true,
>>> exitValue=true)
>>> 
>>> Where entryParameters (if on a method) would let me list which params
> for
>>> that methods to log)
>>> 
>>> How do I avoid logging a password argument for example? Sounds like
>> we
> can
>>> do away with entryParameters if we have a @LogHide to annotate a
>>> parameter.
>>> 
>>> I could see that as step one but we need to think about all that we
> would
>>> want to do to make sure @Log is the right name. What's a name that
>> says
> log
>>> all entries and exits?  @LogEntryExit?
>>> 
>>> Overall I would think that this kind of annotated class would change
> that
>>> class' byte codes after compilation so that there are no runtime
>>> requirements even for annotations. I certainly would not want to
>> leave
>>> behind clues like @LogHide to would be attackers
>>> 
>>> Thoughts?
> 
> I think that @Log is the wrong name because it’s quite vague. Maybe
> @LogMethodCalls, or as you suggest @LogEntryExit.
> 
> I like the signature you suggested @Gary.
> 
> @Matt - As for mechanics, I would think we would want to do compile
>> time
> byte code weaving. (Is there any appetite for using aspectJ? Feels
>> like a
> large ask to add a dependency to log4j2 though.)
> 
 
 I've not lloked at AspectJ for a long time, not sure it requires a
>> runtime;
 I think we want a compile time only dep, Apache Commson Weaver or Apache
 Commons BCEL come to mind.
 
 Gary
 
 
> 
>>> 
>>> Gary
>>> 
>>> 

Re: @Log annotation

[Gary Gregory]

Maybe the smallest feature we could/should start with it a
class-level @ClassLogger() annotation which create a static final Logger
initialized with the class name. Too bad Java does not have what Smalltalk
calls class instance variables.

I am using "ClassLogger" like JUnit has ClassRule so it leave room for
a @Logger like JUnit has @Rule.

Gary

On Thu, Jul 19, 2018 at 11:43 AM Rob Tompkins  wrote:

>
>
> > On Jul 19, 2018, at 1:41 PM, Ralph Goers 
> wrote:
> >
> > To be clear, Log4j-core should have no required dependencies other than
> Log4j-API. And we would like to keep optional dependencies to a minimum.
>
> Right that makes sense to me. Hence it being an after thought, and I like
> Gary’s suggestion of a compile time dependency for the sake of weaving.
>
> >
> > Ralph
> >
> >> On Jul 19, 2018, at 10:36 AM, Gary Gregory 
> wrote:
> >>
> >> eOn Thu, Jul 19, 2018 at 10:19 AM Rob Tompkins  > wrote:
> >>
> >>>
> >>>
>  On Jul 19, 2018, at 11:48 AM, Gary Gregory 
> >>> wrote:
> 
>  FTR: https://projectlombok.org/features/log
> 
>  On Thu, Jul 19, 2018 at 8:48 AM Gary Gregory 
> >>> wrote:
> 
> >
> >
> > On Thu, Jul 19, 2018 at 8:26 AM Rob Tompkins 
> >>> wrote:
> >
> >>
> >>
> >>> On Jul 19, 2018, at 10:17 AM, Gary Gregory  >
> >> wrote:
> >>>
> >>> On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins 
> >> wrote:
> >>>
> 
> 
> > On Jul 19, 2018, at 9:29 AM, Gary Gregory <
> garydgreg...@gmail.com>
>  wrote:
> >
> > Annotation-based logging comes up once in a while here but we
> have
> >>> not
> > implemented it. Project Lombok does that IIRC.
> 
>  Any reason for having not yet implemented it, or just the standard
> >> “time”?
> 
> >>>
> >>> It's just more "stuff" and yes, time. And also, no one's wanted to
> put
> >> the
> >>> time in.
> >>>
> >>> But then there are design issues and adding more "stuff" to the API
> >>> jar.
> >>>
> >>> - Would you allow @Log(level=Level.TRACE) (should be the default?)
> and
> >>> @Log(level=Level.DEBUG)
> >>> - What happens if you say both?
> >>> - Should you be able to break it up and only say @LogEntry() or
> >> @LogExit().
> >>> - What about @Log(file="${user.home}\foo.log")
> >>> - and on and on ;-)
> >>
> >> Definitely fair points, I think I would try to go as simple as
> possible
> >> in a first pass…right?
> >>
> >> @Log
> >> @Log(level=X)
> >>
> >
> > Well, yes. But we need to think about the scope of the annotation.
> The
> > name @Log is as broad as you can think of making the name. So if we
> >>> want to
> > put more in there later, then we need to make sure that's the best
> name.
> >
> > Do you think
> >
> > @Log()
> >
> > could be the default for (for example)
> >
> > @Log(level=Level.TRACE, entry=true, entryParameters=ALL, exit=true,
> > exitValue=true)
> >
> > Where entryParameters (if on a method) would let me list which params
> >>> for
> > that methods to log)
> >
> > How do I avoid logging a password argument for example? Sounds like
> we
> >>> can
> > do away with entryParameters if we have a @LogHide to annotate a
> > parameter.
> >
> > I could see that as step one but we need to think about all that we
> >>> would
> > want to do to make sure @Log is the right name. What's a name that
> says
> >>> log
> > all entries and exits?  @LogEntryExit?
> >
> > Overall I would think that this kind of annotated class would change
> >>> that
> > class' byte codes after compilation so that there are no runtime
> > requirements even for annotations. I certainly would not want to
> leave
> > behind clues like @LogHide to would be attackers
> >
> > Thoughts?
> >>>
> >>> I think that @Log is the wrong name because it’s quite vague. Maybe
> >>> @LogMethodCalls, or as you suggest @LogEntryExit.
> >>>
> >>> I like the signature you suggested @Gary.
> >>>
> >>> @Matt - As for mechanics, I would think we would want to do compile
> time
> >>> byte code weaving. (Is there any appetite for using aspectJ? Feels
> like a
> >>> large ask to add a dependency to log4j2 though.)
> >>>
> >>
> >> I've not lloked at AspectJ for a long time, not sure it requires a
> runtime;
> >> I think we want a compile time only dep, Apache Commson Weaver or Apache
> >> Commons BCEL come to mind.
> >>
> >> Gary
> >>
> >>
> >>>
> >
> > Gary
> >
> >
> >> -Rob
> >>
> >>>
> >>> Gary
> >>>
> >>>
> 
> >
> > Gary
> >
> > On Thu, Jul 19, 2018, 07:15 Rob Tompkins  >
> >>> wrote:
> >
> >> Hey folks,
> >>
> >> I’m curious if anyone has thought about adding a class level
> @Log
> 

Re: @Log annotation

[Rob Tompkins]

> On Jul 19, 2018, at 1:41 PM, Ralph Goers  wrote:
> 
> To be clear, Log4j-core should have no required dependencies other than 
> Log4j-API. And we would like to keep optional dependencies to a minimum.

Right that makes sense to me. Hence it being an after thought, and I like 
Gary’s suggestion of a compile time dependency for the sake of weaving.

> 
> Ralph
> 
>> On Jul 19, 2018, at 10:36 AM, Gary Gregory  wrote:
>> 
>> eOn Thu, Jul 19, 2018 at 10:19 AM Rob Tompkins > > wrote:
>> 
>>> 
>>> 
 On Jul 19, 2018, at 11:48 AM, Gary Gregory 
>>> wrote:
 
 FTR: https://projectlombok.org/features/log
 
 On Thu, Jul 19, 2018 at 8:48 AM Gary Gregory 
>>> wrote:
 
> 
> 
> On Thu, Jul 19, 2018 at 8:26 AM Rob Tompkins 
>>> wrote:
> 
>> 
>> 
>>> On Jul 19, 2018, at 10:17 AM, Gary Gregory 
>> wrote:
>>> 
>>> On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins 
>> wrote:
>>> 
 
 
> On Jul 19, 2018, at 9:29 AM, Gary Gregory 
 wrote:
> 
> Annotation-based logging comes up once in a while here but we have
>>> not
> implemented it. Project Lombok does that IIRC.
 
 Any reason for having not yet implemented it, or just the standard
>> “time”?
 
>>> 
>>> It's just more "stuff" and yes, time. And also, no one's wanted to put
>> the
>>> time in.
>>> 
>>> But then there are design issues and adding more "stuff" to the API
>>> jar.
>>> 
>>> - Would you allow @Log(level=Level.TRACE) (should be the default?) and
>>> @Log(level=Level.DEBUG)
>>> - What happens if you say both?
>>> - Should you be able to break it up and only say @LogEntry() or
>> @LogExit().
>>> - What about @Log(file="${user.home}\foo.log")
>>> - and on and on ;-)
>> 
>> Definitely fair points, I think I would try to go as simple as possible
>> in a first pass…right?
>> 
>> @Log
>> @Log(level=X)
>> 
> 
> Well, yes. But we need to think about the scope of the annotation. The
> name @Log is as broad as you can think of making the name. So if we
>>> want to
> put more in there later, then we need to make sure that's the best name.
> 
> Do you think
> 
> @Log()
> 
> could be the default for (for example)
> 
> @Log(level=Level.TRACE, entry=true, entryParameters=ALL, exit=true,
> exitValue=true)
> 
> Where entryParameters (if on a method) would let me list which params
>>> for
> that methods to log)
> 
> How do I avoid logging a password argument for example? Sounds like we
>>> can
> do away with entryParameters if we have a @LogHide to annotate a
> parameter.
> 
> I could see that as step one but we need to think about all that we
>>> would
> want to do to make sure @Log is the right name. What's a name that says
>>> log
> all entries and exits?  @LogEntryExit?
> 
> Overall I would think that this kind of annotated class would change
>>> that
> class' byte codes after compilation so that there are no runtime
> requirements even for annotations. I certainly would not want to leave
> behind clues like @LogHide to would be attackers
> 
> Thoughts?
>>> 
>>> I think that @Log is the wrong name because it’s quite vague. Maybe
>>> @LogMethodCalls, or as you suggest @LogEntryExit.
>>> 
>>> I like the signature you suggested @Gary.
>>> 
>>> @Matt - As for mechanics, I would think we would want to do compile time
>>> byte code weaving. (Is there any appetite for using aspectJ? Feels like a
>>> large ask to add a dependency to log4j2 though.)
>>> 
>> 
>> I've not lloked at AspectJ for a long time, not sure it requires a runtime;
>> I think we want a compile time only dep, Apache Commson Weaver or Apache
>> Commons BCEL come to mind.
>> 
>> Gary
>> 
>> 
>>> 
> 
> Gary
> 
> 
>> -Rob
>> 
>>> 
>>> Gary
>>> 
>>> 
 
> 
> Gary
> 
> On Thu, Jul 19, 2018, 07:15 Rob Tompkins  >
>>> wrote:
> 
>> Hey folks,
>> 
>> I’m curious if anyone has thought about adding a class level @Log
>> annotation such that upon debug or trace configuration, method
>>> entry
>> and
>> exit gets automatically logged?
>> 
>> -Rob
> 

Re: @Log annotation

[Ralph Goers]

To be clear, Log4j-core should have no required dependencies other than 
Log4j-API. And we would like to keep optional dependencies to a minimum.

Ralph

> On Jul 19, 2018, at 10:36 AM, Gary Gregory  wrote:
> 
> eOn Thu, Jul 19, 2018 at 10:19 AM Rob Tompkins  > wrote:
> 
>> 
>> 
>>> On Jul 19, 2018, at 11:48 AM, Gary Gregory 
>> wrote:
>>> 
>>> FTR: https://projectlombok.org/features/log
>>> 
>>> On Thu, Jul 19, 2018 at 8:48 AM Gary Gregory 
>> wrote:
>>> 
 
 
 On Thu, Jul 19, 2018 at 8:26 AM Rob Tompkins 
>> wrote:
 
> 
> 
>> On Jul 19, 2018, at 10:17 AM, Gary Gregory 
> wrote:
>> 
>> On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins 
> wrote:
>> 
>>> 
>>> 
 On Jul 19, 2018, at 9:29 AM, Gary Gregory 
>>> wrote:
 
 Annotation-based logging comes up once in a while here but we have
>> not
 implemented it. Project Lombok does that IIRC.
>>> 
>>> Any reason for having not yet implemented it, or just the standard
> “time”?
>>> 
>> 
>> It's just more "stuff" and yes, time. And also, no one's wanted to put
> the
>> time in.
>> 
>> But then there are design issues and adding more "stuff" to the API
>> jar.
>> 
>> - Would you allow @Log(level=Level.TRACE) (should be the default?) and
>> @Log(level=Level.DEBUG)
>> - What happens if you say both?
>> - Should you be able to break it up and only say @LogEntry() or
> @LogExit().
>> - What about @Log(file="${user.home}\foo.log")
>> - and on and on ;-)
> 
> Definitely fair points, I think I would try to go as simple as possible
> in a first pass…right?
> 
> @Log
> @Log(level=X)
> 
 
 Well, yes. But we need to think about the scope of the annotation. The
 name @Log is as broad as you can think of making the name. So if we
>> want to
 put more in there later, then we need to make sure that's the best name.
 
 Do you think
 
 @Log()
 
 could be the default for (for example)
 
 @Log(level=Level.TRACE, entry=true, entryParameters=ALL, exit=true,
 exitValue=true)
 
 Where entryParameters (if on a method) would let me list which params
>> for
 that methods to log)
 
 How do I avoid logging a password argument for example? Sounds like we
>> can
 do away with entryParameters if we have a @LogHide to annotate a
 parameter.
 
 I could see that as step one but we need to think about all that we
>> would
 want to do to make sure @Log is the right name. What's a name that says
>> log
 all entries and exits?  @LogEntryExit?
 
 Overall I would think that this kind of annotated class would change
>> that
 class' byte codes after compilation so that there are no runtime
 requirements even for annotations. I certainly would not want to leave
 behind clues like @LogHide to would be attackers
 
 Thoughts?
>> 
>> I think that @Log is the wrong name because it’s quite vague. Maybe
>> @LogMethodCalls, or as you suggest @LogEntryExit.
>> 
>> I like the signature you suggested @Gary.
>> 
>> @Matt - As for mechanics, I would think we would want to do compile time
>> byte code weaving. (Is there any appetite for using aspectJ? Feels like a
>> large ask to add a dependency to log4j2 though.)
>> 
> 
> I've not lloked at AspectJ for a long time, not sure it requires a runtime;
> I think we want a compile time only dep, Apache Commson Weaver or Apache
> Commons BCEL come to mind.
> 
> Gary
> 
> 
>> 
 
 Gary
 
 
> -Rob
> 
>> 
>> Gary
>> 
>> 
>>> 
 
 Gary
 
 On Thu, Jul 19, 2018, 07:15 Rob Tompkins >>> >
>> wrote:
 
> Hey folks,
> 
> I’m curious if anyone has thought about adding a class level @Log
> annotation such that upon debug or trace configuration, method
>> entry
> and
> exit gets automatically logged?
> 
> -Rob

Re: @Log annotation

[Rob Tompkins]

> On Jul 19, 2018, at 11:48 AM, Gary Gregory  wrote:
> 
> FTR: https://projectlombok.org/features/log
> 
> On Thu, Jul 19, 2018 at 8:48 AM Gary Gregory  wrote:
> 
>> 
>> 
>> On Thu, Jul 19, 2018 at 8:26 AM Rob Tompkins  wrote:
>> 
>>> 
>>> 
 On Jul 19, 2018, at 10:17 AM, Gary Gregory 
>>> wrote:
 
 On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins 
>>> wrote:
 
> 
> 
>> On Jul 19, 2018, at 9:29 AM, Gary Gregory 
> wrote:
>> 
>> Annotation-based logging comes up once in a while here but we have not
>> implemented it. Project Lombok does that IIRC.
> 
> Any reason for having not yet implemented it, or just the standard
>>> “time”?
> 
 
 It's just more "stuff" and yes, time. And also, no one's wanted to put
>>> the
 time in.
 
 But then there are design issues and adding more "stuff" to the API jar.
 
 - Would you allow @Log(level=Level.TRACE) (should be the default?) and
 @Log(level=Level.DEBUG)
 - What happens if you say both?
 - Should you be able to break it up and only say @LogEntry() or
>>> @LogExit().
 - What about @Log(file="${user.home}\foo.log")
 - and on and on ;-)
>>> 
>>> Definitely fair points, I think I would try to go as simple as possible
>>> in a first pass…right?
>>> 
>>> @Log
>>> @Log(level=X)
>>> 
>> 
>> Well, yes. But we need to think about the scope of the annotation. The
>> name @Log is as broad as you can think of making the name. So if we want to
>> put more in there later, then we need to make sure that's the best name.
>> 
>> Do you think
>> 
>> @Log()
>> 
>> could be the default for (for example)
>> 
>> @Log(level=Level.TRACE, entry=true, entryParameters=ALL, exit=true,
>> exitValue=true)
>> 
>> Where entryParameters (if on a method) would let me list which params for
>> that methods to log)
>> 
>> How do I avoid logging a password argument for example? Sounds like we can
>> do away with entryParameters if we have a @LogHide to annotate a
>> parameter.
>> 
>> I could see that as step one but we need to think about all that we would
>> want to do to make sure @Log is the right name. What's a name that says log
>> all entries and exits?  @LogEntryExit?
>> 
>> Overall I would think that this kind of annotated class would change that
>> class' byte codes after compilation so that there are no runtime
>> requirements even for annotations. I certainly would not want to leave
>> behind clues like @LogHide to would be attackers
>> 
>> Thoughts?

I think that @Log is the wrong name because it’s quite vague. Maybe 
@LogMethodCalls, or as you suggest @LogEntryExit.

I like the signature you suggested @Gary.

@Matt - As for mechanics, I would think we would want to do compile time byte 
code weaving. (Is there any appetite for using aspectJ? Feels like a large ask 
to add a dependency to log4j2 though.)

>> 
>> Gary
>> 
>> 
>>> -Rob
>>> 
 
 Gary
 
 
> 
>> 
>> Gary
>> 
>> On Thu, Jul 19, 2018, 07:15 Rob Tompkins  wrote:
>> 
>>> Hey folks,
>>> 
>>> I’m curious if anyone has thought about adding a class level @Log
>>> annotation such that upon debug or trace configuration, method entry
>>> and
>>> exit gets automatically logged?
>>> 
>>> -Rob
> 
> 
>>> 
>>> 

Re: @Log annotation

[Gary Gregory]

FTR: https://projectlombok.org/features/log

On Thu, Jul 19, 2018 at 8:48 AM Gary Gregory  wrote:

>
>
> On Thu, Jul 19, 2018 at 8:26 AM Rob Tompkins  wrote:
>
>>
>>
>> > On Jul 19, 2018, at 10:17 AM, Gary Gregory 
>> wrote:
>> >
>> > On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins 
>> wrote:
>> >
>> >>
>> >>
>> >>> On Jul 19, 2018, at 9:29 AM, Gary Gregory 
>> >> wrote:
>> >>>
>> >>> Annotation-based logging comes up once in a while here but we have not
>> >>> implemented it. Project Lombok does that IIRC.
>> >>
>> >> Any reason for having not yet implemented it, or just the standard
>> “time”?
>> >>
>> >
>> > It's just more "stuff" and yes, time. And also, no one's wanted to put
>> the
>> > time in.
>> >
>> > But then there are design issues and adding more "stuff" to the API jar.
>> >
>> > - Would you allow @Log(level=Level.TRACE) (should be the default?) and
>> > @Log(level=Level.DEBUG)
>> > - What happens if you say both?
>> > - Should you be able to break it up and only say @LogEntry() or
>> @LogExit().
>> > - What about @Log(file="${user.home}\foo.log")
>> > - and on and on ;-)
>>
>> Definitely fair points, I think I would try to go as simple as possible
>> in a first pass…right?
>>
>> @Log
>> @Log(level=X)
>>
>
> Well, yes. But we need to think about the scope of the annotation. The
> name @Log is as broad as you can think of making the name. So if we want to
> put more in there later, then we need to make sure that's the best name.
>
> Do you think
>
> @Log()
>
> could be the default for (for example)
>
> @Log(level=Level.TRACE, entry=true, entryParameters=ALL, exit=true,
> exitValue=true)
>
> Where entryParameters (if on a method) would let me list which params for
> that methods to log)
>
> How do I avoid logging a password argument for example? Sounds like we can
> do away with entryParameters if we have a @LogHide to annotate a
> parameter.
>
> I could see that as step one but we need to think about all that we would
> want to do to make sure @Log is the right name. What's a name that says log
> all entries and exits?  @LogEntryExit?
>
> Overall I would think that this kind of annotated class would change that
> class' byte codes after compilation so that there are no runtime
> requirements even for annotations. I certainly would not want to leave
> behind clues like @LogHide to would be attackers
>
> Thoughts?
>
> Gary
>
>
>> -Rob
>>
>> >
>> > Gary
>> >
>> >
>> >>
>> >>>
>> >>> Gary
>> >>>
>> >>> On Thu, Jul 19, 2018, 07:15 Rob Tompkins  wrote:
>> >>>
>>  Hey folks,
>> 
>>  I’m curious if anyone has thought about adding a class level @Log
>>  annotation such that upon debug or trace configuration, method entry
>> and
>>  exit gets automatically logged?
>> 
>>  -Rob
>> >>
>> >>
>>
>>

Re: @Log annotation

[Gary Gregory]

On Thu, Jul 19, 2018 at 8:26 AM Rob Tompkins  wrote:

>
>
> > On Jul 19, 2018, at 10:17 AM, Gary Gregory 
> wrote:
> >
> > On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins  wrote:
> >
> >>
> >>
> >>> On Jul 19, 2018, at 9:29 AM, Gary Gregory 
> >> wrote:
> >>>
> >>> Annotation-based logging comes up once in a while here but we have not
> >>> implemented it. Project Lombok does that IIRC.
> >>
> >> Any reason for having not yet implemented it, or just the standard
> “time”?
> >>
> >
> > It's just more "stuff" and yes, time. And also, no one's wanted to put
> the
> > time in.
> >
> > But then there are design issues and adding more "stuff" to the API jar.
> >
> > - Would you allow @Log(level=Level.TRACE) (should be the default?) and
> > @Log(level=Level.DEBUG)
> > - What happens if you say both?
> > - Should you be able to break it up and only say @LogEntry() or
> @LogExit().
> > - What about @Log(file="${user.home}\foo.log")
> > - and on and on ;-)
>
> Definitely fair points, I think I would try to go as simple as possible in
> a first pass…right?
>
> @Log
> @Log(level=X)
>

Well, yes. But we need to think about the scope of the annotation. The name
@Log is as broad as you can think of making the name. So if we want to put
more in there later, then we need to make sure that's the best name.

Do you think

@Log()

could be the default for (for example)

@Log(level=Level.TRACE, entry=true, entryParameters=ALL, exit=true,
exitValue=true)

Where entryParameters (if on a method) would let me list which params for
that methods to log)

How do I avoid logging a password argument for example? Sounds like we can
do away with entryParameters if we have a @LogHide to annotate a parameter.

I could see that as step one but we need to think about all that we would
want to do to make sure @Log is the right name. What's a name that says log
all entries and exits?  @LogEntryExit?

Overall I would think that this kind of annotated class would change that
class' byte codes after compilation so that there are no runtime
requirements even for annotations. I certainly would not want to leave
behind clues like @LogHide to would be attackers

Thoughts?

Gary


> -Rob
>
> >
> > Gary
> >
> >
> >>
> >>>
> >>> Gary
> >>>
> >>> On Thu, Jul 19, 2018, 07:15 Rob Tompkins  wrote:
> >>>
>  Hey folks,
> 
>  I’m curious if anyone has thought about adding a class level @Log
>  annotation such that upon debug or trace configuration, method entry
> and
>  exit gets automatically logged?
> 
>  -Rob
> >>
> >>
>
>

Re: @Log annotation

[Rob Tompkins]

> On Jul 19, 2018, at 10:17 AM, Gary Gregory  wrote:
> 
> On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins  wrote:
> 
>> 
>> 
>>> On Jul 19, 2018, at 9:29 AM, Gary Gregory 
>> wrote:
>>> 
>>> Annotation-based logging comes up once in a while here but we have not
>>> implemented it. Project Lombok does that IIRC.
>> 
>> Any reason for having not yet implemented it, or just the standard “time”?
>> 
> 
> It's just more "stuff" and yes, time. And also, no one's wanted to put the
> time in.
> 
> But then there are design issues and adding more "stuff" to the API jar.
> 
> - Would you allow @Log(level=Level.TRACE) (should be the default?) and
> @Log(level=Level.DEBUG)
> - What happens if you say both?
> - Should you be able to break it up and only say @LogEntry() or @LogExit().
> - What about @Log(file="${user.home}\foo.log")
> - and on and on ;-)

Definitely fair points, I think I would try to go as simple as possible in a 
first pass…right?

@Log
@Log(level=X)

-Rob

> 
> Gary
> 
> 
>> 
>>> 
>>> Gary
>>> 
>>> On Thu, Jul 19, 2018, 07:15 Rob Tompkins  wrote:
>>> 
 Hey folks,
 
 I’m curious if anyone has thought about adding a class level @Log
 annotation such that upon debug or trace configuration, method entry and
 exit gets automatically logged?
 
 -Rob
>> 
>> 

Re: @Log annotation

[Gary Gregory]

On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins  wrote:

>
>
> > On Jul 19, 2018, at 9:29 AM, Gary Gregory 
> wrote:
> >
> > Annotation-based logging comes up once in a while here but we have not
> > implemented it. Project Lombok does that IIRC.
>
> Any reason for having not yet implemented it, or just the standard “time”?
>

It's just more "stuff" and yes, time. And also, no one's wanted to put the
time in.

But then there are design issues and adding more "stuff" to the API jar.

- Would you allow @Log(level=Level.TRACE) (should be the default?) and
@Log(level=Level.DEBUG)
- What happens if you say both?
- Should you be able to break it up and only say @LogEntry() or @LogExit().
- What about @Log(file="${user.home}\foo.log")
- and on and on ;-)

Gary


>
> >
> > Gary
> >
> > On Thu, Jul 19, 2018, 07:15 Rob Tompkins  wrote:
> >
> >> Hey folks,
> >>
> >> I’m curious if anyone has thought about adding a class level @Log
> >> annotation such that upon debug or trace configuration, method entry and
> >> exit gets automatically logged?
> >>
> >> -Rob
>
>

Re: @Log annotation

[Rob Tompkins]

> On Jul 19, 2018, at 9:29 AM, Gary Gregory  wrote:
> 
> Annotation-based logging comes up once in a while here but we have not
> implemented it. Project Lombok does that IIRC.

Any reason for having not yet implemented it, or just the standard “time”?

> 
> Gary
> 
> On Thu, Jul 19, 2018, 07:15 Rob Tompkins  wrote:
> 
>> Hey folks,
>> 
>> I’m curious if anyone has thought about adding a class level @Log
>> annotation such that upon debug or trace configuration, method entry and
>> exit gets automatically logged?
>> 
>> -Rob

Re: @Log annotation

[Gary Gregory]

Annotation-based logging comes up once in a while here but we have not
implemented it. Project Lombok does that IIRC.

Gary

On Thu, Jul 19, 2018, 07:15 Rob Tompkins  wrote:

> Hey folks,
>
> I’m curious if anyone has thought about adding a class level @Log
> annotation such that upon debug or trace configuration, method entry and
> exit gets automatically logged?
>
> -Rob