[
https://issues.apache.org/jira/browse/SOLR-13335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798157#comment-16798157
]
Uwe Schindler edited comment on SOLR-13335 at 3/21/19 2:56 PM:
---------------------------------------------------------------
Hi Kevin,
according to Javadocs, you should not build your reader that way. To do it
correctly, the base class of ResoureLoader has a protected method that takes an
input stream and the encoding to build a reader. So actually after you have the
InputStream from our SolrResourceLoader, you should call: {{return
buildReader(reader, encoding);}} (see
[https://velocity.apache.org/engine/2.0/apidocs/org/apache/velocity/runtime/resource/loader/ResourceLoader.html#buildReader-java.io.InputStream-java.lang.String-])
The reason for that is: the parameter {{encoding}} might be {{null}}, and then
it will use the property passed in the Velocity runtime.
A good way to check how a ResourceLoader for velocity should be build is to
read its source code. I had similar problems the last time I touched Velocity.
The test suite is not so helpful, because it uses the special StringReader for
tests to pass in String-templates. In real life, it will load the files from
ResourceLoader, Maybe we should add a real test for this.
was (Author: thetaphi):
Hi Kevin,
according to Javadocs, you should not build your reader that way. To do it
correctly, the base class of ResoureLoader has a protected method that takes an
input stream and the encoding to build a reader. So actually after you have the
InputStream from our SolrResourceLoader, you should call: {{return
buildReader(reader, encoding);}} (see
[https://velocity.apache.org/engine/2.0/apidocs/org/apache/velocity/runtime/resource/loader/ResourceLoader.html#buildReader-java.io.InputStream-java.lang.String-])
> Upgrade to velocity 2.0 and velocity-tools 3.0
> ----------------------------------------------
>
> Key: SOLR-13335
> URL: https://issues.apache.org/jira/browse/SOLR-13335
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Kevin Risden
> Assignee: Kevin Risden
> Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-13335.patch, SOLR-13335.patch, SOLR-13335.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As part of looking to remove old commons-lang in SOLR-9079, found that
> velocity depends on it. Upgrading Velocity would allow completely removing
> commons-lang
> Copy some detail from SOLR-9079 investigation:
> * solr/contrib/velocity/ivy.xml doesn't even reference commons-lang
> * velocity 1.7 was released - 2010-11-29
> * LUCENE-5249 from 2013 was the last time velocity was changed in
> lucene/ivy-versions.properties
> * velocity-tools 2.0 has an optional dependency on commons-lang
> * velocity 1.7 has a hard dependency on commons-lang.
> Upgrading velocity 1.7 -> 2.0
> * http://velocity.apache.org/engine/2.0/upgrading.html
> * Change velocity to velocity-engine-core
> * upgrades commons-lang to commons-lang3
> So if we want to finish removing commons-lang, we need to upgrade velocity.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
