[ 
https://issues.apache.org/jira/browse/VELOCITY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16013780#comment-16013780
 ] 

Michael Osipov commented on VELOCITY-880:
-----------------------------------------

The stuff looks weird. Why is {{#getAsciiStream()}} used at all? This is deemed 
to fail.
Now let's get to your patch: You are mixing several issues within one patch 
which do not belong there. Focus your patch on the problem of the issue. The 
last bullet should be handled separately handled. While I agree that I template 
has to be stored as CLOB, there might be usecases where VARCHAR is just fine. 
We should try to cover them all. As for your fix of the issue: Why do you turn 
a reader back to an input stream to obtain a reader again? That's pure 
nonsense. The best we can do for the current code is to throw the conversion 
crap out and use {{#getCharacterStream()}}. The database driver will do the 
magic for us. No more encoding issues.

> DataSourceResourceLoader corrupts UTF-8 encoded characters in template
> ----------------------------------------------------------------------
>
>                 Key: VELOCITY-880
>                 URL: https://issues.apache.org/jira/browse/VELOCITY-880
>             Project: Velocity
>          Issue Type: Bug
>    Affects Versions: 2.1.x
>         Environment: Oracle12c and HSQLDB 2.3.4, JDK 1.8
>            Reporter: James R Doyle
>         Attachments: velocity-880.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> A long-withstanding bug in the DataSourceResourceLoader corrupts UTF-8 
> templates retrieved from the database.  The Unit Test suite for this resource 
> loader has deficiencies that hide the bug. 
> The cause of the problem is this:
> {code}
>       InputStream rawStream = rs.getAsciiStream(templateColumn);
> The resolution of the problem is simply:
>       Reader r = rs.getCharacterStream(templateColumn);
>       InputStream rawStream = null;
>            try {
>                 rawStream = IOUtils.toInputStream(IOUtils.toString(r), 
> encoding);
>                 } catch (IOException ioe) {}
> {code}
> Once done, the test failure vanishes:
>         org.junit.ComparisonFailure: Unicode test failed.  
>         Expected :The Euro Currency Symbol € is a two-byte UTF-8 encoded 
> character.
>         Actual   :The Euro Currency Symbol ? is a two-byte UTF-8 encoded 
> character.
> The bug was verified and the fix was tested against Oracle12c and HSQLDB 
> 2.3.4 using a CLOB column to store the template data.
> The Unit Tests for this resource loader need attention.
> Please see VELOCITY-599 ; long standing problem, which has been erroneously 
> marked as resolved but has been in the codebase for a long time.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Reply via email to