Awesome, thanks for the clarification. Gary
On Sat, Sep 27, 2014 at 9:25 AM, Remko Popma <[email protected]> wrote: > AFAIKS, there is nothing outstanding here. > > The way it works is, > 1. built-in levels are fully mapped. The mapping is pluggable, so users > can switch to a different mapping if desired. > 2. custom JUL levels are supported, but users should provide their own > LevelConverter in that case. We currently do not attempt to automatically > map custom JUL levels to Log4j levels. > > All of this is fully documented in the JUL Adapter component docs. > > > On Sat, Sep 27, 2014 at 9:43 PM, Gary Gregory <[email protected]> > wrote: > >> Ping. >> >> Gary >> >> On Thu, Sep 11, 2014 at 8:29 AM, Gary Gregory <[email protected]> >> wrote: >> >>> Where are we on this? >>> >>> Gary >>> >>> On Wed, Sep 10, 2014 at 1:48 AM, Remko Popma <[email protected]> >>> wrote: >>> >>>> Without actually experimenting, I was thinking it might be difficult to >>>> make the full auto solution robust in all scenarios, so having an interface >>>> where users can completely determine their own mapping (option #2) is >>>> probably very nice to have. >>>> >>>> Option #3 may be ideal (but the level mapper still needs to deal with >>>> the exceptional case where the code uses a custom level that is not defined >>>> in the config.) >>>> >>>> >>>> On Wednesday, September 10, 2014, Matt Sicker <[email protected]> wrote: >>>> >>>>> So far, I've implemented choice #2 to some extent. >>>>> >>>>> On 9 September 2014 23:47, Ralph Goers <[email protected]> >>>>> wrote: >>>>> >>>>>> If I was implementing this I would take a custom JUL level and map it >>>>>> to the appropriate predefined JUL level. That would then map to a Log4j >>>>>> level. >>>>>> >>>>>> Ralph >>>>>> >>>>>> On Sep 9, 2014, at 9:19 PM, Remko Popma <[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Wednesday, September 10, 2014, Matt Sicker <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> There's actually a bit of an interesting challenge in converting >>>>>>> from a custom level in JUL to Log4j. JUL allows you to use any integer >>>>>>> value possible (not just non-negative ones). Also, their progression of >>>>>>> level values goes in reverse of ours. Thus, any level above 1000 >>>>>>> (Level.SEVERE in JUL) would need to be squeezed into the range of 1 to >>>>>>> 99! >>>>>>> Plus, Integer.MAX_VALUE indicates StandardLevel.ALL, but Level.OFF in >>>>>>> JUL. >>>>>>> Then there'd be the other way around, too. >>>>>>> >>>>>>> Darn! That makes things tricky indeed... >>>>>> Just throwing out some thoughts: >>>>>> >>>>>> 1. Full auto: We could have some mapping logic that converts the >>>>>> custom JUL int level to a log4j int that is between the mapped built-in >>>>>> levels. (TBD: how to avoid collisions if multiple custom levels are >>>>>> defined >>>>>> between built-in levels?) >>>>>> >>>>>> 2. Semi-auto: we define an interface that converts JUL levels to >>>>>> Log4j levels. We provide a default impl for the built-in levels. Users >>>>>> need >>>>>> to provide their own impl (or extend ours?) if they have custom JUL >>>>>> levels. >>>>>> (TBD: how does our default impl handle undefined custom JUL levels?) >>>>>> >>>>>> 3. Config only: this depends on >>>>>> https://issues.apache.org/jira/browse/LOG4J2-589 >>>>>> Custom log4j levels are defined in configuration. The log4j config >>>>>> file is loaded first, so the JUL bridge can convert custom levels using >>>>>> the >>>>>> name only. It can completely ignore the JUL int level. >>>>>> >>>>>> 4. Easiest: we (initially) don't support custom JUL levels. Unknown >>>>>> levels are converted to some ad hoc log4j level. Let's say, INFO, but we >>>>>> can decide to use any level. >>>>>> >>>>>> >>>>>> >>>>>>> As to those fields, I think we can probably drop them. LogRecord >>>>>>> dynamically calculates them from the Throwable stacktrace if necessary. >>>>>>> We >>>>>>> do it faster. >>>>>>> >>>>>> >>>>>> Phew! >>>>>> >>>>>>> >>>>>>> On 9 September 2014 22:07, Matt Sicker <[email protected]> wrote: >>>>>>> >>>>>>>> What about the logp, entering, exiting, and throwing methods which >>>>>>>> all take a source class name and a source method name? Just ignore >>>>>>>> them? >>>>>>>> >>>>>>>> On 9 September 2014 21:40, Remko Popma <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> My take would be to drop the seqNo and threadID integer, and for >>>>>>>>> level, check if its a built-in JUL level which can be translated to a >>>>>>>>> built-in log4j level. If it's not a built-in JUL level we can do a >>>>>>>>> log4j >>>>>>>>> Level.forName() call to create that custom level in log4j as well. >>>>>>>>> Thoughts? >>>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>> On 2014/09/10, at 11:07, Matt Sicker <[email protected]> wrote: >>>>>>>>> >>>>>>>>> I'm actually thinking of some sort of LogRecordMessage or similar >>>>>>>>> which takes a useful subset of LogRecord. >>>>>>>>> >>>>>>>>> On 9 September 2014 21:01, Matt Sicker <[email protected]> wrote: >>>>>>>>> >>>>>>>>>> I've got ranges in place to map to standard levels, but custom >>>>>>>>>> level support is currently done through the MDC. Should I use a >>>>>>>>>> MapMessage >>>>>>>>>> instead? Make a new Message type just for log4j-jul? There's >>>>>>>>>> metadata in >>>>>>>>>> some of these Logger methods that I'd like to include, but if the >>>>>>>>>> MDC isn't >>>>>>>>>> the best way to do that, then I'd prefer another way. I noticed that >>>>>>>>>> pax-logging does this for every log event to include some metadata >>>>>>>>>> about >>>>>>>>>> the OSGi bundle that made the log call, so I kept up the style. >>>>>>>>>> >>>>>>>>>> As to the static field, yes, I noticed that, too. It's only for a >>>>>>>>>> sequence number, and we have our own (better) way of doing that with >>>>>>>>>> on-demand sequencing (and using the AtomicXxx classes indeed) >>>>>>>>>> anyways. >>>>>>>>>> >>>>>>>>>> On 9 September 2014 20:39, Remko Popma <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Fro a performance point of view, it would be great if we could >>>>>>>>>>> avoid creating LogRecord instances. Not just from a GC perspective, >>>>>>>>>>> but in >>>>>>>>>>> java6 the LogRecord constructor synchronizes on a static >>>>>>>>>>> variable(!): big >>>>>>>>>>> bottleneck. This is improved (using AtomicXxx) in java7. >>>>>>>>>>> >>>>>>>>>>> Also would great if we can avoid using the ThreadContext MDC for >>>>>>>>>>> every log event. (Its copy-on-write design is not a good match for >>>>>>>>>>> this >>>>>>>>>>> usage...) >>>>>>>>>>> >>>>>>>>>>> Would there be a way to map custom JUL log levels to custom >>>>>>>>>>> Log4j levels? >>>>>>>>>>> >>>>>>>>>>> Sent from my iPhone >>>>>>>>>>> >>>>>>>>>>> On 2014/09/10, at 10:20, Matt Sicker <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> Actually, now that I look at it, I can just use an inner class >>>>>>>>>>> with ExtendedLoggerWrapper to get at those protected methods I >>>>>>>>>>> mentioned. I >>>>>>>>>>> mean, that appears to be the point of it! Let me see if it does >>>>>>>>>>> everything >>>>>>>>>>> I needed. >>>>>>>>>>> >>>>>>>>>>> On 9 September 2014 20:08, Matt Sicker <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Now that I'm looking at this, what's the point of all the >>>>>>>>>>>> methods that take a FQCN instead of having just the ones in >>>>>>>>>>>> ExtendedLogger? >>>>>>>>>>>> I'm not sure why we didn't just use a field in AbstractLogger in >>>>>>>>>>>> the first >>>>>>>>>>>> place. >>>>>>>>>>>> >>>>>>>>>>>> On 9 September 2014 19:14, Matt Sicker <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I'm making some changes to log4j-jul to reduce redundant time >>>>>>>>>>>>> spent constructing a LogRecord that I don't even want to use most >>>>>>>>>>>>> of the >>>>>>>>>>>>> time. However, the ExtendedLogger interface (which I need to use >>>>>>>>>>>>> at the >>>>>>>>>>>>> very least so that I can set the fqcn to >>>>>>>>>>>>> java.util.logging.Logger) only >>>>>>>>>>>>> provides a single version of logMessage (unlike AbstractLogger >>>>>>>>>>>>> which has a >>>>>>>>>>>>> bunch), and several methods like catching(), throwing(), etc., >>>>>>>>>>>>> all depend >>>>>>>>>>>>> on protected methods in AbstractLogger that I'd rather not >>>>>>>>>>>>> re-implement. It >>>>>>>>>>>>> would be nice if I could just call the Logger methods I need, but >>>>>>>>>>>>> they all >>>>>>>>>>>>> get called with the wrong fqcn. >>>>>>>>>>>>> >>>>>>>>>>>>> Can we use a non-static final field that contains the fqcn? If >>>>>>>>>>>>> I could, I'd extend AbstractLogger myself, but I already have to >>>>>>>>>>>>> extend the >>>>>>>>>>>>> JUL Logger class (should have been an interface, grrr). Thus, I >>>>>>>>>>>>> can't rely >>>>>>>>>>>>> on AbstractLogger being the source of all these method calls. >>>>>>>>>>>>> Unlike the >>>>>>>>>>>>> other adapters, JUL provides more various logger calls than we >>>>>>>>>>>>> even have, >>>>>>>>>>>>> and I don't think ExtendedLogger was written with this scenario >>>>>>>>>>>>> in mind. >>>>>>>>>>>>> >>>>>>>>>>>>> I don't think this should be too large an impact of a change. >>>>>>>>>>>>> I'm going to push up a proposal, but feel free to veto it or >>>>>>>>>>>>> offer some >>>>>>>>>>>>> suggestions! >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Matt Sicker <[email protected]> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Matt Sicker <[email protected]> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Matt Sicker <[email protected]> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Matt Sicker <[email protected]> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Matt Sicker <[email protected]> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Matt Sicker <[email protected]> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matt Sicker <[email protected]> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Matt Sicker <[email protected]> >>>>> >>>> >>> >>> >>> -- >>> E-Mail: [email protected] | [email protected] >>> Java Persistence with Hibernate, Second Edition >>> <http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >> >> >> >> -- >> E-Mail: [email protected] | [email protected] >> Java Persistence with Hibernate, Second Edition >> <http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> > > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
