[
https://issues.apache.org/jira/browse/TIKA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849064#comment-16849064
]
Jonathan Essex commented on TIKA-2882:
--------------------------------------
Having gone down the route of hand-coding the multipart payload before, I'm
reluctant to do it that way.
I'll have a think about Apache HttpClient. But what if we followed the
precedent of ExternalParser in core and created
RemoteParser/RemoteParserFactory that will create instances of remote parsers
based on configuration?
That way objects in tika-parsers could get access to remote parser services
that are actually defined in tika-app or tika-server.
> Parsers should not include HTTP client code
> -------------------------------------------
>
> Key: TIKA-2882
> URL: https://issues.apache.org/jira/browse/TIKA-2882
> Project: Tika
> Issue Type: Improvement
> Components: parser
> Affects Versions: 1.21
> Reporter: Jonathan Essex
> Priority: Major
>
> Folks, does it really make sense for a parser to have a REST client built in?
> The GROBID and NLTKNERecogniser parsers use the apache CXF client directly.
>
> Since I don't use CXF and my entire app is built on a different JAX-RS stack
> this just dropped me straight into dependency hell.
> Surely it would make more sense to keep the parsers... well, parsers... and
> build support for delegating parsing to other services into some higher level
> in the stack (such as the server, where the CXF dependency is more benign).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
