ScriptingPlugin question

> What steps will reproduce the problem?
1. Start luke with the following command:
java -cp $CLASSPATH org.getopt.luke.Luke -index /path/to/index -ro -script 
testfile.js
2. testfile.js contains the following line:
print(ir.numDocs());

> What is the expected output? What do you see instead?
More like "desired" rather than "expected" output. If I specify a script file 
on the command line, my expectation is that the output should be shown on the 
command line and luke would exit after it ran my script.

Instead I see that output of the script show up on the Luke scripting plugin 
console, and I have to manually shut Luke down.

> What version of the product are you using? On what operating system?
Luke version: 1.0.1 with Lucene 3.0.1 on Mac OS X (10.6)

> Please provide any additional information below.

I tried hacking the code a bit to replace TAWriter in ScriptingPlugin:48 with 
PrintWriter taw = new PrintWriter(System.out) and some other things - this does 
display the result to console, but Luke does not exit.

If I try to forcibly exit by adding this line to my testfile.js:
app.actionExit();
then I get a stack trace that points to some background threads being forcibly 
killed, and no result. If I enter the above command in the ScriptingPlugin 
console, then Luke exits cleanly without complaints.

Questions:
1) Is my expectation, ie, if I specify -script on the command line, then the 
command should dump out the result of my script and exit, make sense? More 
importantly, would this feature be considered (so I will wait for it instead of 
trying to build my own). Of course, if no -script is provided, then the user 
can still load external scripts using load("/full/path/to/script"); in the 
console and execute them.
2) Is there a way (perhaps a different call) that would execute the script, 
then wait for the background threads to complete before closing all the handles?
3) In case support for this is not planned, would the correct approach be to 
build a separate plugin for this functionality (BatchScriptingPlugin say) which 
would be triggered by a different command line parameter? Or would it be better 
to provide a different main class (LukeCli say) which would call the internal 
methods and also provide a Javascript context like ScriptingPlugin? From my 
initial explorations into the Luke code, the last approach appears to not be 
very feasible, since the code seems to be very tightly coupled with the GUI 
framework.

My motivation is to use Luke's ScriptingPlugin to debug remote production 
indexes.

TIA for your answers, and thanks for a great tool.

Sujit

Original issue reported on code.google.com by sujitatg...@gmail.com on 17 Nov 2010 at 8:57

Follow up to the above...

I was trying to build a search script and I was not able to get the value for 
the Version enum which is needed for building Analyzer and QueryParser. So I 
added a getLuceneVersion() in Luke.java that returns Version.LUCENE_30.

public Version getLuceneVersion() {
  return Version.LUCENE_30;
}

Since Luke does require specific Lucene versions, this would probably be 
reasonable to do?

The Javascript code can then pick this up as app.getLuceneVersion().

var analyzer = 
  new Packages.org.apache.lucene.analysis.standard.StandardAnalyzer(
  app.getLuceneVersion());
var parser = new Packages.org.apache.lucene.queryParser.QueryParser(
  app.getLuceneVersion(), "f", analyzer);
var searcher = new Packages.org.apache.lucene.search.IndexSearcher(ir);
var query = parser.parse("title:foo");
var hits = searcher.search(query, 100).scoreDocs;
for (var i = 0; i < hits.length; i++) {
  get(hits[i].doc, hits[i].score);
}
searcher.close();

Thanks
Sujit

Original comment by sujitatg...@gmail.com on 20 Nov 2010 at 8:07

ddolddoly / luke

ScriptingPlugin question #30