You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2019/03/21 14:57:00 UTC
[jira] [Comment Edited] (SOLR-13335) Upgrade to velocity 2.0 and
velocity-tools 3.0
[ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org