You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "A B (JIRA)" <de...@db.apache.org> on 2005/11/03 01:04:56 UTC
[jira] Updated: (DERBY-675) Build-time processing of "metadata.properties" file handles slashes incorrectly.
[ http://issues.apache.org/jira/browse/DERBY-675?page=all ]
A B updated DERBY-675:
----------------------
Attachment: d675.patch
Attaching a patch to fix this issue. The "readLine" method in ODBCMetadataGenerator.java was treating single backslashes as "end-of-line" markers and hence was not recognizing escaped sequences like "\n". It turns out that the check for backslashes in that method is unnecessary, so this patch removes it. I ran the metadata.java and odbc_metadata.java tests with this patch and they ran okay, so I think it should be safe. I still want to run some more tests tonight, just to be sure, but I thought I'd post the patch now since it is affecting another developer's current work (Mamta's).
I will add another comment tomorrow indicating the full test results.
> Build-time processing of "metadata.properties" file handles slashes incorrectly.
> --------------------------------------------------------------------------------
>
> Key: DERBY-675
> URL: http://issues.apache.org/jira/browse/DERBY-675
> Project: Derby
> Type: Bug
> Components: Build tools
> Versions: 10.1.1.0, 10.2.0.0, 10.1.1.1
> Reporter: A B
> Assignee: A B
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: d675.patch
>
> As found and described by Mamta here:
> http://www.nabble.com/-Derby-573-Optimizer-overrides-and-metadata.properties-files-t460642.html
> During the ant build process, Derby's metadata.properties file is modified by the ODBCMetadataGenerator class and that class treats backslashes that occur in the metadata.properties file incorrectly. More specifically, it treats every backslash as the end of a line and thus will translate things like
> FROM --DERBY-PROPERTIES joinOrder=FIXED \\n \
> into
> FROM --DERBY-PROPERTIES joinOrder=FIXED \
> \
> n \
> (in other words, escaped characters like "\n" are handled incorrectly)..
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-675) Build-time processing of "metadata.properties"
file handles slashes incorrectly.
Posted by Army <qo...@sbcglobal.net>.
Daniel John Debrunner wrote:
> Would it be safer to use standard Java character reading classes, rather
> than inventing your own here?
>
> Use something like
>
> new LineNumberReader(new InputStreamReader(is, "ISO 8859-1"));
>
> since property files are defined to be that encoding?
I think there were two reasons why I created a readLine() method instead of
using an existing Java one: 1) because, for whatever reason, I thought that
backslashes needed special handling (and hence a standard Java "readLine()"
wouldn't have worked), and 2) there are some character-related operations that
have to be done (esp. right-side trimming to find the last non-whitespace
character) and I thought that it'd be cleaner to do that character processing
while reading, instead of getting a string and processing it character by character.
But now that reason #1 is void and since reason #2 isn't really much of a
reason, Yes, it would be safer to use standarad Java character reading classes.
I'll make that change and post a patch soon.
Army
Re: [jira] Updated: (DERBY-675) Build-time processing of "metadata.properties"
file handles slashes incorrectly.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
A B (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-675?page=all ]
>
> A B updated DERBY-675:
> ----------------------
>
> Attachment: d675.patch
>
> Attaching a patch to fix this issue. The "readLine" method in ODBCMetadataGenerator.java was treating single backslashes as "end-of-line" markers and hence was not recognizing escaped sequences like "\n". It turns out that the check for backslashes in that method is unnecessary, so this patch removes it. I ran the metadata.java and odbc_metadata.java tests with this patch and they ran okay, so I think it should be safe. I still want to run some more tests tonight, just to be sure, but I thought I'd post the patch now since it is affecting another developer's current work (Mamta's).
>
Would it be safer to use standard Java character reading classes, rather
than inventing your own here?
Use something like
new LineNumberReader(new InputStreamReader(is, "ISO 8859-1"));
since property files are defined to be that encoding?
Dan.