lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: velocity response writer breaks portability
Date Thu, 17 Jun 2010 17:23:56 GMT

On Jun 17, 2010, at 1:07 PM, Chris Hostetter wrote:
> : I'm confused by that comment about XSLT.  How would using XSLT  
> client-side be
> : any more sure that the handlers are exposing everything?   All ya  
> gotta do
> : when using VrW is flip to wt=xml and you can then see everything  
> used to
> I'm horribly un-informed about Velocity and the VrW, but my  
> recollection
> from a previous discussion about this idea (i thought it was on  
> list, but
> it might have been an offline discussion at apachecon or a meetup) was
> that since the Velocity engine runs in the ServletContext, a template
> could use direct object refrences to access data that wouldn't be
> available to remote clients parsing the xml or json output -- ie: a  
> well
> intentioned but lazily written patch might get committed that uses a
> refrence to the SolrCore to get access to some data directly in a
> velocity template, rather then the more general solution of updating  
> hte
> appropriate request handler to add that data to the  
> SolrQueryResponse so
> that all response writers return that data.

You're sorta right.  It doesn't run in the ServletContext, though.  It  
simply passes the Solr request and response objects into a Velocity  
context (meaning these objects are available to do whatever you want  
with). And there are some other "tools" that get put in the context  
that allow HTML, URL, and other escaping, number formatting, etc.

Yes, the templates could reach out into any of these objects (but no  
others) and drill down to get information that wouldn't be presented  
in an XML response.  I don't see that as a negative though.  But  
certainly your point about it being able to present more than what XML  
could is valid.

> : generate the view.  The same HTML would come out either way.  With  
> XSLT, a
> : plugin couldn't bring in it's own .xsl file for the client to use  
> (at least
> : not currently, no way to serve a file from a JAR).  With  
> Velocity, .vm files
> i'm pretty sure that ResourceLoader will fall back to the  
> ClassLoader when
> trying to access files not found in the conf directory -- which means
> plugins should be able to include XSLT files in their jars, and  
> stylesheet
> urls like "/admin/file?custom-plugin-a.xsl" would work (we just need  
> to
> fix some foolish assumptions in the XmlResponseWriter's usage of the
> stylesheet param so it's more generally useful)

I don't think ShowFileRequestHandler does this.  It uses the File  
object and such.  I'd be surprised if it could, and it really should  
NOT be able to do that - that would allow one to serve up any files on  
the classpath, .class, etc.  I'd consider that a major hole.   The  
Velocity stuff doesn't work that way.  Templates are not servable to  
the client from the classpath.  But /admin/file could serve up *files*  
under /conf/velocity though - which is as designed and with a way to  
shut them off via excludes if desired.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message