[
https://issues.apache.org/jira/browse/VELOCITY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036262#comment-16036262
]
Claude Brisson commented on VELOCITY-880:
-----------------------------------------
I totally agree that getAsciiStream() is to be avoided, and I'd also say so
from getBinaryStream(). With getBinaryStream(), which is more targeted towards
BLOBs than CLOBs, you take the risk of exposing an internal database encoding
you're unaware of. The natural method is getCharacterStream(), and if it
doesn't work for a specific JDBC driver, it means the driver is broken. At the
minimum, we can have the getReader() be protected so that it can be subclassed.
But I totally agree that we should validate it against the widest number of db
vendors. Since some time ago I was implied in a wide DB benchmarking job, I do
also have access to the ones you name plus several others like PostgresQL, and
Vertica.
James, you say:
> The reason I use IOUtils to convert the Reader to an InputStream is that the
> base class method expects InpuStream.
This isn't true anymore for 2.0. I think the only needed change is to switch to
getCharacterStream().
> 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: project.tar.gz, 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
