[jira] Created: (SOLR-49) PATCH: XSLTServletFilter

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (SOLR-49) PATCH: XSLTServletFilter

Nick Burch (Jira)
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

       
Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (SOLR-49) PATCH: XSLTServletFilter

Nick Burch (Jira)
     [ 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

       
Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Nick Burch (Jira)
In reply to this post by Nick Burch (Jira)
    [ 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

       
Reply | Threaded
Open this post in threaded view
|

Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Chris Hostetter-3

: 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

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Nick Burch (Jira)
In reply to this post by Nick Burch (Jira)
    [ 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

       
Reply | Threaded
Open this post in threaded view
|

Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Bertrand Delacretaz
In reply to this post by Chris Hostetter-3
On 9/19/06, Chris Hostetter <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (SOLR-49) PATCH: XSLTServletFilter

Nick Burch (Jira)
In reply to this post by Nick Burch (Jira)
     [ 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

       
Reply | Threaded
Open this post in threaded view
|

Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Yonik Seeley-2
In reply to this post by Chris Hostetter-3
On 9/19/06, Chris Hostetter <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Bertrand Delacretaz
On 9/20/06, Yonik Seeley <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Chris Hostetter-3
In reply to this post by Nick Burch (Jira)

: 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

Reply | Threaded
Open this post in threaded view
|

Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Chris Hostetter-3
In reply to this post by Bertrand Delacretaz
: > ...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

Reply | Threaded
Open this post in threaded view
|

Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Yonik Seeley-2
In reply to this post by Chris Hostetter-3
On 9/20/06, Chris Hostetter <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Otis Gospodnetic-2
In reply to this post by Chris Hostetter-3
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 <[hidden email]>
To: [hidden email]
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




Reply | Threaded
Open this post in threaded view
|

Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Chris Hostetter-3

: 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

Reply | Threaded
Open this post in threaded view
|

Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Bertrand Delacretaz
In reply to this post by Yonik Seeley-2
On 9/21/06, Yonik Seeley <[hidden email]> wrote:
> On 9/20/06, Chris Hostetter <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Yonik Seeley-2
On 9/21/06, Bertrand Delacretaz <[hidden email]> wrote:

> On 9/21/06, Yonik Seeley <[hidden email]> wrote:
> > On 9/20/06, Chris Hostetter <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Bertrand Delacretaz
On 9/21/06, Yonik Seeley <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Chris Hostetter-3

: > ...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

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Yonik Seeley-2
On 9/21/06, Chris Hostetter <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: Re: [jira] Commented: (SOLR-49) PATCH: XSLTServletFilter

Bertrand Delacretaz
In reply to this post by Chris Hostetter-3
On 9/21/06, Chris Hostetter <[hidden email]> 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
12