Hello Andy, Mea culpa!! I finally tracked down my problem. The testbed was running a slightly older version than I had thought. Now that I’m using up-to-date I’m seeing the debug info that was added 19 Aug.
Sorry for wasting b/w, Chris > On Oct 23, 2017, at 4:58 PM, Chris Tomlinson <[email protected]> > wrote: > > Hi Andy, > > The "Lucene query: {} ({})” message is not coming out at all. I try a variety > of queries, and other parameter settings and since the cache key is such that > any change in query, limit, language snd such leads to another key I should > see many such log statements. > > In any event, I’ll look further into the matter since I’ll now fork jena and > see what I can do regarding the highlighting. > > Thanks, > Chris > > > >> On Oct 23, 2017, at 3:31 PM, Andy Seaborne <[email protected] >> <mailto:[email protected]>> wrote: >> >> That all looks right. >> >> Is the message not coming out at all or coming out once only? I ask because >> it is in a "getOrFill" so the Callable is only called when there is a cache >> miss. >> >> Andy >> >> On 22/10/17 18:22, Chris Tomlinson wrote: >>> Hello Andy, >>> Thank you for the reply. I’m apparently not facile with log4j.properties. >>> I've tried several configurations and I'm only able to get the TextQueryPF >>> log.debug() to fire: >>>> [2017-10-22 16:47:52] Fuseki INFO [1] POST >>>> http://localhost:13180/fuseki/bdrcrw/query >>>> <http://localhost:13180/fuseki/bdrcrw/query> >>>> [2017-10-22 16:47:52] Fuseki INFO [1] POST /bdrcrw :: 'query' :: >>>> [application/x-www-form-urlencoded charset=UTF-8] ? >>>> [2017-10-22 16:47:52] Fuseki INFO [1] Query = PREFIX : >>>> <http://purl.bdrc.io/ontology/root# <http://purl.bdrc.io/ontology/root#>> >>>> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns# >>>> <http://www.w3.org/1999/02/22-rdf-syntax-ns#>> PREFIX rdfs: >>>> <http://www.w3.org/2000/01/rdf-schema# >>>> <http://www.w3.org/2000/01/rdf-schema#>> PREFIX owl: >>>> <http://www.w3.org/2002/07/owl# <http://www.w3.org/2002/07/owl#>> PREFIX >>>> adm: <http://purl.bdrc.io/ontology/admin/ >>>> <http://purl.bdrc.io/ontology/admin/>> PREFIX bdo: >>>> <http://purl.bdrc.io/ontology/core/ <http://purl.bdrc.io/ontology/core/>> >>>> PREFIX bdr: <http://purl.bdrc.io/resource/ >>>> <http://purl.bdrc.io/resource/>> PREFIX text: >>>> <http://jena.apache.org/text# <http://jena.apache.org/text#>> PREFIX skos: >>>> <http://www.w3.org/2004/02/skos/core# >>>> <http://www.w3.org/2004/02/skos/core#>> PREFIX lang: >>>> <http://ontologi.es/lang/core# <http://ontologi.es/lang/core#>> PREFIX ad: >>>> <http://schemas.talis.com/2005/address/schema# >>>> <http://schemas.talis.com/2005/address/schema#>> select ?s ?n ?sc where { >>>> (?s1 ?sc ?lit) text:query (bdo:chunkContents "\"དགའ་རབ་རྡོ་རྗེ་\"") . >>>> ?s bdo:eTextHasChunk ?s1 . ?s1 bdo:seqNum ?n . } limit 10 >>>> [2017-10-22 16:47:52] TextQueryPF DEBUG Text query: "དགའ་རབ་རྡོ་རྗེ་" (-1) >>>> [2017-10-22 16:47:52] Fuseki INFO [1] 200 OK (423 ms) >>> I’ve tried a variety of configurations along the following lines: >>>> log4j.rootLogger=INFO, jena.plainstdout >>>> log4j.logger.org.apache.jena=INFO >>>> log4j.logger.org.apache.jena.fuseki=INFO >>>> log4j.logger.org.apache.jena.query.text=DEBUG >>>> log4j.logger.org.apache.jena.query.text.TextQueryPF=DEBUG >>>> log4j.logger.org.apache.jena.query.text.TextIndexLucene=DEBUG >>> As I understand, setting log4j.logger.org.apache.jena=DEBUG should be >>> sufficient (if too verbose) and setting >>> log4j.logger.org.apache.jena.query.text=DEBUG should have enabled debug for >>> any class in the package and I really thought >>> log4j.logger.org.apache.jena.query.text.TextIndexLucene=DEBUG should have >>> enabled debug level in TextIndexLucene specifically. Setting >>> log4j.logger.org.apache.jena.query.text=DEBUG and >>> log4j.logger.org.apache.jena.query.text.TextQueryPF=INFO indeed turns off >>> the log.debug in TextQueryPF as I expected. >>> The code region containing the log.debug() in TextIndexLucene is: >>>> >>>> String queryString = textClause ; >>>> if (langClause != null) >>>> queryString = "(" + queryString + ") AND " + langClause ; >>>> if (graphClause != null) >>>> queryString = "(" + queryString + ") AND " + graphClause ; >>>> >>>> if ( log.isDebugEnabled()) >>>> log.debug("Lucene query: {} ({})", queryString,limit) ; >>>> >>>> IndexSearcher indexSearcher = new IndexSearcher(indexReader) ; >>>> Query query = parseQuery(queryString, queryAnalyzer) ; >>>> if ( limit <= 0 ) >>>> limit = MAX_N ; >>>> ScoreDoc[] sDocs = indexSearcher.search(query, limit).scoreDocs ; >>>> >>>> List<TextHit> results = new ArrayList<>() ; >>> And I know that execution passes the log.isDebugEnabled and reaches the >>> parseQuery() since I can inject a queryString with an error and see the >>> stack trace where the ParseException is caught in the getOrFill(). >>> As far as I can tell the log is setup in the same manner in TextQueryPF and >>> TextIndexLucene: >>>> import org.slf4j.Logger ; >>>> import org.slf4j.LoggerFactory ; >>>> >>>> /** property function that accesses a text index */ >>>> public class TextQueryPF extends PropertyFunctionBase { >>>> private static Logger log = LoggerFactory.getLogger(TextQueryPF.class) >>>> ; >>> and >>>> import org.slf4j.Logger ; >>>> import org.slf4j.LoggerFactory ; >>>> >>>> public class TextIndexLucene implements TextIndex { >>>> private static Logger log = >>>> LoggerFactory.getLogger(TextIndexLucene.class) ; >>> What am I missing? >>> Thanks, >>> Chris >>>> On Oct 21, 2017, at 3:33 PM, Andy Seaborne <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> >>>> On 20/10/17 20:00, Chris Tomlinson wrote: >>>>> Hi, >>>>> I’m interested in looking into whether and how it might be possible to >>>>> incorporate Lucene highlighting into jena-text. I don’t see any other >>>>> work, but perhaps others have dealt with the topic already. I was >>>>> thinking of some sort of a 4th return parameter in the PF. >>>>> While examining the code I found an oddity. I was interested in seeing >>>>> the final Lucene query created in TextIndexLucene via the log.debug at >>>>> line 417 but it never fires even though the log.debug at line 249 in >>>>> TextQueryPF produces expected output. I’m guessing that somehow the use >>>>> of the lambda in getOrFill of the cache at line 267 of TextQueryPF >>>>> somehow obscures the logging properties. Maybe that’s why there’s the >>>>> commented out alternative that avoids the cache? >>>> >>>> Because they are different loggers? As statics, they are as compiled, no >>>> closure related. >>>> >>>> TextIndexLucene.class and TextQueryPF.class respectively. >>>> >>>> (I see the "no cache" code as a debugging remains - there was a cache >>>> issue recently) >>>> >>>> Andy >>>> >>>>> Thanks, >>>>> Chris >
