Looks okay. If it simplifies the logging then it would be good. The jars look small enough to include without any problems in a mobile app.<div><br></div><div>Martin<br><br><div class="gmail_quote">On 6 February 2013 13:46, Chris Burrell <span dir="ltr"><<a href="mailto:chris@burrell.me.uk" target="_blank">chris@burrell.me.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Martin / DM<div><br></div><div>What about looking at replacing the JSword logging framework with SLF4j. For android, all you'd do is include the Android bindings: <a href="http://www.slf4j.org/android/" target="_blank">http://www.slf4j.org/android/</a></div>
<div><br></div><div>The benefits with slf4j is that you can provide it with placeholders e.g. log.debug("hi {}. My name is {}", a, b, exception); In that way, non of the string concatenation happens until before. </div>
<div><br></div><div>See the summary at the bottom of the page here: <a href="http://www.slf4j.org/manual.html" target="_blank">http://www.slf4j.org/manual.html</a></div><div><br></div><div>Any thoughts?</div><div>
<br></div><div>Not a huge issue for me (yet - as I don't have lots of desktop users). I was just wondering and I guessed some of it was historical!</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>
Chris</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5">
<div class="gmail_extra"><br><br><div class="gmail_quote">On 6 February 2013 13:37, Martin Denham <span dir="ltr"><<a href="mailto:mjdenham@gmail.com" target="_blank">mjdenham@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I failed to get the JSword logging to work on Android, which doesn't mean it won't work but I gave up. It would be nice to be able to swap out the current logging implementation. If we could swap it out I would use something based around android.util.Log which I use everywhere else in And Bible. Is it possible to do that?<div>
<br></div><div>It would be nice if there was a Logger interface which had a DefaultLoggerImpl as now or maybe Log4jLoggerImpl and I would implement an AndroidLoggerImpl. we would also need a way to specify the impl to be used- maybe just Logger.setLoggerImpl or using config files as JSword uses elsewhere.</div>
<div><br></div><div>Regards</div><div>Martin<br><br><div class="gmail_quote"><div><div>On 6 February 2013 13:20, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div style="word-wrap:break-word">My answers were a bit short. Here's a bit of history. (As best I can remember ;)<div>
<br><div>When creating an application from scratch, it is wise to start with some frameworks: logging, internationalization, memory management, ...</div><div><br></div><div>When I started w/ JSword 8.5 years ago, these already in place. (Thanks Joe!)</div>
<div><br></div><div>At that time we were using Java 1.3.</div><div><br></div><div>Loggers at that time were being strongly debated as who's was the best, and log4j was used for JSword. Java did not have a logger. But wrapped by our logger class.</div>
<div><br></div><div>IIRC: At that time there was no support in any logging package for stack tracing, which is critical for debugging. </div><div><br></div><div>One of the problems with generating a stack trace is that we want it to show where the problem occurred (class, method and line where the logger was called), not one starting inside of the logger in some distant package. So, we put a static logger object in each class that did logging. The logger was then part of that class and would properly show that class as the originator for the log message. To get the method and the line number of where the logger was called required a stack trace to dig through.</div>
<div><br></div><div>We then figured out how to get the calling class by digging into the call stack. (See CallContext).</div><div><br></div><div>Then we changed from log4j to Java logging. The names we had for our logger needed to map to the logging levels in Java. We kept our old names and documented the mapping.</div>
<div><br></div><div>Regarding Java Logging, I don't know the full capabilities. Here is what we need for good logging:</div><div>1) Class where the logging took place. Always.</div><div>2) Method and line of where the event took place. The place where the logger is called might be the closest place that we can get. This is needed for debugging errors. It is probably not needed for fine levels of detail.</div>
<div>3) Stack trace. Needed for understanding errors. It is not sufficient to know the class, method and line, but need the context of the event.</div><div><br></div><div>So we probably have baggage from the past and Java Logging probably has caught up. So, if there are better ways to get method and line, that'd be great. It might make sense to use the provided throwable (when not null).</div>
<div><br></div><div>Enough for now.</div><div><br></div><div>In Him,</div><div><span style="white-space:pre-wrap"> </span>DM</div><div><div><div><br><div><div>On Feb 6, 2013, at 6:39 AM, Chris Burrell <<a href="mailto:chris@burrell.me.uk" target="_blank">chris@burrell.me.uk</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">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)</div><div class="gmail_extra">
<br><br><div class="gmail_quote">
On 6 February 2013 11:24, Chris Burrell <span dir="ltr"><<a href="mailto:chris@burrell.me.uk" target="_blank">chris@burrell.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I guess my more general question is why "<span style="font-family:arial,sans-serif;font-size:13px">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."</span><br>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">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 </span><span style="font-family:arial,sans-serif;font-size:13px">output anyway, so I can configure a java.util.logging.Logger via a "log4j.properties" file using the bindings provided by slf4j.</span></div>
<div><br></div><div>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.</div>
<div><br></div><div>Anyhow, just a thought. </div><span><font color="#888888"><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">Chris</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On 6 February 2013 09:37, Chris Burrell <span dir="ltr"><<a href="mailto:chris@burrell.me.uk" target="_blank">chris@burrell.me.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<span><font color="#888888"><div>
<br></div><div>Chris</div><div><br></div></font></span></div><div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On 5 February 2013 23:38, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Logger.doLogging needs to change to test the level against set level and bail if it is not going to be recorded.<div><br></div><div>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.</div>
<div><br></div><div>Will that help?</div><span><font color="#888888"><div><br></div><div>-- DM</div></font></span><div><br><div><div>On Feb 5, 2013, at 6:22 PM, Chris Burrell <<a href="mailto:chris@burrell.me.uk" target="_blank">chris@burrell.me.uk</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">The 10% logging was debug logging, perhaps that was exacerbated during profiling, but i'd expect it to be exacerbated uniformly-sh.<div><br></div><div>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.</div>
<div><br></div><div>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)</div>
<div><br></div><div>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.</div>
<div><br></div><div>Cheers</div><div>Chris</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 5 February 2013 23:04, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
On Feb 5, 2013, at 3:37 PM, Chris Burrell <<a href="mailto:chris@burrell.me.uk" target="_blank">chris@burrell.me.uk</a>> wrote:<br>
<br>
> Hi<br>
><br>
> 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.<br>
<br>
</div>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.<br>
<br>
There's a bug in changing the LogLevel and in specifying the logger config. But I don't remember.<br>
<div><br>
><br>
> I'm guessing that's because of the bit that tries to throw an Exception to capture the stack trace.<br>
<br>
</div>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.<br>
<br>
See the "showLocation" part of the getLogger() call.<br>
<div><br>
><br>
> Is there any reason why we're not using the java loggers directly?<br>
<br>
</div>We are using the java loggers. We don't use it directly since we were using a different logger before the java loggers.<br>
<div><br>
> Or why we're not using log4j (i see there's a not about keeping it small)<br>
<br>
</div>That's what we were using.<br>
<br>
The philosophy of JSword architecture is to:<br>
define an abstract interface<br>
create a basic implementation of the abstraction<br>
use a plugin to define which implementation is being used. (Not used wrt logging)<br>
<br>
By hiding behind the concrete abstraction, we were able to swap out implementations.<br>
<br>
Hope this helps,<br>
DM<br>
<br>
<br>
</blockquote></div><br></div>
</blockquote></div><br></div></div></blockquote></div><br></div>
</div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></div><br></div></div>_______________________________________________<br>
jsword-devel mailing list<br>
<a href="mailto:jsword-devel@crosswire.org" target="_blank">jsword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/jsword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/jsword-devel</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
jsword-devel mailing list<br>
<a href="mailto:jsword-devel@crosswire.org" target="_blank">jsword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/jsword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/jsword-devel</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
jsword-devel mailing list<br>
<a href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/jsword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/jsword-devel</a><br>
<br></blockquote></div><br></div>