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