I did a multi level explain system in the work I did at DERI. (I'll have to go back and look at the code) but I suspect that if we do something like what the httpcommons does for the various custom logs it would work.
perhaps multiple Loggers with org.apache.jena.explain as the root logger then adding org.apache.jena.explain.queries org.apache.jena.explain.algebra org.apache.jena.explain.exec org.apache.jena.explain.remote so that you can turn off, up or down the log level for any particular part of the query execution. The one I did used a single Logger and the query ID to track the output for the specific query. The engine logged specific information we wanted (like how long to get a response from a federated query and how many triples it returned) and in the end we packaged up all the info into a single string that the user could download via a rest request. We added session capability to Fuseki, so we stored the explain in the session, the user could then request the explain information immediately after a request. Claude On Mon, May 12, 2014 at 2:02 PM, Andy Seaborne (JIRA) <[email protected]>wrote: > > [ > https://issues.apache.org/jira/browse/JENA-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13995048#comment-13995048] > > Andy Seaborne edited comment on JENA-691 at 5/12/14 1:00 PM: > ------------------------------------------------------------- > > What I am finding is that (and this is crossing the external/debug > boundary but in a complicated system the boundary is not clear cut to me) I > want to turn specific parts on and off, and the simple info/fine is too > crude. At least, there need to be more levels but, due to verbosity, it's > nice to select output of specific parts of the system. The local/remote > case would be useful even currently, or TDB vs in-memory (because various > things use SPARQL on in-memory datasets themselves internally). > > At the moment, {{Explain}} messages go to an SLF4J logger at level info. > There is one logger for all {{Explain}}. Several loggers would be > possible (with some hackery because the messages are multi-line). Even so, > an API to simply manage this from within running code would be good. Use > of SLF4J can be the implementation. > > > > was (Author: andy.seaborne): > What I am finding is that (and this is crossing the external/debug > boundary but in a complicated system the boundary is not clear cut to me) I > want to turn specific parts on and off, and the simple info/fine is too > crude. At least, there need to be more levels but, due to verbosity, it's > nice to select output of specific parts of the system. The local/remote > case would be useful even currently, or TDB vs in-memory (because various > things use SPARQL on in-memory datasets themselves internally). > > At the moment, {{Explain}} messages go to an SLF4J logger at level info. > There is one logger for all {{Explain}}. Several loggers would be > possible (with some hackery because the messages are multi-line). Even so, > an API to simple manage this from within running code would be good. Use > of SLF4J can be the implementation. > > > > "Explain" Categories > > -------------------- > > > > Key: JENA-691 > > URL: https://issues.apache.org/jira/browse/JENA-691 > > Project: Apache Jena > > Issue Type: Improvement > > Reporter: Andy Seaborne > > > > "Explain" capabilities in ARQ are provided like logging levels with > levels ALL, INFO, FINE and NONE. For example, Algebra is printed at level > FINE but that implies level INFO, which includes queries. > > Instead, categories would be better so that a "mix and match" of various > explanations could be set to give a more focused output. > > This JIRA is for collecting suggestions, requests and contributions for > a more extensive "Explain" capability. > > > > -- > This message was sent by Atlassian JIRA > (v6.2#6252) > -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
