Moving to log4j, java.util.logging, Apache Commons Logging, etc?
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.
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). Christian
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
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.
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).
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 ______________________________
[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@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
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_dependency
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@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
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. We're keeping you updated, Christian
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.
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
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).
..thanks for keeping me updated. ___________________________ On Tue, Apr 3, 2012 at 1:18 AM, Charles Duffy <charles@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@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
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@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@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
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@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@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
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). On Wed, Apr 4, 2012 at 5:12 PM, Dimitar Popov <dimitar.popov@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@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@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
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
participants (5)
-
Charles Duffy -
Christian Grün -
Dave Glick -
Dimitar Popov -
Dimitar Popov