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 <ralph.go...@dslextreme.com> 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 <garydgreg...@gmail.com> 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 <chtom...@gmail.com> 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 <garydgreg...@gmail.com> >>> wrote: >>>>> >>>>> eOn Thu, Jul 19, 2018 at 10:19 AM Rob Tompkins <chtom...@gmail.com >>> <mailto:chtom...@gmail.com>> 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, >>>>>>>> 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 <chtom...@gmail.com >>> <mailto:chtom...@gmail.com>> >>>>>> 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 >>>> >>> >>> > >
