Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Thu, 3 Mar 2016 15:46:18 +0000 (UTC)
From: "Uwe Schindler (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12946336.1456963216000.209353.1457019978058@Atlassian.JIRA>
In-Reply-To: <JIRA.12946336.1456963216000@Atlassian.JIRA>
References: <JIRA.12946336.1456963216000@Atlassian.JIRA>
 <JIRA.12946336.1456963216050@arcas>
Subject: [jira] [Commented] (SOLR-8778) Deprecate CSVStrategy's setters, and
 make its pre-configured strategies immutable
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Uwe Schindler commented on SOLR-8778:
-------------------------------------

+1 to fix this!

Ideally we should remove our CSV fork from Solr's repository! I tried to do that and cut over to the official release, but I gave up; see SOLR-3213. The commons-csv release is a total rewrite not having any overlap with our early fork in the internal package. The official release does not support most "hackish" stuff, introduced to spare allocations (which is no longer an issue in Java 8, we can do {{new CSV*()}} as often as we like, Hotspot optimizes that away). I think this stuff also is the reason for this issue, [~steve_rowe]?

So we should really upgrade to a better CSV parser (official commons-csv) and remove the "reuse" of instances in thread unsafe ways.

> Deprecate CSVStrategy's setters, and make its pre-configured strategies immutable
> ---------------------------------------------------------------------------------
>
>                 Key: SOLR-8778
>                 URL: https://issues.apache.org/jira/browse/SOLR-8778
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Steve Rowe
>         Attachments: SOLR-8778.patch
>
>
> Removing some deprecated things in CSVStrategy (SOLR-8764) exposed a bug: it's possible to redefine the public static {{CSVStrategy.\{DEFAULT,EXCEL,TDF}_STRATEGY}} strategies, simply by calling their setters.
> Right now that's happening in {{CSVParserTest.testUnicodeEscape()}}, where the default unicode escape interpretation is changed from false to true.  And then if that test happens to run before {{CSVStrategyTest.testSetCSVStrategy()}}, which tests that the unicode escape interpretation on the default strategy is set to false, then the latter will fail.
> Example failures: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16079/ and http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/3126/


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org