Moving to log4j, java.util.logging, Apache Commons Logging, etc?
Sunday, 1 April 2012 · 16 messages · last reply 5 Apr 2012
CG
Hi Charles,
Quoted text · Charles Duffy · 5 lines
> Is the decision to use an in-house logging framework open to > reconsideration? I'd be willing to do a first-draft cut on a transition to > log4j, Sun's java.util.logging, or Apache Commons Logging (a thin > indirection layer which can use either of those as an underlying backend) if > there's agreement to do so.
Thanks for your offer. While our current log architecture seems to have covered most requirements (regarding the feedback we've got on it), I have no doubt it can be further improved, so your draft is welcome. Intuitively, I'd first stick with Java's default logging mechanism, as the BaseX core is supposed to work without any additional libraries (but of course we could switch over to other logging libraries if they are found in the classpath).
Christian
DP
Dimitar Popov1 Apr 2012 23:35 #
Quoted text · 23:26:43 · 16 lines
Am Sonntag, 1. April 2012, 23:26:43 schrieb Christian Grün: > Hi Charles, > > > Is the decision to use an in-house logging framework open to > > reconsideration? I'd be willing to do a first-draft cut on a transition to > > log4j, Sun's java.util.logging, or Apache Commons Logging (a thin > > indirection layer which can use either of those as an underlying backend) if > > there's agreement to do so. > > Thanks for your offer. While our current log architecture seems to > have covered most requirements (regarding the feedback we've got on > it), I have no doubt it can be further improved, so your draft is > welcome. Intuitively, I'd first stick with Java's default logging > mechanism, as the BaseX core is supposed to work without any > additional libraries (but of course we could switch over to other > logging libraries if they are found in the classpath).
Just a short note from my side: I'd also propose SLF4J (at least for BaseX HTTP / Web App), since we already depend on it, because of Milton WebDAV.
Regards,
Dimitar
CG
Quoted text · Charles Duffy · 2 lines
> Could you quickly run through the requirements for a logging system in > BaseX, to be sure we're on the same page?
Just a short one... It might be a good start to check out the existing debug mode, which is very cheap, too, and rewrite it in a way such that this output is redirected to the logging library. For more details, it might be worth talking to Dimitar, as he had some similar thoughts just a few time ago (for now, I'd still prefer to stick with the standard Java libraries -- even if the external library has just a few kb -- and dynamically plug in a more advanced solution,
automatically or via reflection).
Christian
Quoted text · Charles Duffy · 34 lines
> [High priority] > - Ability to add cheap trace-level logging at any point in the code (not > only places which have been passed a handle to the single logger instance); > "cheap" in this case meaning having no significant performance impact when > active log level is below this point. > - Ability to toggle detailed logging for very specific components (ie. only > for org.basex.query.func.JavaModuleFunc) via configuration changes only. > > [Medium priority] > - Ability to enable stack traces for log messages which may not include them > by default as a configuration-only (no-code-change) capability. > > [Low priority] > - Ability to use appenders for remote logging, auto-rotated logging, or > similar advanced functionality, where using such appenders is necessary to > be compliant with local standards (I'm in a Java shop, so we have a typical > set of log4j appenders used). > > > The principal reason I'd consider Apache Commons Logging is that it > automates the process of switching to alternate logging libraries, rather > than needing to write the indirection layer ourselves; a 3rd party embedding > a library will typically prefer that it support their choice of native > logging libraries -- and as log4j is far more widely used than > java.util.logging (which is both newer and less capable), supporting it is > often expected. That said -- it *does* add a 3rd-party 60K jar to the > necessary set of libraries (more if one wants to use it to target something > other than log4j or java.util.logging). > > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
CD
Charles Duffy2 Apr 2012 01:17 #
Howdy --
Right now, logging in BaseX is managed through org.basex.server.Log, allocated within each BaseXServer instance and passed to classes such as ClientListener with a known need to do logging.
Compared to common logging approaches, this is somewhat unfortunate -- any class not passed a reference to the Log instance is unable to perform logging, and functionality common to log4j-derived logging frameworks (such as fine-grained log level and destination control) is unavailable.
Is the decision to use an in-house logging framework open to reconsideration? I'd be willing to do a first-draft cut on a transition to log4j, Sun's java.util.logging, or Apache Commons Logging (a thin indirection layer which can use either of those as an underlying backend) if there's agreement to do so.
CD
Quoted text · Christian Grün · 16 lines
On 04/01/2012 04:26 PM, Christian Grün wrote: > Hi Charles, > >> Is the decision to use an in-house logging framework open to >> reconsideration? I'd be willing to do a first-draft cut on a transition to >> log4j, Sun's java.util.logging, or Apache Commons Logging (a thin >> indirection layer which can use either of those as an underlying backend) if >> there's agreement to do so. > > Thanks for your offer. While our current log architecture seems to > have covered most requirements (regarding the feedback we've got on > it), I have no doubt it can be further improved, so your draft is > welcome. Intuitively, I'd first stick with Java's default logging > mechanism, as the BaseX core is supposed to work without any > additional libraries (but of course we could switch over to other > logging libraries if they are found in the classpath).
Howdy, Christian --
Could you quickly run through the requirements for a logging system in BaseX, to be sure we're on the same page?
The things I personally want which I don't understand to be presently available:
[High priority]
- Ability to add cheap trace-level logging at any point in the code (not only places which have been passed a handle to the single logger instance); "cheap" in this case meaning having no significant performance impact when active log level is below this point.
- Ability to toggle detailed logging for very specific components (ie. only for org.basex.query.func.JavaModuleFunc) via configuration changes only.
[Medium priority]
- Ability to enable stack traces for log messages which may not include them by default as a configuration-only (no-code-change) capability.
[Low priority]
- Ability to use appenders for remote logging, auto-rotated logging, or similar advanced functionality, where using such appenders is necessary to be compliant with local standards (I'm in a Java shop, so we have a typical set of log4j appenders used).
The principal reason I'd consider Apache Commons Logging is that it automates the process of switching to alternate logging libraries, rather than needing to write the indirection layer ourselves; a 3rd party embedding a library will typically prefer that it support their choice of native logging libraries -- and as log4j is far more widely used than java.util.logging (which is both newer and less capable), supporting it is often expected. That said -- it *does* add a 3rd-party 60K jar to the necessary set of libraries (more if one wants to use it to target something other than log4j or java.util.logging).
CD
Quoted text · Dimitar Popov · 3 lines
On 04/01/2012 04:35 PM, Dimitar Popov wrote: > Just a short note from my side: I'd also propose SLF4J (at least for BaseX > HTTP / Web App), since we already depend on it, because of Milton WebDAV.
Looks good to me -- I wasn't previously familiar with SLF4J, but on brief review, this looks at least as suitable as commons-logging for acting as a switch between log4j and java.util.logging.
CD
Quoted text · Christian Grün · 12 lines
On 04/01/2012 05:24 PM, Christian Grün wrote: >> Could you quickly run through the requirements for a logging system in >> BaseX, to be sure we're on the same page? > > Just a short one... It might be a good start to check out the existing > debug mode, which is very cheap, too, and rewrite it in a way such > that this output is redirected to the logging library. For more > details, it might be worth talking to Dimitar, as he had some similar > thoughts just a few time ago (for now, I'd still prefer to stick with > the standard Java libraries -- even if the external library has just a > few kb -- and dynamically plug in a more advanced solution, > automatically or via reflection).
Work started on that, present in my github tree
(https://github.com/charles-dyfis-net/basex/commits/java_util_logging).
This is the first time I've used java.util.logging, and I have a few gripes about it (most particularly, the need to construct new Object[] arrays to store format string parameters means that calls that aren't logged are not nearly as cheap as they might otherwise be, leading to the need for a lot of logger.isLoggable() calls wrapping blocks with log messages if we want to code for optimal performance... *sigh*).
That said, I'll get this to a point where it has functional parity with old behavior (respecting
DEBUG, the -z flag, etc) and let folks know when it's ready for testing or early review. Note that I'm by no means a "Java developer", so I expect no small amount of feedback on anything this large. :)
FYI -- I rather strongly disagree with building our own indirection layer to dynamically switch between logging libraries, when at least two such layers already exist on the market (and one of them is already found in our dependency chain); writing an indirection layer that switches between indirection layers is considered an antipattern for reasons I consider to be pretty good ones, which the slf4j folks document in their FAQ[1]... but we can have that discussion later; supporting java.util.logging is a reasonable first step before we consider others.
[1] http://www.slf4j.org/faq.html#optional_dependencyQuoted text · Christian Grün · 37 lines
> Christian > ______________________________ > >> [High priority] >> - Ability to add cheap trace-level logging at any point in the code (not >> only places which have been passed a handle to the single logger instance); >> "cheap" in this case meaning having no significant performance impact when >> active log level is below this point. >> - Ability to toggle detailed logging for very specific components (ie. only >> for org.basex.query.func.JavaModuleFunc) via configuration changes only. >> >> [Medium priority] >> - Ability to enable stack traces for log messages which may not include them >> by default as a configuration-only (no-code-change) capability. >> >> [Low priority] >> - Ability to use appenders for remote logging, auto-rotated logging, or >> similar advanced functionality, where using such appenders is necessary to >> be compliant with local standards (I'm in a Java shop, so we have a typical >> set of log4j appenders used). >> >> >> The principal reason I'd consider Apache Commons Logging is that it >> automates the process of switching to alternate logging libraries, rather >> than needing to write the indirection layer ourselves; a 3rd party embedding >> a library will typically prefer that it support their choice of native >> logging libraries -- and as log4j is far more widely used than >> java.util.logging (which is both newer and less capable), supporting it is >> often expected. That said -- it *does* add a 3rd-party 60K jar to the >> necessary set of libraries (more if one wants to use it to target something >> other than log4j or java.util.logging). >> >> >> _______________________________________________ >> BaseX-Talk mailing list >> BaseX-Talk at mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
CG
Christian Grün2 Apr 2012 15:07 #
Quoted text · Charles Duffy · 2 lines
> Work started on that, present in my github tree > (https://github.com/charles-dyfis-net/basex/commits/java_util_logging).
Good news, I'll look at that soon.
Quoted text · Charles Duffy · 3 lines
> FYI -- I rather strongly disagree with building our own indirection layer to > dynamically switch between logging libraries, when at least two such layers > already exist on the market [...]
True. All this is related to a more general question: do we want to allow dependencies to other libraries in the BaseX core, or do we want the core to stay monolithic/as is? As we are accumulating more and more projects that are embedded only if they are available in the classpath (igo, tagsoup, jline, xml-resolver, ...), our current approach may get too limiting at some stage. On the other hand, people frequently appreciate the fact that the BaseX core still works out-of-the-box without any dependencies.
If we decide to abandon our ascetic attitude, we may still have to decide which libraries won't introduce too much redundancy in terms of functionality; on the other hand, it will be much easier to embed other projects into our core product. And, last but not least, we could merge the "basex" and "basex-api" projects, as those are tightly connected anyway.
We're keeping you updated,
Christian
CD
Charles Duffy2 Apr 2012 18:53 #
Quoted text · Christian Grün · 25 lines
On 04/02/2012 08:07 AM, Christian Grün wrote: >> Work started on that, present in my github tree >> (https://github.com/charles-dyfis-net/basex/commits/java_util_logging). > > Good news, I'll look at that soon. > >> FYI -- I rather strongly disagree with building our own indirection layer to >> dynamically switch between logging libraries, when at least two such layers >> already exist on the market [...] > > True. All this is related to a more general question: do we want to > allow dependencies to other libraries in the BaseX core, or do we want > the core to stay monolithic/as is? As we are accumulating more and > more projects that are embedded only if they are available in the > classpath (igo, tagsoup, jline, xml-resolver, ...), our current > approach may get too limiting at some stage. On the other hand, people > frequently appreciate the fact that the BaseX core still works > out-of-the-box without any dependencies. > > If we decide to abandon our ascetic attitude, we may still have to > decide which libraries won't introduce too much redundancy in terms of > functionality; on the other hand, it will be much easier to embed > other projects into our core product. And, last but not least, we > could merge the "basex" and "basex-api" projects, as those are tightly > connected anyway.
I think that keeping jline, tagsoup, and the like out of the core is a good idea -- they're small, self-contained, and easy to toggle.
I also think that logging is different.
Logging API selection impacts all the code that uses it. As an example: Much of the code I'm writing would be considerably shorter if working with a logging framework which supported MDC; there would be no need to put the current connection info into each logged string by hand, for instance, if it simply were placed in the diagnostic context and emitted as part of the defined format string without needing to be passed as part of each and every log statement.
This kind of problem can't be solved by adding a
lowest-common-denominator wrapper (similar to Apache Commons Logging or, presumably, something we were to write ourselves), but *can* be solved by using an API powerful enough to provide these features on top of an implementation which lacks them. slf4j does this, providing a full-featured, consistent API which provides *all* the features, delegates them to the underlying implementation when possible, and provides its own implementations otherwise.
CD
Quoted text · Christian Grün · 4 lines
On 04/02/2012 08:07 AM, Christian Grün wrote: >> Work started on that, present in my github tree >> (https://github.com/charles-dyfis-net/basex/commits/java_util_logging). > Good news, I'll look at that soon.
FYI --
I just checked in today's work (which includes better support for controlling logging around reflection); this is by no means remotely mergeable, but it might be near a point where a proof-of-concept review could be appropriate.
Incidentally, I'm personally running with the following config file:
# Logging
handlers = java.util.logging.ConsoleHandler
.level = SEVERE
# Default to detailed logging for all of org.basex
org.basex.level = FINER
# HTMLParser throws lots of reflection errors we don't care about org.basex.build.file.HTMLParser.level = INFO
# Console Logging
java.util.logging.ConsoleHandler.level = ALL
java.util.logging.ConsoleHandler.formatter = java.util.logging.XMLFormatter
Being able to do this kind of filtering (logging reflection errors, except for ones from a specific class) is part of what I was aiming at here. The XMLFormatter is interesting largely because it shows what information is available to log; for instance, a typical line looks like the following:
<record>
<date>2012-04-02T18:16:45</date>
<millis>1333408605243</millis>
<sequence>1775</sequence>
<logger>org.basex.build.file.HTMLParser</logger>
<level>FINE</level>
<class>org.basex.build.file.HTMLParser</class>
<method>opt</method>
<thread>24</thread>
<message>Exception thrown during reflection</message>
<exception>
<message>java.lang.IllegalArgumentException:
java.lang.ClassCastException@739efd29</message>
<frame>
<class>sun.reflect.GeneratedMethodAccessor1</class>
<method>invoke</method>
</frame>
<frame>
<class>sun.reflect.DelegatingMethodAccessorImpl</class>
<method>invoke</method>
<line>25</line>
</frame>
[...]...or, for code not converted to the new framework:
<record>
<date>2012-04-02T17:00:29</date>
<millis>1333404029536</millis>
<sequence>193</sequence>
<logger>org.basex.legacy_logger.general</logger>
<level>FINER</level>
<class>org.basex.util.Util</class>
<method>debug</method>
<thread>21</thread>
<message>Indexing Attributes...</message>
</record>Note how in this case "class" is org.basex.util.Util, and "logger" is the name of a generalized legacy logger; the automatic class detection isn't useful here because we're going through a centralized method rather than using the logging library as it's intended to be, ie. called directly at the point in the code where the relevant message is generated. (By the way, it's possible for users to specify format strings which collect more information, specific including line numbers, but this is turned off by default for performance reasons).
CG
Christian Grün3 Apr 2012 10:39 #
..thanks for keeping me updated.
Quoted text · Christian Grün · 90 lines
On Tue, Apr 3, 2012 at 1:18 AM, Charles Duffy <charles at dyfis.net> wrote: > On 04/02/2012 08:07 AM, Christian Grün wrote: >>> >>> Work started on that, present in my github tree >>> (https://github.com/charles-dyfis-net/basex/commits/java_util_logging). >> >> Good news, I'll look at that soon. > > > FYI -- > > I just checked in today's work (which includes better support for > controlling logging around reflection); this is by no means remotely > mergeable, but it might be near a point where a proof-of-concept review > could be appropriate. > > Incidentally, I'm personally running with the following config file: > > # Logging > handlers = java.util.logging.ConsoleHandler > .level = SEVERE > > # Default to detailed logging for all of org.basex > org.basex.level = FINER > > # HTMLParser throws lots of reflection errors we don't care about > org.basex.build.file.HTMLParser.level = INFO > > # Console Logging > java.util.logging.ConsoleHandler.level = ALL > java.util.logging.ConsoleHandler.formatter = java.util.logging.XMLFormatter > > Being able to do this kind of filtering (logging reflection errors, except > for ones from a specific class) is part of what I was aiming at here. The > XMLFormatter is interesting largely because it shows what information is > available to log; for instance, a typical line looks like the following: > > <record> > <date>2012-04-02T18:16:45</date> > <millis>1333408605243</millis> > <sequence>1775</sequence> > <logger>org.basex.build.file.HTMLParser</logger> > <level>FINE</level> > <class>org.basex.build.file.HTMLParser</class> > <method>opt</method> > <thread>24</thread> > <message>Exception thrown during reflection</message> > <exception> > <message>java.lang.IllegalArgumentException: > java.lang.ClassCastException@739efd29</message> > <frame> > <class>sun.reflect.GeneratedMethodAccessor1</class> > <method>invoke</method> > </frame> > <frame> > <class>sun.reflect.DelegatingMethodAccessorImpl</class> > <method>invoke</method> > <line>25</line> > </frame> > [...] > > ...or, for code not converted to the new framework: > > <record> > <date>2012-04-02T17:00:29</date> > <millis>1333404029536</millis> > <sequence>193</sequence> > <logger>org.basex.legacy_logger.general</logger> > <level>FINER</level> > <class>org.basex.util.Util</class> > <method>debug</method> > <thread>21</thread> > <message>Indexing Attributes...</message> > </record> > > Note how in this case "class" is org.basex.util.Util, and "logger" is the > name of a generalized legacy logger; the automatic class detection isn't > useful here because we're going through a centralized method rather than > using the logging library as it's intended to be, ie. called directly at the > point in the code where the relevant message is generated. (By the way, it's > possible for users to specify format strings which collect more information, > specific including line numbers, but this is turned off by default for > performance reasons). > > > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
DP
Quoted text · Christian Grün · 49 lines
Am Montag, 2. April 2012, 09:52:46 schrieb Charles Duffy: > On 04/02/2012 08:07 AM, Christian Grün wrote: > >> Work started on that, present in my github tree > >> (https://github.com/charles-dyfis-net/basex/commits/java_util_logging). > > > > Good news, I'll look at that soon. > > > >> FYI -- I rather strongly disagree with building our own indirection layer to > >> dynamically switch between logging libraries, when at least two such layers > >> already exist on the market [...] > > > > True. All this is related to a more general question: do we want to > > allow dependencies to other libraries in the BaseX core, or do we want > > the core to stay monolithic/as is? As we are accumulating more and > > more projects that are embedded only if they are available in the > > classpath (igo, tagsoup, jline, xml-resolver, ...), our current > > approach may get too limiting at some stage. On the other hand, people > > frequently appreciate the fact that the BaseX core still works > > out-of-the-box without any dependencies. > > > > If we decide to abandon our ascetic attitude, we may still have to > > decide which libraries won't introduce too much redundancy in terms of > > functionality; on the other hand, it will be much easier to embed > > other projects into our core product. And, last but not least, we > > could merge the "basex" and "basex-api" projects, as those are tightly > > connected anyway. > > I think that keeping jline, tagsoup, and the like out of the core is a > good idea -- they're small, self-contained, and easy to toggle. > > I also think that logging is different. > > > Logging API selection impacts all the code that uses it. As an example: > Much of the code I'm writing would be considerably shorter if working > with a logging framework which supported MDC; there would be no need to > put the current connection info into each logged string by hand, for > instance, if it simply were placed in the diagnostic context and emitted > as part of the defined format string without needing to be passed as > part of each and every log statement. > > This kind of problem can't be solved by adding a > lowest-common-denominator wrapper (similar to Apache Commons Logging or, > presumably, something we were to write ourselves), but *can* be solved > by using an API powerful enough to provide these features on top of an > implementation which lacks them. slf4j does this, providing a > full-featured, consistent API which provides *all* the features, > delegates them to the underlying implementation when possible, and > provides its own implementations otherwise.
Hi all,
today I made some research and found why java.util.logging (JUL) is "good, bad and ugly" [1]. Now, as a developer I'm mostly concerned with the fact that JUL may pose performance impact, due to the fact that it does not support parameterized messages. Therefore, if we decide to use JUL we'll have to wrap it anyway.
On the other hand, I found that SLF4J are good enough to provide a java.util.logging.Handler implementation which uses SLF4J [2]. So, I guess we could use the power of SLF4J, even if the accepted logging mechanism is JUL.
Regards,
Dimitar
[1] http://glauche.de/2009/09/09/java-util-logging-vs-slf4j/ [2] https://github.com/ceki/slf4j/tree/master/jul-to-slf4j
DG
Quoted text · Christian Grün · 2 lines
> True. All this is related to a more general question: do we want to allow dependencies to other libraries in the BaseX core, or do we want the core to stay monolithic/as is? As we are accumulating more and more projects that are embedded only if they are available in the classpath (igo, tagsoup, jline, xml-resolver, ...), our current approach may get too limiting at some stage. On the other hand, people frequently appreciate the fact that the BaseX core still works out-of-the-box without any dependencies. > If we decide to abandon our ascetic attitude, we may still have to decide which libraries won't introduce too much redundancy in terms of functionality; on the other hand, it will be much easier to embed other projects into our core product. And, last but not least, we could merge the "basex" and "basex-api" projects, as those are tightly connected anyway.
I for one am a little nervous about the prospect of introducing too many (if any) outside dependencies. The cross-compiling process for Nxdb gets much more complicated the more external Java references are added. Not to mention, from a purely theoretical standpoint, I do appreciate the effort made thus far to keep BaseX free from external library requirements.
That said, I also recognize that logging is one of those features that it just doesn't make sense to write support for when there are so many other suitable libraries out there for use. I personally tend to use log4net on just about every project I write - adding the log4net reference is one of the first things I usually do.
I think the key will be to make sure that hard dependencies are thought through deliberately and only added when and if it is clear they will provide some important and necessary additional functionality. What I really would hate to see happen is for BaseX to require a large hodge-podge of different libraries just to get up and running.
Dave
DP
What is your opinion about creating a wrapper around JUL? Writing
if(logger.isLoggable(Level.FINE)) {
logger.log(Level.FINE,...);
}seems to be a little cumbersome...
Regards,
Dimitar
Quoted text · Charles Duffy · 107 lines
On Wednesday 04 April 2012 16:40:25 Charles Duffy wrote: > FYI -- > > The time I have available to work on this has decreased substantially, > so it might make sense to get what's there right now reviewed so we can > figure out the least-effort path towards merging. > > On 04/03/2012 03:39 AM, Christian Grün wrote: > > ..thanks for keeping me updated. > > ___________________________ > > > > On Tue, Apr 3, 2012 at 1:18 AM, Charles Duffy<charles at dyfis.net> wrote: > >> On 04/02/2012 08:07 AM, Christian Grün wrote: > >>>> Work started on that, present in my github tree > >>>> (https://github.com/charles-dyfis-net/basex/commits/java_util_logging). > >>> > >>> Good news, I'll look at that soon. > >> > >> FYI -- > >> > >> I just checked in today's work (which includes better support for > >> controlling logging around reflection); this is by no means remotely > >> mergeable, but it might be near a point where a proof-of-concept review > >> could be appropriate. > >> > >> Incidentally, I'm personally running with the following config file: > >> > >> # Logging > >> handlers = java.util.logging.ConsoleHandler > >> .level = SEVERE > >> > >> # Default to detailed logging for all of org.basex > >> org.basex.level = FINER > >> > >> # HTMLParser throws lots of reflection errors we don't care about > >> org.basex.build.file.HTMLParser.level = INFO > >> > >> # Console Logging > >> java.util.logging.ConsoleHandler.level = ALL > >> java.util.logging.ConsoleHandler.formatter = > >> java.util.logging.XMLFormatter > >> > >> Being able to do this kind of filtering (logging reflection errors, > >> except > >> for ones from a specific class) is part of what I was aiming at here. The > >> XMLFormatter is interesting largely because it shows what information is > >> available to log; for instance, a typical line looks like the following: > >> > >> <record> > >> <date>2012-04-02T18:16:45</date> > >> <millis>1333408605243</millis> > >> <sequence>1775</sequence> > >> <logger>org.basex.build.file.HTMLParser</logger> > >> <level>FINE</level> > >> <class>org.basex.build.file.HTMLParser</class> > >> <method>opt</method> > >> <thread>24</thread> > >> <message>Exception thrown during reflection</message> > >> <exception> > >> <message>java.lang.IllegalArgumentException: > >> java.lang.ClassCastException@739efd29</message> > >> <frame> > >> <class>sun.reflect.GeneratedMethodAccessor1</class> > >> <method>invoke</method> > >> </frame> > >> <frame> > >> <class>sun.reflect.DelegatingMethodAccessorImpl</class> > >> <method>invoke</method> > >> <line>25</line> > >> </frame> > >> > >> [...] > >> > >> ...or, for code not converted to the new framework: > >> > >> <record> > >> <date>2012-04-02T17:00:29</date> > >> <millis>1333404029536</millis> > >> <sequence>193</sequence> > >> <logger>org.basex.legacy_logger.general</logger> > >> <level>FINER</level> > >> <class>org.basex.util.Util</class> > >> <method>debug</method> > >> <thread>21</thread> > >> <message>Indexing Attributes...</message> > >> </record> > >> > >> Note how in this case "class" is org.basex.util.Util, and "logger" is the > >> name of a generalized legacy logger; the automatic class detection isn't > >> useful here because we're going through a centralized method rather than > >> using the logging library as it's intended to be, ie. called directly at > >> the point in the code where the relevant message is generated. (By the > >> way, it's possible for users to specify format strings which collect > >> more information, specific including line numbers, but this is turned > >> off by default for performance reasons). > >> > >> > >> > >> _______________________________________________ > >> BaseX-Talk mailing list > >> BaseX-Talk at mailman.uni-konstanz.de > >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
CD
FYI --
The time I have available to work on this has decreased substantially, so it might make sense to get what's there right now reviewed so we can figure out the least-effort path towards merging.
Quoted text · Christian Grün · 91 lines
On 04/03/2012 03:39 AM, Christian Grün wrote: > ..thanks for keeping me updated. > ___________________________ > > On Tue, Apr 3, 2012 at 1:18 AM, Charles Duffy<charles at dyfis.net> wrote: >> On 04/02/2012 08:07 AM, Christian Grün wrote: >>>> Work started on that, present in my github tree >>>> (https://github.com/charles-dyfis-net/basex/commits/java_util_logging). >>> Good news, I'll look at that soon. >> >> FYI -- >> >> I just checked in today's work (which includes better support for >> controlling logging around reflection); this is by no means remotely >> mergeable, but it might be near a point where a proof-of-concept review >> could be appropriate. >> >> Incidentally, I'm personally running with the following config file: >> >> # Logging >> handlers = java.util.logging.ConsoleHandler >> .level = SEVERE >> >> # Default to detailed logging for all of org.basex >> org.basex.level = FINER >> >> # HTMLParser throws lots of reflection errors we don't care about >> org.basex.build.file.HTMLParser.level = INFO >> >> # Console Logging >> java.util.logging.ConsoleHandler.level = ALL >> java.util.logging.ConsoleHandler.formatter = java.util.logging.XMLFormatter >> >> Being able to do this kind of filtering (logging reflection errors, except >> for ones from a specific class) is part of what I was aiming at here. The >> XMLFormatter is interesting largely because it shows what information is >> available to log; for instance, a typical line looks like the following: >> >> <record> >> <date>2012-04-02T18:16:45</date> >> <millis>1333408605243</millis> >> <sequence>1775</sequence> >> <logger>org.basex.build.file.HTMLParser</logger> >> <level>FINE</level> >> <class>org.basex.build.file.HTMLParser</class> >> <method>opt</method> >> <thread>24</thread> >> <message>Exception thrown during reflection</message> >> <exception> >> <message>java.lang.IllegalArgumentException: >> java.lang.ClassCastException@739efd29</message> >> <frame> >> <class>sun.reflect.GeneratedMethodAccessor1</class> >> <method>invoke</method> >> </frame> >> <frame> >> <class>sun.reflect.DelegatingMethodAccessorImpl</class> >> <method>invoke</method> >> <line>25</line> >> </frame> >> [...] >> >> ...or, for code not converted to the new framework: >> >> <record> >> <date>2012-04-02T17:00:29</date> >> <millis>1333404029536</millis> >> <sequence>193</sequence> >> <logger>org.basex.legacy_logger.general</logger> >> <level>FINER</level> >> <class>org.basex.util.Util</class> >> <method>debug</method> >> <thread>21</thread> >> <message>Indexing Attributes...</message> >> </record> >> >> Note how in this case "class" is org.basex.util.Util, and "logger" is the >> name of a generalized legacy logger; the automatic class detection isn't >> useful here because we're going through a centralized method rather than >> using the logging library as it's intended to be, ie. called directly at the >> point in the code where the relevant message is generated. (By the way, it's >> possible for users to specify format strings which collect more information, >> specific including line numbers, but this is turned off by default for >> performance reasons). >> >> >> >> _______________________________________________ >> BaseX-Talk mailing list >> BaseX-Talk at mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
CD
Naively wrapping JUL would mean that log messages' metadata would have class and line location of the wrapper, not the original method (unless we explicitly passed it everywhere and used logp(), which is also cumbersome). Avoiding this and similar pitfalls is code that needs to be written and maintained, and it's work that SLF4J has already done.
(As a quick point of clarification -- the isLoggable() check is necessary only when calculating one of the arguments to logger.log requires a non-negligible amount of time; string concatenation, allocating a new Object[] array, and similar things can fall into this category).
Quoted text · Dimitar Popov · 132 lines
On Wed, Apr 4, 2012 at 5:12 PM, Dimitar Popov <dimitar.popov at uni-konstanz.de > wrote: > What is your opinion about creating a wrapper around JUL? Writing > > if(logger.isLoggable(Level.FINE)) { > logger.log(Level.FINE,...); > } > > seems to be a little cumbersome... > > Regards, > Dimitar > > On Wednesday 04 April 2012 16:40:25 Charles Duffy wrote: > > FYI -- > > > > The time I have available to work on this has decreased substantially, > > so it might make sense to get what's there right now reviewed so we can > > figure out the least-effort path towards merging. > > > > On 04/03/2012 03:39 AM, Christian Grün wrote: > > > ..thanks for keeping me updated. > > > ___________________________ > > > > > > On Tue, Apr 3, 2012 at 1:18 AM, Charles Duffy<charles at dyfis.net> > wrote: > > >> On 04/02/2012 08:07 AM, Christian Grün wrote: > > >>>> Work started on that, present in my github tree > > >>>> ( > https://github.com/charles-dyfis-net/basex/commits/java_util_logging). > > >>> > > >>> Good news, I'll look at that soon. > > >> > > >> FYI -- > > >> > > >> I just checked in today's work (which includes better support for > > >> controlling logging around reflection); this is by no means remotely > > >> mergeable, but it might be near a point where a proof-of-concept > review > > >> could be appropriate. > > >> > > >> Incidentally, I'm personally running with the following config file: > > >> > > >> # Logging > > >> handlers = java.util.logging.ConsoleHandler > > >> .level = SEVERE > > >> > > >> # Default to detailed logging for all of org.basex > > >> org.basex.level = FINER > > >> > > >> # HTMLParser throws lots of reflection errors we don't care about > > >> org.basex.build.file.HTMLParser.level = INFO > > >> > > >> # Console Logging > > >> java.util.logging.ConsoleHandler.level = ALL > > >> java.util.logging.ConsoleHandler.formatter = > > >> java.util.logging.XMLFormatter > > >> > > >> Being able to do this kind of filtering (logging reflection errors, > > >> except > > >> for ones from a specific class) is part of what I was aiming at here. > The > > >> XMLFormatter is interesting largely because it shows what information > is > > >> available to log; for instance, a typical line looks like the > following: > > >> > > >> <record> > > >> <date>2012-04-02T18:16:45</date> > > >> <millis>1333408605243</millis> > > >> <sequence>1775</sequence> > > >> <logger>org.basex.build.file.HTMLParser</logger> > > >> <level>FINE</level> > > >> <class>org.basex.build.file.HTMLParser</class> > > >> <method>opt</method> > > >> <thread>24</thread> > > >> <message>Exception thrown during reflection</message> > > >> <exception> > > >> <message>java.lang.IllegalArgumentException: > > >> java.lang.ClassCastException@739efd29</message> > > >> <frame> > > >> <class>sun.reflect.GeneratedMethodAccessor1</class> > > >> <method>invoke</method> > > >> </frame> > > >> <frame> > > >> <class>sun.reflect.DelegatingMethodAccessorImpl</class> > > >> <method>invoke</method> > > >> <line>25</line> > > >> </frame> > > >> > > >> [...] > > >> > > >> ...or, for code not converted to the new framework: > > >> > > >> <record> > > >> <date>2012-04-02T17:00:29</date> > > >> <millis>1333404029536</millis> > > >> <sequence>193</sequence> > > >> <logger>org.basex.legacy_logger.general</logger> > > >> <level>FINER</level> > > >> <class>org.basex.util.Util</class> > > >> <method>debug</method> > > >> <thread>21</thread> > > >> <message>Indexing Attributes...</message> > > >> </record> > > >> > > >> Note how in this case "class" is org.basex.util.Util, and "logger" is > the > > >> name of a generalized legacy logger; the automatic class detection > isn't > > >> useful here because we're going through a centralized method rather > than > > >> using the logging library as it's intended to be, ie. called directly > at > > >> the point in the code where the relevant message is generated. (By the > > >> way, it's possible for users to specify format strings which collect > > >> more information, specific including line numbers, but this is turned > > >> off by default for performance reasons). > > >> > > >> > > >> > > >> _______________________________________________ > > >> BaseX-Talk mailing list > > >> BaseX-Talk at mailman.uni-konstanz.de > > >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > > > _______________________________________________ > > BaseX-Talk mailing list > > BaseX-Talk at mailman.uni-konstanz.de > > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > >
Written for BaseX 7.2. BaseX may have changed since: please check the current documentation.
⚡Generated with XQuery