[
https://issues.apache.org/jira/browse/SOLR-15121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280211#comment-17280211
]
David Eric Pugh commented on SOLR-15121:
----------------------------------------
[~uschindler] your suggestion makes a LOT of sense to me, and I can work
towards that.
So here is where my Java skills start failing me.. What is the best way for
the contrib module to override the default behavior of the core module? In my
PR I tried to look if a class existed, and then use it, that was how I did the
XSLTLoader lookup, but I knew that wasn't great.
Do I need to somehow make the UpdateRequestHandler pluggable like this:
{{
<requestHandler name="/update" class="solr.UpdateRequestHandler">
<contentLoader mimeType="xml/application"
class="org.apache.solr.scripting.XSLTLoader"/>
</requestHandler>
}}
Any simpler options?
> Move XSLT (tr param) to scripting contrib
> -----------------------------------------
>
> Key: SOLR-15121
> URL: https://issues.apache.org/jira/browse/SOLR-15121
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Assignee: David Eric Pugh
> Priority: Blocker
> Fix For: master (9.0)
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> The XSLT functionality, present in both XML /update loading, and also in the
> response writer, ought to move to the "scripting" contrib module because XSLT
> is a type of scripting. XSLT is risky from a security standpoint, and so
> should not be in solr-core.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
