[
https://issues.apache.org/jira/browse/SOLR-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-1725:
---------------------------
Attachment: SOLR-1725.patch
Updated patch with lots of changes, here's the notes i kept as i went along...
* updated patch to trunk
* added classloader to ScriptEngineManager constructor
* fixed InputStreamReader to use UTF-8
* fixed Reader usage to ensure it's closed
* fixed file extension parsing using commons-io
* renamed some test files to make it more clear at a glance what they were for
* more tests and asserts to verify that changes are working (including adding
field values)
* added logic to allow script functions to return "false" to end processing of
this command
* fixed init to call super.init
* removed splitting of string "scripts" init param, replaced with multivalued
"script" init param
* generallize "params" to allow any init param type (not just NamedList)
* add support for forcing engine name
* add details about supported engines if we can't fine one by extension/name
* updated javadocs
Things i still want to deal with:
* make test assume() javascript/js engine is available - from what i can tell
JREs aren't required to support it
* check engine(s) & scripts exist in inform
* add tests of bad configs (bad engine name, bad extension)
* polish javadocs
* deal with problem of processor functions that don't exist in script.
The last one is a biggee. from what i can tell, the ScriptEngine api doesn't
give us any sort of "reflection" and the more i think about it, the more
silently ignoring when a function doesn't exist seems like a really bad idea --
what if the script has a function name with a typo in it? what if a stray "cat"
command causes someome to accidently truncate a script file to 0 bytes? (so
it's still a legal script, but doesn't have any functions?) ... i think we
should fail hard if any method used isn't found -- so people have to implement
every method that they use (ie: if you never use "rollback" it's no big deal
that you don't have a processRollback(...) method)
> Script based UpdateRequestProcessorFactory
> ------------------------------------------
>
> Key: SOLR-1725
> URL: https://issues.apache.org/jira/browse/SOLR-1725
> Project: Solr
> Issue Type: New Feature
> Components: update
> Affects Versions: 1.4
> Reporter: Uri Boness
> Assignee: Erik Hatcher
> Labels: UpdateProcessor
> Fix For: 4.1
>
> Attachments: SOLR-1725-rev1.patch, SOLR-1725.patch, SOLR-1725.patch,
> SOLR-1725.patch, SOLR-1725.patch, SOLR-1725.patch, SOLR-1725.patch,
> SOLR-1725.patch, SOLR-1725.patch, SOLR-1725.patch, SOLR-1725.patch
>
>
> A script based UpdateRequestProcessorFactory (Uses JDK6 script engine
> support). The main goal of this plugin is to be able to configure/write
> update processors without the need to write and package Java code.
> The update request processor factory enables writing update processors in
> scripts located in {{solr.solr.home}} directory. The functory accepts one
> (mandatory) configuration parameter named {{scripts}} which accepts a
> comma-separated list of file names. It will look for these files under the
> {{conf}} directory in solr home. When multiple scripts are defined, their
> execution order is defined by the lexicographical order of the script file
> name (so {{scriptA.js}} will be executed before {{scriptB.js}}).
> The script language is resolved based on the script file extension (that is,
> a *.js files will be treated as a JavaScript script), therefore an extension
> is mandatory.
> Each script file is expected to have one or more methods with the same
> signature as the methods in the {{UpdateRequestProcessor}} interface. It is
> *not* required to define all methods, only those hat are required by the
> processing logic.
> The following variables are define as global variables for each script:
> * {{req}} - The SolrQueryRequest
> * {{rsp}}- The SolrQueryResponse
> * {{logger}} - A logger that can be used for logging purposes in the script
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
