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

Hudson commented on TIKA-1689:
------------------------------

SUCCESS: Integrated in tika-trunk-jdk1.7 #800 (See 
[https://builds.apache.org/job/tika-trunk-jdk1.7/800/])
TIKA-1689: with mention in Changes.txt (tallison: 
http://svn.apache.org/viewvc/tika/trunk/?view=rev&rev=1692565)
* /tika/trunk/CHANGES.txt
TIKA-1689: revert mistakenly flipped sort order of parsers from r1677328 
(tallison: http://svn.apache.org/viewvc/tika/trunk/?view=rev&rev=1692564)
* 
/tika/trunk/tika-core/src/main/java/org/apache/tika/utils/ServiceLoaderUtils.java
* /tika/trunk/tika-parsers/src/test/java/org/apache/tika/utils
* 
/tika/trunk/tika-parsers/src/test/java/org/apache/tika/utils/ServiceLoaderUtilsTest.java


> Parser sort order change in TIKA-1517 breaks parser override capability
> -----------------------------------------------------------------------
>
>                 Key: TIKA-1689
>                 URL: https://issues.apache.org/jira/browse/TIKA-1689
>             Project: Tika
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.9
>            Reporter: David Warren
>            Priority: Blocker
>             Fix For: 1.10
>
>
> In Tika 1.9, the comparator used to sort parsers (in ServiceLoaderUtils) now 
> returns them in the reverse order from how they were returned in prior 
> versions, when the comparator was in DefaultParser.  This work was done under 
> TIKA-1517.
> This change broke one of our customizations in which we use our own parser 
> instead of Tika's HtmlParser to process html.  We use the service loader 
> logic (creating our own META-INF/services/org.apache.tika.parser.Parser file) 
> and rely on the order in which the list returned by 
> DefaultParser.getDefaultParsers() is evaluated.    Expecting that when Tika 
> builds the map of mime types to parsers it first puts in entries for 
> HtmlParser, then overwrites these with our custom parser.  
> I realize relying on this is brittle.  And I found a valid workaround to the 
> problem in Tika 1.9 is to blacklist HtmlParser.  However, in case this parser 
> ordering change was not intentional, I figured I'd mention it.



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

Reply via email to