[jsword-devel] Loggers

[Chris Burrell]

And on the above, is it not just a matter of configuring the Java Logger to
output the stack trace? when logging? (forgive my ignore on the java
loggers)


On 6 February 2013 11:24, Chris Burrell <chris at burrell.me.uk> wrote:

> I guess my more general question is why "We want that when we are
> handling errors. Maybe we don't want to do it for all levels of logging.
> I.e. configure it."
>
> Doesn't the Java Logger do that? Given we're wrapping around
> java.util.loggin.Logger anyway, why not just use those directly. The only
> reason I can find is that someone preferred the log4j api to the
> java.util.logging api. With Slf4j a developer of a third-party application
> can change the way these logs are output anyway, so I can configure a
> java.util.logging.Logger via a "log4j.properties" file using the bindings
> provided by slf4j.
>
> When I've tried configuring the Loggers occasionally for JSword I have to
> say I've found it pretty difficult to work out, for 2 main reasons.
> Everything looks like it's using log4j, but the .properties file uses the
> java.util.logging.Logger style. My problem was then two-fold: i haven't
> used that much, and without digging into the implementation, it's difficult
> to know how the log levels match up to the log4j log levels.
>
> Anyhow, just a thought.
>
> Chris
>
>
>
> On 6 February 2013 09:37, Chris Burrell <chris at burrell.me.uk> wrote:
>
>> Yeah, i think that will help. I can do the first one. I'm not promising I
>> go through the whole code base to do the others.
>>
>> Chris
>>
>>
>>
>> On 5 February 2013 23:38, DM Smith <dmsmith at crosswire.org> wrote:
>>
>>> Logger.doLogging needs to change to test the level against set level and
>>> bail if it is not going to be recorded.
>>>
>>> There will still be some building of messages outside. We can add a
>>> boolean shouldLog(logLevel) to help one determine on whether to construct a
>>> log message.
>>>
>>> Will that help?
>>>
>>> -- DM
>>>
>>> On Feb 5, 2013, at 6:22 PM, Chris Burrell <chris at burrell.me.uk> wrote:
>>>
>>> The 10% logging was debug logging, perhaps that was exacerbated during
>>> profiling, but i'd expect it to be exacerbated uniformly-sh.
>>>
>>> The JSword logger doesn't define a isDebugEnabled as far as I can see.
>>> Also, showLocation is true by default, so lots of work happens every time.
>>> The logger implementation seems to rely on the underlying functionality as
>>> to whether it is logged out to a screen/stream/file/etc. but by then all
>>> the work has been done.
>>>
>>> Due to the missing isDebugEnable type functions, JSword methods across
>>> the board presumably do quite a lot of concatenation before even calling
>>> the logger, i.e. passing a concatenation of parameters. (not sure whether
>>> the profiler would wrap that into the log call, or the caller method,
>>> probably the caller)
>>>
>>> Unfortunately, the third party is not in charge of showLocation. And
>>> can't change it as the moment except on a per logger basis. Perhaps it was
>>> the particular operation. It's partly because of String concatenations.
>>>
>>> Cheers
>>> Chris
>>>
>>>
>>>
>>> On 5 February 2013 23:04, DM Smith <dmsmith at crosswire.org> wrote:
>>>
>>>>
>>>> On Feb 5, 2013, at 3:37 PM, Chris Burrell <chris at burrell.me.uk> wrote:
>>>>
>>>> > Hi
>>>> >
>>>> > I was doing a bit of performance tuning for STEP earlier, to see how
>>>> I could speed up some of the searches. I found that possibly up to 10% of
>>>> the time could be spent logging.
>>>>
>>>> Seem strange that 10 percent of the time is managing errors. (You need
>>>> to look into configuring the logger to only log errors, if you aren't
>>>> already). Then the calls to logger are lightweight. Pretty much a no-op.
>>>>
>>>> There's a bug in changing the LogLevel and in specifying the logger
>>>> config. But I don't remember.
>>>>
>>>> >
>>>> > I'm guessing that's because of the bit that tries to throw an
>>>> Exception to capture the stack trace.
>>>>
>>>> We want that when we are handling errors. Maybe we don't want to do it
>>>> for all levels of logging. I.e. configure it.
>>>>
>>>> See the "showLocation" part of the getLogger() call.
>>>>
>>>> >
>>>> > Is there any reason why we're not using the java loggers directly?
>>>>
>>>> We are using the java loggers. We don't use it directly since we were
>>>> using a different logger before the java loggers.
>>>>
>>>> > Or why we're not using log4j (i see there's a not about keeping it
>>>> small)
>>>>
>>>> That's what we were using.
>>>>
>>>> The philosophy of JSword architecture is to:
>>>> define an abstract interface
>>>> create a basic implementation of the abstraction
>>>> use a plugin to define which implementation is being used. (Not used
>>>> wrt logging)
>>>>
>>>> By hiding behind the concrete abstraction, we were able to swap out
>>>> implementations.
>>>>
>>>> Hope this helps,
>>>>         DM
>>>>
>>>>
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20130206/45fac3bb/attachment-0001.html>