[
https://issues.apache.org/jira/browse/TIKA-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240398#comment-13240398
]
Sergey Beryozkin edited comment on TIKA-593 at 3/28/12 1:56 PM:
----------------------------------------------------------------
Hi, here is the thread on the CXF list to do with handling 415:
http://cxf.547215.n5.nabble.com/TIKA-593-odd-behavior-related-to-CXF-JAX-RS-services-and-415-Http-response-codes-tt5600131.html.
Re Accept: I think that the client code needs to have an idea about the format
of the data it expects back thus CXF WebClient will try to set some specific
default. FYI, proxy-based clients will analyze @Produces/@Consumes. Also the
idea of the client having to know what it expects back is finding its way into
JAX-RS 2.0 client api too.
Update: WebClient (trunk/2.5.3-SNAPSHOT) will only default Accept to
application/xml if a specific custom class is expected to be populated on
return, if Response is expected back then no action is taken
was (Author: sergey_beryozkin):
Hi, here is the thread on the CXF list to do with handling 415:
http://cxf.547215.n5.nabble.com/TIKA-593-odd-behavior-related-to-CXF-JAX-RS-services-and-415-Http-response-codes-tt5600131.html.
Re Accept: I think that the client code needs to have an idea about the format
of the data it expects back thus CXF WebClient will try to set some specific
default. FYI, proxy-based clients will analyze @Produces/@Consumes. Also the
idea of the client having to know what it expects back is finding its way into
JAX-RS 2.0 client api too.
> Tika network server
> -------------------
>
> Key: TIKA-593
> URL: https://issues.apache.org/jira/browse/TIKA-593
> Project: Tika
> Issue Type: New Feature
> Components: general
> Affects Versions: 0.10
> Reporter: Jukka Zitting
> Assignee: Chris A. Mattmann
> Fix For: 1.2
>
> Attachments: TIKA-593.Mattmann.032612.patch.2.txt,
> TIKA-593.Mattmann.032612.patch.txt, TIKA-593.Mattmann.032712.patch.2.txt,
> TIKA-593.Mattmann.032712.patch.txt, TIKA-593_pom.diff
>
>
> It would be cool to be able to run Tika as a network service that accepts a
> binary document as input and produces the extracted content (as XHTML, text,
> or just metadata) as output. A bit like TIKA-169, but without the dependency
> to a servlet container.
> I'd like to be able to set up and run such a server like this:
> $ java -jar tika-app.jar --port 1234
> We should also add a NetworkParser class that acts as a local client for such
> a service. This way a lightweight client could use the full set of Tika
> parsing functionality even with just the tika-core jar within its classpath.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
