jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "frank (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3667) Possible regression with accepted content types when extracting and indexing binary values
Date Sun, 29 Sep 2013 03:43:24 GMT

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

frank commented on JCR-3667:
----------------------------

In the issue: JCR-3476, it says
This is unnecessarily expensive because the binary is fetched. Also an empty field is added
to the index document.

While Tika v1.4 solves a issue : TIKA-1133
In some cases it is beneficial to allow empty and duplicate Tika metadata values for multi-valued
XML elements like RDF bags.

Current Jackrabbit depends on Tika v1.3, how about upgrading Tika to version 1.4 and check
to see whether this problem solved or not?

> Possible regression with accepted content types when extracting and indexing binary values
> ------------------------------------------------------------------------------------------
>
>                 Key: JCR-3667
>                 URL: https://issues.apache.org/jira/browse/JCR-3667
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>    Affects Versions: 2.4.4
>            Reporter: C├ędric Damioli
>             Fix For: 2.4.5, 2.6.4, 2.7.2
>
>
> JCR-3476 introduced a mime-type test before parsing binary values, based on Tika's supported
parsers.
> This may lead to incorrect behaviours, with a "text/xml" not being extracted and indexed
because the XMLParser does not declare "text/xml" as a supported type.
> The problem here is that there is a regression between 2.4.3 and 2.4.4, because the same
content was previously well recognized by Tika's Detector and then extracted.
> Furthermore, it seems to me inconsistent on one hand to rely on the declared content
type and on the other hand to delegate the actual type detection to Tika ? 
> This may lead to cases where the jcr:mimeType value is set to eg. "application/pdf" but
detected and parsed by Tika as "text/plain" with no error.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message