It has been brought up before. You can read about the JSR process at http://jcp.org <http://jcp.org/>.
Ralph > On Jul 19, 2018, at 11:19 AM, Rob Tompkins <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>> >>>> >>>> >>>>> On Jul 19, 2018, at 1:41 PM, Ralph Goers <[email protected]> >>>> 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 <[email protected]> >>>> wrote: >>>>>> >>>>>> eOn Thu, Jul 19, 2018 at 10:19 AM Rob Tompkins <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jul 19, 2018, at 11:48 AM, Gary Gregory <[email protected]> >>>>>>> wrote: >>>>>>>> >>>>>>>> FTR: https://projectlombok.org/features/log >>>>>>>> >>>>>>>> On Thu, Jul 19, 2018 at 8:48 AM Gary Gregory <[email protected]> >>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jul 19, 2018 at 8:26 AM Rob Tompkins <[email protected]> >>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Jul 19, 2018, at 10:17 AM, Gary Gregory <[email protected] >>>>> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Jul 19, 2018, at 9:29 AM, Gary Gregory < >>>> [email protected]> >>>>>>>>>>>> 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 <[email protected] >>>> <mailto:[email protected]>> >>>>>>> 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 >>>>> >>>> >>>> >> >> > >
