You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Bertrand Delacretaz (JIRA)" <ji...@apache.org> on 2006/09/14 17:52:22 UTC
[jira] Created: (SOLR-49) PATCH: XSLTServletFilter
PATCH: XSLTServletFilter
------------------------
Key: SOLR-49
URL: http://issues.apache.org/jira/browse/SOLR-49
Project: Solr
Issue Type: New Feature
Components: search
Environment: Tested on macosx 10.4.7, JDK 1.5.0_06
Reporter: Bertrand Delacretaz
Priority: Minor
Patch that implements server-side XSLT transforms of query results.
The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example:
http://localhost:8983/solr/select/html?q=usage&transform=my.xsl
In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format.
Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far.
The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already.
The patch is all new files, except for adding this in web.xml before the first <servlet>:
<filter>
<filter-name>xslt</filter-name>
<filter-class>org.apache.solr.xslt.XSLTServletFilter</filter-class>
</filter>
<!-- apply the XSLT filter when select/html is used to make queries -->
<filter-mapping>
<filter-name>xslt</filter-name>
<url-pattern>/select/html/*</url-pattern>
</filter-mapping>
I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (SOLR-49) PATCH: XSLTServletFilter
Posted by Chris Hostetter <ho...@fucit.org>.
: > I'm wondering if moving to a lightweight object container
: > (picocontainer, Spring, HiveMind...) to assemble and configure Solr's
: > components wouldn't make sense at some point...it might be too much
: > work right now, but I can't help thinking that there's some
: > reinvention going on here.
:
: There certainly is reinvention going on... it's just too easy to keep
: making incremental changes at this point.
yeah, the nice thing about having Solr use it's own homegrown
config parsing / object-factory based framework is that we don't alienate
anyone in particular by not using the framework they are most familiar
with.
Instead we get the best of all worlds by alienating everyone! :)
-Hoss
Re: [jira] Updated: (SOLR-49) PATCH: XSLTServletFilter
Posted by Yonik Seeley <yo...@apache.org>.
On 9/26/06, Bertrand Delacretaz <bd...@apache.org> wrote:
> On 9/26/06, Chris Hostetter <ho...@fucit.org> wrote:
>
> > ...Since this QueryResponseWriter has use of configuration options, now is
> > probably the time to add an init(NamedList) method to the interface that
> > get's called with a upon construction by SolrCore...
>
> I'm wondering if moving to a lightweight object container
> (picocontainer, Spring, HiveMind...) to assemble and configure Solr's
> components wouldn't make sense at some point...it might be too much
> work right now, but I can't help thinking that there's some
> reinvention going on here.
There certainly is reinvention going on... it's just too easy to keep
making incremental changes at this point.
http://www.nabble.com/solr-configuration-path-change-tf1286821.html#a3422968
http://www.nabble.com/XML-Query-tf1407548.html#a3809517
http://www.nabble.com/Fwd%3A-Microkernal-architecture-%28was-Re%3A-XML-Query%29-tf1416310.html#a3817176
-Yonik
Re: [jira] Updated: (SOLR-49) PATCH: XSLTServletFilter
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 9/26/06, Chris Hostetter <ho...@fucit.org> wrote:
> ...Since this QueryResponseWriter has use of configuration options, now is
> probably the time to add an init(NamedList) method to the interface that
> get's called with a upon construction by SolrCore...
I'm wondering if moving to a lightweight object container
(picocontainer, Spring, HiveMind...) to assemble and configure Solr's
components wouldn't make sense at some point...it might be too much
work right now, but I can't help thinking that there's some
reinvention going on here.
> ...FYI: an alternate approach to caching the Templates object in the
> TransformProvider would be to use the SolrCache framework...
Ok - I'll have a look, thanks!
-Bertrand
Re: [jira] Updated: (SOLR-49) PATCH: XSLTServletFilter
Posted by Chris Hostetter <ho...@fucit.org>.
: Attachment: solr-XSLTResponseWriter-20060922.tar.gz
I finally got a chance to look at this tonight, i like it, but the big
thing thta jumped out at me was the configuration...
Since this QueryResponseWriter has use of configuration options, now is
probably the time to add an init(NamedList) method to the interface that
get's called with a upon construction by SolrCore just like
SolrRequestHandler (using DOMUtils.nodesToNamedList) ... that will have
the added benefit of allowing response writers to have defaults that can
be overriden by the defaults of the request handler *or* by query time
params.
FYI: an alternate approach to caching the Templates object in the
TransformProvider would be to use the SolrCache framework -- the
LRUCache doesn't currently have a notion of timed "expiration" but we
could just re-check the file modification in a CacheRegenertor and
document that the xsl files are only checked on commit. (which may be a
better meme in general now that i think about).
-Hoss
[jira] Updated: (SOLR-49) PATCH: XSLTServletFilter
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SOLR-49?page=all ]
Bertrand Delacretaz updated SOLR-49:
------------------------------------
Attachment: solr-XSLTResponseWriter-20060922.tar.gz
Here's yet another version which takes the Content-Type from the XSLT transform.
The code and these instructions replace the previous versions:
Must be configured like this in solrconfig.xml:
<!--
XSLT response writer (SOLR-49)
Changes to XSLT transforms are taken into account every xsltCacheLifetimeSeconds at most.
-->
<queryResponseWriter
name="xslt"
class="org.apache.solr.request.XSLTResponseWriter"
xsltCacheLifetimeSeconds="5"
/>
The following request parameters activate the XSLTResponseWriter:
wt = xslt
tr = my-xslt-transform.xsl
The Content-Type comes from the xsl:output element of the XSLT transform:
<xsl:output media-type="text/html"/>
And finally, the TransformerProvider warns about the possible performance implications of its simplistic cache, when first used:
ATTENTION: The TransformerProvider's simplistic XSLT caching mechanism is
not appropriate for high load scenarios, unless a single XSLT transform is used
and xsltCacheLifetimeSeconds is set to a sufficiently high value.
> PATCH: XSLTServletFilter
> ------------------------
>
> Key: SOLR-49
> URL: http://issues.apache.org/jira/browse/SOLR-49
> Project: Solr
> Issue Type: New Feature
> Components: search
> Environment: Tested on macosx 10.4.7, JDK 1.5.0_06
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: solr-XSLTResponseWriter-20060922.tar.gz, solr-XSLTResponseWriter-files.tar.gz, xslt-filter-files.tar.gz
>
>
> Patch that implements server-side XSLT transforms of query results.
> The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example:
> http://localhost:8983/solr/select/html?q=usage&transform=my.xsl
> In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format.
> Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far.
> The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already.
> The patch is all new files, except for adding this in web.xml before the first <servlet>:
> <filter>
> <filter-name>xslt</filter-name>
> <filter-class>org.apache.solr.xslt.XSLTServletFilter</filter-class>
> </filter>
> <!-- apply the XSLT filter when select/html is used to make queries -->
> <filter-mapping>
> <filter-name>xslt</filter-name>
> <url-pattern>/select/html/*</url-pattern>
> </filter-mapping>
> I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-49) PATCH: XSLTServletFilter
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SOLR-49?page=all ]
Hoss Man updated SOLR-49:
-------------------------
Attachment: SOLR-49.diff
SOLR-49.diff is solr-XSLTResponseWriter-20061016.tar.gz in svn patch form with a few small tweaks...
1) I removed the javadocs on the init() method in each of the concrete QueryResponseWriter classes so they would inherit the interface docs.
2) I added a small unit test to demonstrate that the stylesheet was being applied
I think this is commitable as is, but one small thing occured to me that i wanted to get concensus on first: right now this can be used to expose any file in the ${solr.home}/conf by trying to use it as an XSLT ... should it respect the
<gettableFiles> directive in the solrconfig.xml -- which might be anoying since it requires explicitly listing each file, or should we change this to only look at files in some new ${solr.home}/xslt (or ${solr.home}/conf/xslt) directory?
another minor nit: query-to-html.xsl seems like it would render the "query" as html, not the results of the query ... maybe we should just call it "example.xsl" ?
> PATCH: XSLTServletFilter
> ------------------------
>
> Key: SOLR-49
> URL: http://issues.apache.org/jira/browse/SOLR-49
> Project: Solr
> Issue Type: New Feature
> Components: search
> Environment: Tested on macosx 10.4.7, JDK 1.5.0_06
> Reporter: Bertrand Delacretaz
> Assigned To: Hoss Man
> Priority: Minor
> Attachments: SOLR-49.diff, solr-XSLTResponseWriter-20060922.tar.gz, solr-XSLTResponseWriter-20061016.tar.gz, solr-XSLTResponseWriter-files.tar.gz, xslt-filter-files.tar.gz
>
>
> Patch that implements server-side XSLT transforms of query results.
> The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example:
> http://localhost:8983/solr/select/html?q=usage&transform=my.xsl
> In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format.
> Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far.
> The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already.
> The patch is all new files, except for adding this in web.xml before the first <servlet>:
> <filter>
> <filter-name>xslt</filter-name>
> <filter-class>org.apache.solr.xslt.XSLTServletFilter</filter-class>
> </filter>
> <!-- apply the XSLT filter when select/html is used to make queries -->
> <filter-mapping>
> <filter-name>xslt</filter-name>
> <url-pattern>/select/html/*</url-pattern>
> </filter-mapping>
> I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-49) PATCH: XSLTServletFilter
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SOLR-49?page=all ]
Bertrand Delacretaz updated SOLR-49:
------------------------------------
Attachment: xslt-filter-files.tar.gz
New files
> PATCH: XSLTServletFilter
> ------------------------
>
> Key: SOLR-49
> URL: http://issues.apache.org/jira/browse/SOLR-49
> Project: Solr
> Issue Type: New Feature
> Components: search
> Environment: Tested on macosx 10.4.7, JDK 1.5.0_06
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: xslt-filter-files.tar.gz
>
>
> Patch that implements server-side XSLT transforms of query results.
> The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example:
> http://localhost:8983/solr/select/html?q=usage&transform=my.xsl
> In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format.
> Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far.
> The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already.
> The patch is all new files, except for adding this in web.xml before the first <servlet>:
> <filter>
> <filter-name>xslt</filter-name>
> <filter-class>org.apache.solr.xslt.XSLTServletFilter</filter-class>
> </filter>
> <!-- apply the XSLT filter when select/html is used to make queries -->
> <filter-mapping>
> <filter-name>xslt</filter-name>
> <url-pattern>/select/html/*</url-pattern>
> </filter-mapping>
> I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Yonik Seeley <yo...@apache.org>.
On 9/21/06, Yonik Seeley <yo...@apache.org> wrote:
> On 9/21/06, Chris Hostetter <ho...@fucit.org> wrote:
> > : > ...What do people think about a "Map getContext()" for a
> > : > SolrQueryRequest? It could be instantiated on-demand to avoid any
> > : > penalty for those not using it...
> > :
> > : This would be useful in my case.
> >
> > no objections ...
>
> OK, I'll add it. I'd resist if I thought it was *only* for this xslt
> case, but I think it will be used for other things in the future.
OK, it's been added as SolrQueryRequest.getContext() : Map<Object,Object>
Ink isn't dry... feel free to suggest or make changes.
-Yonik
Re: Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Yonik Seeley <yo...@apache.org>.
On 9/21/06, Chris Hostetter <ho...@fucit.org> wrote:
> : > ...What do people think about a "Map getContext()" for a
> : > SolrQueryRequest? It could be instantiated on-demand to avoid any
> : > penalty for those not using it...
> :
> : This would be useful in my case.
>
> no objections ...
OK, I'll add it. I'd resist if I thought it was *only* for this xslt
case, but I think it will be used for other things in the future.
-Yonik
Re: Re: Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 9/21/06, Chris Hostetter <ho...@fucit.org> wrote:
> ...for the getContentType it could apply the
> transformation to an arbitrary constant snippet of XML since all we care
> about is the media type...
It wouldn't even need to apply the transformation, once the XSLT is
parsed, Transformer.getOutputProperty(...) can be used to get the
media-type.
But, as Yonik says, the context Map thingy will probably have other
uses, so it's a better solution.
-Bertrand
Re: Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Chris Hostetter <ho...@fucit.org>.
: > ...What do people think about a "Map getContext()" for a
: > SolrQueryRequest? It could be instantiated on-demand to avoid any
: > penalty for those not using it...
:
: This would be useful in my case.
no objections ... the other thought that occured to me for this specific
case is that both the write method and the getContentType method could
fetch seperate Transform instances, and apply those transformations
independently -- in the case of write, it would apply the Transformation
as it currently does, but for the getContentType it could apply the
transformation to an arbitrary constant snippet of XML since all we care
about is the media type.
It's a big hack ... but it would be a way to work arround hte lack of
state if there was some reason adding state was prohibitively hard.
-Hoss
Re: Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 9/21/06, Yonik Seeley <yo...@apache.org> wrote:
> ...the javadoc says that Transformer isn't
> thread-safe...
Ok, I'll need to change my code anyway then, as currently I'm reusing
Transformer objects.
> ...What do people think about a "Map getContext()" for a
> SolrQueryRequest? It could be instantiated on-demand to avoid any
> penalty for those not using it...
This would be useful in my case.
-Bertrand
Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Yonik Seeley <yo...@apache.org>.
On 9/21/06, Bertrand Delacretaz <bd...@apache.org> wrote:
> On 9/21/06, Yonik Seeley <yo...@apache.org> wrote:
> > On 9/20/06, Chris Hostetter <ho...@fucit.org> wrote:
> > > ...isn't that what the "media-type" attribute of <xsl:output/> is for?
> >
> > Is it somehow possible to grab that and return it from
> > RequestHandler.getContentType()?...
>
> Yes, it works, thanks for the idea!
>
> But this means that, in my XSLTResponseWriter, the Transformer object
> has to be available in both the getContentType(...) and write(...)
> methods.
>
> What's the recommended way of storing the Transformer object so that
> both methods can use it, in a threadsafe way? With plain Servlet
> interfaces, I'd store it in a ServletRequest attribute.
We haven't had to yet :-)
I was going to suggest to just use your TransformerProvider
(transformer cache). But, the javadoc says that Transformer isn't
thread-safe.
One hackish way would be to keep the Transformer in a thread local.
But, it does seem like it could be useful to have a "context" or a way
of associating more info/objects with a particular request.
What do people think about a "Map getContext()" for a
SolrQueryRequest? It could be instantiated on-demand to avoid any
penalty for those not using it.
-Yonik
Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 9/21/06, Yonik Seeley <yo...@apache.org> wrote:
> On 9/20/06, Chris Hostetter <ho...@fucit.org> wrote:
> > ...isn't that what the "media-type" attribute of <xsl:output/> is for?
>
> Is it somehow possible to grab that and return it from
> RequestHandler.getContentType()?...
Yes, it works, thanks for the idea!
But this means that, in my XSLTResponseWriter, the Transformer object
has to be available in both the getContentType(...) and write(...)
methods.
What's the recommended way of storing the Transformer object so that
both methods can use it, in a threadsafe way? With plain Servlet
interfaces, I'd store it in a ServletRequest attribute.
Is there something like request attributes in SolrQueryRequest or
SolrQueryResponse, which can be used to share context between the
various objects processing a request, without influencing the
response?
-Bertrand
Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Yonik Seeley <yo...@apache.org>.
On 9/20/06, Chris Hostetter <ho...@fucit.org> wrote:
> : The content-type should also be selectable by a request parameter, with
> : text/html as the default I guess.
>
> isn't that what the "media-type" attribute of <xsl:output/> is for?
Is it somehow possible to grab that and return it from
RequestHandler.getContentType()?
-Yonik
Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Chris Hostetter <ho...@fucit.org>.
: The content-type should also be selectable by a request parameter, with
: text/html as the default I guess.
isn't that what the "media-type" attribute of <xsl:output/> is for?
-Hoss
[jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SOLR-49?page=comments#action_12436135 ]
Bertrand Delacretaz commented on SOLR-49:
-----------------------------------------
In retrospect I think a different response writer is more consistent with the way other output formats are generated, shouldn't be hard to implement that way.
The content-type should also be selectable by a request parameter, with text/html as the default I guess.
> PATCH: XSLTServletFilter
> ------------------------
>
> Key: SOLR-49
> URL: http://issues.apache.org/jira/browse/SOLR-49
> Project: Solr
> Issue Type: New Feature
> Components: search
> Environment: Tested on macosx 10.4.7, JDK 1.5.0_06
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: xslt-filter-files.tar.gz
>
>
> Patch that implements server-side XSLT transforms of query results.
> The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example:
> http://localhost:8983/solr/select/html?q=usage&transform=my.xsl
> In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format.
> Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far.
> The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already.
> The patch is all new files, except for adding this in web.xml before the first <servlet>:
> <filter>
> <filter-name>xslt</filter-name>
> <filter-class>org.apache.solr.xslt.XSLTServletFilter</filter-class>
> </filter>
> <!-- apply the XSLT filter when select/html is used to make queries -->
> <filter-mapping>
> <filter-name>xslt</filter-name>
> <url-pattern>/select/html/*</url-pattern>
> </filter-mapping>
> I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Resolved: (SOLR-49) PATCH: XSLTServletFilter
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/18/06, Chris Hostetter <ho...@fucit.org> wrote:
> ...Would you like to do the honors of writing up some wiki docs about the new
> Writer?...
sure, will do that tomorrow or Friday.
-Bertrand
Re: [jira] Resolved: (SOLR-49) PATCH: XSLTServletFilter
Posted by Chris Hostetter <ho...@fucit.org>.
: Thanks again Bertrand.
Would you like to do the honors of writing up some wiki docs about the new
Writer?
-Hoss
[jira] Resolved: (SOLR-49) PATCH: XSLTServletFilter
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SOLR-49?page=all ]
Hoss Man resolved SOLR-49.
--------------------------
Resolution: Fixed
Commited with both the subdirectory change and the rename to "example.xsl"
Thanks again Bertrand.
> PATCH: XSLTServletFilter
> ------------------------
>
> Key: SOLR-49
> URL: http://issues.apache.org/jira/browse/SOLR-49
> Project: Solr
> Issue Type: New Feature
> Components: search
> Environment: Tested on macosx 10.4.7, JDK 1.5.0_06
> Reporter: Bertrand Delacretaz
> Assigned To: Hoss Man
> Priority: Minor
> Attachments: SOLR-49.diff, solr-XSLTResponseWriter-20060922.tar.gz, solr-XSLTResponseWriter-20061016.tar.gz, solr-XSLTResponseWriter-files.tar.gz, xslt-filter-files.tar.gz
>
>
> Patch that implements server-side XSLT transforms of query results.
> The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example:
> http://localhost:8983/solr/select/html?q=usage&transform=my.xsl
> In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format.
> Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far.
> The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already.
> The patch is all new files, except for adding this in web.xml before the first <servlet>:
> <filter>
> <filter-name>xslt</filter-name>
> <filter-class>org.apache.solr.xslt.XSLTServletFilter</filter-class>
> </filter>
> <!-- apply the XSLT filter when select/html is used to make queries -->
> <filter-mapping>
> <filter-name>xslt</filter-name>
> <url-pattern>/select/html/*</url-pattern>
> </filter-mapping>
> I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-49) PATCH: XSLTServletFilter
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SOLR-49?page=all ]
Bertrand Delacretaz updated SOLR-49:
------------------------------------
Attachment: solr-XSLTResponseWriter-20061016.tar.gz
Here's the latest incarnation, using a more Solrish way of initializing the response writer.
The solr-XSLTResponseWriter-20061016.tar.gz attachment replaces all the previous patches.
I have added an init(NamedList args) method to the QueryResponseWriter (solr-49.patch in the attached file), which means that the solrconfig.xml part has changed:
<!--
XSLT response writer (SOLR-49)
Changes to XSLT transforms are taken into account every xsltCacheLifetimeSeconds at most.
-->
<queryResponseWriter
name="xslt"
class="org.apache.solr.request.XSLTResponseWriter"
>
<int name="xsltCacheLifetimeSeconds">5</int>
</queryResponseWriter>
Apart from that, the patch works as indicated in my previous comment.
> PATCH: XSLTServletFilter
> ------------------------
>
> Key: SOLR-49
> URL: http://issues.apache.org/jira/browse/SOLR-49
> Project: Solr
> Issue Type: New Feature
> Components: search
> Environment: Tested on macosx 10.4.7, JDK 1.5.0_06
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: solr-XSLTResponseWriter-20060922.tar.gz, solr-XSLTResponseWriter-20061016.tar.gz, solr-XSLTResponseWriter-files.tar.gz, xslt-filter-files.tar.gz
>
>
> Patch that implements server-side XSLT transforms of query results.
> The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example:
> http://localhost:8983/solr/select/html?q=usage&transform=my.xsl
> In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format.
> Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far.
> The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already.
> The patch is all new files, except for adding this in web.xml before the first <servlet>:
> <filter>
> <filter-name>xslt</filter-name>
> <filter-class>org.apache.solr.xslt.XSLTServletFilter</filter-class>
> </filter>
> <!-- apply the XSLT filter when select/html is used to make queries -->
> <filter-mapping>
> <filter-name>xslt</filter-name>
> <url-pattern>/select/html/*</url-pattern>
> </filter-mapping>
> I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SOLR-49?page=comments#action_12443761 ]
Bertrand Delacretaz commented on SOLR-49:
-----------------------------------------
Thanks for committing, I have documented this at http://wiki.apache.org/solr/XsltResponseWriter
> PATCH: XSLTServletFilter
> ------------------------
>
> Key: SOLR-49
> URL: http://issues.apache.org/jira/browse/SOLR-49
> Project: Solr
> Issue Type: New Feature
> Components: search
> Environment: Tested on macosx 10.4.7, JDK 1.5.0_06
> Reporter: Bertrand Delacretaz
> Assigned To: Hoss Man
> Priority: Minor
> Attachments: SOLR-49.diff, solr-XSLTResponseWriter-20060922.tar.gz, solr-XSLTResponseWriter-20061016.tar.gz, solr-XSLTResponseWriter-files.tar.gz, xslt-filter-files.tar.gz
>
>
> Patch that implements server-side XSLT transforms of query results.
> The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example:
> http://localhost:8983/solr/select/html?q=usage&transform=my.xsl
> In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format.
> Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far.
> The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already.
> The patch is all new files, except for adding this in web.xml before the first <servlet>:
> <filter>
> <filter-name>xslt</filter-name>
> <filter-class>org.apache.solr.xslt.XSLTServletFilter</filter-class>
> </filter>
> <!-- apply the XSLT filter when select/html is used to make queries -->
> <filter-mapping>
> <filter-name>xslt</filter-name>
> <url-pattern>/select/html/*</url-pattern>
> </filter-mapping>
> I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (SOLR-49) PATCH: XSLTServletFilter
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SOLR-49?page=all ]
Hoss Man reassigned SOLR-49:
----------------------------
Assignee: Hoss Man
> PATCH: XSLTServletFilter
> ------------------------
>
> Key: SOLR-49
> URL: http://issues.apache.org/jira/browse/SOLR-49
> Project: Solr
> Issue Type: New Feature
> Components: search
> Environment: Tested on macosx 10.4.7, JDK 1.5.0_06
> Reporter: Bertrand Delacretaz
> Assigned To: Hoss Man
> Priority: Minor
> Attachments: solr-XSLTResponseWriter-20060922.tar.gz, solr-XSLTResponseWriter-20061016.tar.gz, solr-XSLTResponseWriter-files.tar.gz, xslt-filter-files.tar.gz
>
>
> Patch that implements server-side XSLT transforms of query results.
> The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example:
> http://localhost:8983/solr/select/html?q=usage&transform=my.xsl
> In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format.
> Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far.
> The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already.
> The patch is all new files, except for adding this in web.xml before the first <servlet>:
> <filter>
> <filter-name>xslt</filter-name>
> <filter-class>org.apache.solr.xslt.XSLTServletFilter</filter-class>
> </filter>
> <!-- apply the XSLT filter when select/html is used to make queries -->
> <filter-mapping>
> <filter-name>xslt</filter-name>
> <url-pattern>/select/html/*</url-pattern>
> </filter-mapping>
> I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Chris Hostetter <ho...@fucit.org>.
: OTOH, forcing the XSLT files to be under conf/xslt would avoid
: cluttering the conf directory, I think it's a good idea.
yeah .. the clutter issue alone seems to make it a worthwhile restriction.
: You mean that the filename gives this impression, right? No problem with
correct.
: a rename, example.xsl is fine, or maybe xslt-writer-example.xsl.
I figure "example.xsl" is a more general description of it's purpose -- it
could be reused completley externally from the XSLTOutputWriter (ie: if we
fix the way the stylesheet param works in the XMLOutputWriter)
I'll commit with these changes once i get to work.
-Hoss
[jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SOLR-49?page=comments#action_12443196 ]
Bertrand Delacretaz commented on SOLR-49:
-----------------------------------------
I'm with Yonik on the security thing, Solr is wide open as is anyway.
OTOH, forcing the XSLT files to be under conf/xslt would avoid cluttering the conf directory, I think it's a good idea.
> query-to-html.xsl seems like it would render the "query" as html...
You mean that the filename gives this impression, right? No problem with a rename, example.xsl is fine, or maybe xslt-writer-example.xsl.
> PATCH: XSLTServletFilter
> ------------------------
>
> Key: SOLR-49
> URL: http://issues.apache.org/jira/browse/SOLR-49
> Project: Solr
> Issue Type: New Feature
> Components: search
> Environment: Tested on macosx 10.4.7, JDK 1.5.0_06
> Reporter: Bertrand Delacretaz
> Assigned To: Hoss Man
> Priority: Minor
> Attachments: SOLR-49.diff, solr-XSLTResponseWriter-20060922.tar.gz, solr-XSLTResponseWriter-20061016.tar.gz, solr-XSLTResponseWriter-files.tar.gz, xslt-filter-files.tar.gz
>
>
> Patch that implements server-side XSLT transforms of query results.
> The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example:
> http://localhost:8983/solr/select/html?q=usage&transform=my.xsl
> In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format.
> Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far.
> The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already.
> The patch is all new files, except for adding this in web.xml before the first <servlet>:
> <filter>
> <filter-name>xslt</filter-name>
> <filter-class>org.apache.solr.xslt.XSLTServletFilter</filter-class>
> </filter>
> <!-- apply the XSLT filter when select/html is used to make queries -->
> <filter-mapping>
> <filter-name>xslt</filter-name>
> <url-pattern>/select/html/*</url-pattern>
> </filter-mapping>
> I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SOLR-49?page=comments#action_12442978 ]
Hoss Man commented on SOLR-49:
------------------------------
I'm going to try and review this again today.
> PATCH: XSLTServletFilter
> ------------------------
>
> Key: SOLR-49
> URL: http://issues.apache.org/jira/browse/SOLR-49
> Project: Solr
> Issue Type: New Feature
> Components: search
> Environment: Tested on macosx 10.4.7, JDK 1.5.0_06
> Reporter: Bertrand Delacretaz
> Assigned To: Hoss Man
> Priority: Minor
> Attachments: solr-XSLTResponseWriter-20060922.tar.gz, solr-XSLTResponseWriter-20061016.tar.gz, solr-XSLTResponseWriter-files.tar.gz, xslt-filter-files.tar.gz
>
>
> Patch that implements server-side XSLT transforms of query results.
> The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example:
> http://localhost:8983/solr/select/html?q=usage&transform=my.xsl
> In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format.
> Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far.
> The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already.
> The patch is all new files, except for adding this in web.xml before the first <servlet>:
> <filter>
> <filter-name>xslt</filter-name>
> <filter-class>org.apache.solr.xslt.XSLTServletFilter</filter-class>
> </filter>
> <!-- apply the XSLT filter when select/html is used to make queries -->
> <filter-mapping>
> <filter-name>xslt</filter-name>
> <url-pattern>/select/html/*</url-pattern>
> </filter-mapping>
> I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 9/20/06, Yonik Seeley <yo...@apache.org> wrote:
> ...Done carefully, optional components won't be loaded into the JVM...
But still, the bloat also happens in the source code - it might be
good to separate between "core" and "icing on the cake" code, in the
source code tree.
-Bertrand
Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Yonik Seeley <yo...@apache.org>.
On 9/19/06, Chris Hostetter <ho...@fucit.org> wrote:
> i just worry that as Solr grows and
> we get more OutputWriters and RequestHandlers we're going to want to have
> a limited number of "core plugins" that ship out of hte box, and a jar of
> additional plugins that people can use if they want, but don't need loaded
> into the JVM by people who don't care
Done carefully, optional components won't be loaded into the JVM.
Handlers, response writers, or filters not referenced by the
solrconfig.xml or schema.xml fall into this category.
-Yonik
Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Chris Hostetter <ho...@fucit.org>.
: How far is Solr from what Hoss described below - single solr.war with
: multiple instances/collections/indices?
: I know it has been discussed in the past, but I don't recall anything
: after that.
It's already possible to do this with solr out of the box using tomcat...
http://wiki.apache.org/solr/SolrTomcat (scroll down)
...i'm 90% sure the same is possible using "JettyPlus" but i haven't
confirmed that.
The only other hitch is being able to load custom "plugins" (request
handlers, output writers, analzyers, etc) that are in your own jar files
(outside of the war) by configuring the servlet container to add to the
built in classpath ... again, it should be possible right now, it's just a
question of what containers support it and how.
-Hoss
Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Hi,
How far is Solr from what Hoss described below - single solr.war with multiple instances/collections/indices?
I know it has been discussed in the past, but I don't recall anything after that.
Thanks,
Otis
----- Original Message ----
From: Chris Hostetter <ho...@fucit.org>
To: solr-dev@lucene.apache.org
Sent: Wednesday, September 20, 2006 5:56:17 PM
Subject: Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
: > ...but is there anyway to let
: > people add web.xml for things like ServletFilters without manully
: > unpacking and modifyng hte war?..
:
: The way we handle that in Cocoon 2.1.x is with ant tasks which patch
: web.xml (and other similar things) at build time, based on options
: coming from properties files. The default build properties are stored
: in Subversion, and user-specified build properties can override these,
: coming from a file that is ignored by Subversion, to select options.
:
: This works well, but the build becomes a bit messy with many options.
yeah ... unfortunately it would require differnetly configured instances
to have separe physical war files ... the holy grail that we've discussed
in the past is being able to support a limitless number of Solr instances
using uniquely named contexts all pointing at a wingle instance of the
solr.war
-Hoss
Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Chris Hostetter <ho...@fucit.org>.
: > ...but is there anyway to let
: > people add web.xml for things like ServletFilters without manully
: > unpacking and modifyng hte war?..
:
: The way we handle that in Cocoon 2.1.x is with ant tasks which patch
: web.xml (and other similar things) at build time, based on options
: coming from properties files. The default build properties are stored
: in Subversion, and user-specified build properties can override these,
: coming from a file that is ignored by Subversion, to select options.
:
: This works well, but the build becomes a bit messy with many options.
yeah ... unfortunately it would require differnetly configured instances
to have separe physical war files ... the holy grail that we've discussed
in the past is being able to support a limitless number of Solr instances
using uniquely named contexts all pointing at a wingle instance of the
solr.war
-Hoss
Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 9/19/06, Chris Hostetter <ho...@fucit.org> wrote:
> ...1) it shouldn't be /select/html ... select/xslt or something, but there's
> no reason to assume the output of the XSLT would be html..
Right, and as Yonik suggests it probably makes more sense to create a
new QueryResponseWriter for this. The Content-Type can then be
selected by a request parameter, with text/html as the default?
> ...but is there anyway to let
> people add web.xml for things like ServletFilters without manully
> unpacking and modifyng hte war?..
The way we handle that in Cocoon 2.1.x is with ant tasks which patch
web.xml (and other similar things) at build time, based on options
coming from properties files. The default build properties are stored
in Subversion, and user-specified build properties can override these,
coming from a file that is ignored by Subversion, to select options.
This works well, but the build becomes a bit messy with many options.
Anyway, if server-side XSLT becomes a QueryResponseWriter, this won't
be needed right now.
> ...if there is, we should look into it for stuff like this, and now is a
> good time to start...
The first step might be to create a "contrib" source directory for
that kind of stuff, compile that into a separate jar that is
optionally included in the generated war, based on build-time
properties?
> ...if not, then we need to be cautious about not bloating Solr -- but the
> functionality of this patch seems to be worthwhile...
100% agreed on not bloating Solr, its beauty is that it does one thing
and one thing well.
That being said, I need to make it easier to build a self-contained
demo (including user-specified search forms and HTML-formatted
results) for my current project - I'll work on that and submit patches
which can be refined once an add-on mechanism is in place.
-Bertrand
Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by Chris Hostetter <ho...@fucit.org>.
: Thanks Bertrand, I've not used servlet filters before.
:
: What do people think the tradeoffs are of using a different url
: "/select/html" vs a different response writer "wt=html&wt.xslt=..." ?
1) it shouldn't be /select/html ... select/xslt or something, but there's
no reason to assume the output of the XSLT would be html
2) in spirit, i like hte idea of supporting both client site XSLT (with
the current XMLOutputWriter and some improved handling of hte stylesheet
param) and server side XSLT (wiht something like this patch) ... but i'm a
little leary of "overfilling the toolbox" with features.
this is nothing against this patch ... i just worry that as Solr grows and
we get more OutputWriters and RequestHandlers we're going to want to have
a limited number of "core plugins" that ship out of hte box, and a jar of
additional plugins that people can use if they want, but don't need loaded
into the JVM by people who don't care (much the way lucene has language
specific analyzers in a contrib module -- having an OutputWriter that
generates tab delimited results, or a ServletFilter that trims whitespace
are all usefull features, but shouldn't neccessarily be in the core)
with most things, putting them in a seperate JAR and having good
instructions on loading them into Solr's classpath for various
ServletContainers would probably be fine -- but is there anyway to let
people add web.xml for things like ServletFilters without manully
unpacking and modifyng hte war?
...if there is, we should look into it for stuff like this, and now is a
good time to start.
...if not, then we need to be cautious about not bloating Solr -- but the
functionality of this patch seems to be worthwhile.
-Hoss
[jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SOLR-49?page=comments#action_12435553 ]
Yonik Seeley commented on SOLR-49:
----------------------------------
Thanks Bertrand, I've not used servlet filters before.
What do people think the tradeoffs are of using a different url "/select/html" vs a different response writer "wt=html&wt.xslt=..."
?
Anyone else have opinions on if this should be committed?
> PATCH: XSLTServletFilter
> ------------------------
>
> Key: SOLR-49
> URL: http://issues.apache.org/jira/browse/SOLR-49
> Project: Solr
> Issue Type: New Feature
> Components: search
> Environment: Tested on macosx 10.4.7, JDK 1.5.0_06
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: xslt-filter-files.tar.gz
>
>
> Patch that implements server-side XSLT transforms of query results.
> The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example:
> http://localhost:8983/solr/select/html?q=usage&transform=my.xsl
> In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format.
> Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far.
> The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already.
> The patch is all new files, except for adding this in web.xml before the first <servlet>:
> <filter>
> <filter-name>xslt</filter-name>
> <filter-class>org.apache.solr.xslt.XSLTServletFilter</filter-class>
> </filter>
> <!-- apply the XSLT filter when select/html is used to make queries -->
> <filter-mapping>
> <filter-name>xslt</filter-name>
> <url-pattern>/select/html/*</url-pattern>
> </filter-mapping>
> I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-49) PATCH: XSLTServletFilter
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SOLR-49?page=all ]
Bertrand Delacretaz updated SOLR-49:
------------------------------------
Attachment: solr-XSLTResponseWriter-files.tar.gz
Here's a new patch, I've reworked the code into an XSLTResponseWriter.
Must be configured like this in solrconfig.xml:
<queryResponseWriter name="xslt" class="org.apache.solr.request.XSLTResponseWriter"/>
And the following request parameters activate it:
wt = xslt
tr = my-xslt-transform.xsl
ct = text/html (which is the default value)
(don't you love terse param names ;-)
The XSLT transform is read using SolrConfig.config.openResource(...), so it must be available in the solr/conf directory when running the Solr example config.
> PATCH: XSLTServletFilter
> ------------------------
>
> Key: SOLR-49
> URL: http://issues.apache.org/jira/browse/SOLR-49
> Project: Solr
> Issue Type: New Feature
> Components: search
> Environment: Tested on macosx 10.4.7, JDK 1.5.0_06
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: solr-XSLTResponseWriter-files.tar.gz, xslt-filter-files.tar.gz
>
>
> Patch that implements server-side XSLT transforms of query results.
> The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example:
> http://localhost:8983/solr/select/html?q=usage&transform=my.xsl
> In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format.
> Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far.
> The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already.
> The patch is all new files, except for adding this in web.xml before the first <servlet>:
> <filter>
> <filter-name>xslt</filter-name>
> <filter-class>org.apache.solr.xslt.XSLTServletFilter</filter-class>
> </filter>
> <!-- apply the XSLT filter when select/html is used to make queries -->
> <filter-mapping>
> <filter-name>xslt</filter-name>
> <url-pattern>/select/html/*</url-pattern>
> </filter-mapping>
> I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SOLR-49?page=comments#action_12443085 ]
Yonik Seeley commented on SOLR-49:
----------------------------------
> right now this can be used to expose any file in the ${solr.home}/conf by trying to use it as an XSLT
It's good that you noted it, but I think it's fine for now:
- conf doesn't contain personal data like logs could...
- Solr is a backend system with all the doors left wide open... IMO, locking a window isn't currently worth the effort, esp if it makes it harder to use.
> PATCH: XSLTServletFilter
> ------------------------
>
> Key: SOLR-49
> URL: http://issues.apache.org/jira/browse/SOLR-49
> Project: Solr
> Issue Type: New Feature
> Components: search
> Environment: Tested on macosx 10.4.7, JDK 1.5.0_06
> Reporter: Bertrand Delacretaz
> Assigned To: Hoss Man
> Priority: Minor
> Attachments: SOLR-49.diff, solr-XSLTResponseWriter-20060922.tar.gz, solr-XSLTResponseWriter-20061016.tar.gz, solr-XSLTResponseWriter-files.tar.gz, xslt-filter-files.tar.gz
>
>
> Patch that implements server-side XSLT transforms of query results.
> The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example:
> http://localhost:8983/solr/select/html?q=usage&transform=my.xsl
> In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format.
> Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far.
> The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already.
> The patch is all new files, except for adding this in web.xml before the first <servlet>:
> <filter>
> <filter-name>xslt</filter-name>
> <filter-class>org.apache.solr.xslt.XSLTServletFilter</filter-class>
> </filter>
> <!-- apply the XSLT filter when select/html is used to make queries -->
> <filter-mapping>
> <filter-name>xslt</filter-name>
> <url-pattern>/select/html/*</url-pattern>
> </filter-mapping>
> I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira