[
https://issues.apache.org/jira/browse/SOLR-15121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280166#comment-17280166
]
Uwe Schindler commented on SOLR-15121:
--------------------------------------
Hi,
I did a quick look at it. The problem is that you cloned the whole XML handler
and one contains the XSL callback the other not.
It had a reason that both were in the same handler, as the actual XSLT stuff is
just some small piece: taking the parsed XML as DOM tree and apply the XSL to
it and then go on with standard processing.
IMHO the correct way to handle this would be to have all the functionality in
Solr Core only and just disable it. The Contrib just makes the "tr" parameter
visible. Another aproach would be to add a protected "transform" method (taking
some Source, returning Result) that by default is a noop (return a Result
wrapping the Source). The contrib just implements this method.
> 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: 1h 20m
> 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
