[
https://issues.apache.org/jira/browse/TIKA-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Giovanni De Stefano updated TIKA-3362:
--------------------------------------
Description:
All calls to *RecursiveMetadataResource.parseMetadata* have *text* hardcoded
as *handlerTypeName* while it should be dynamic.
*AsyncParser* worker threads process *FetchEmitTuple* objects asynchronously
and by then the http headers are not available. An idea to make the
*handlerTypeName* dynamic could be to add it to the configuration of the
emitter (so directly into *FetchEmitTuple*).
*EmitterResource* on the other hand, could take the *handlerTypeName* as
*PathParam* (just as it is in *TikeResource*).
What do you think about this reasoning? If this is acceptable I could work on
PR :)
was:All calls to *RecursiveMetadataResource.parseMetadata* have *text*
hardcoded as *handlerTypeName* while it should be dynamic (perhaps taken from
*httpHeaders*).
> AsyncParser and EmitterResource have handler type hardcoded to text
> -------------------------------------------------------------------
>
> Key: TIKA-3362
> URL: https://issues.apache.org/jira/browse/TIKA-3362
> Project: Tika
> Issue Type: Bug
> Components: tika-pipes
> Affects Versions: 2.0.0
> Reporter: Giovanni De Stefano
> Priority: Major
>
> All calls to *RecursiveMetadataResource.parseMetadata* have *text* hardcoded
> as *handlerTypeName* while it should be dynamic.
> *AsyncParser* worker threads process *FetchEmitTuple* objects asynchronously
> and by then the http headers are not available. An idea to make the
> *handlerTypeName* dynamic could be to add it to the configuration of the
> emitter (so directly into *FetchEmitTuple*).
> *EmitterResource* on the other hand, could take the *handlerTypeName* as
> *PathParam* (just as it is in *TikeResource*).
> What do you think about this reasoning? If this is acceptable I could work on
> PR :)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
