Hi Nick, On 7 May 2014, at 12:48, Nick Burch <apa...@gagravarr.org> wrote:
> Hi All > > One for our JAXRS gurus here… OK, not a guru here but I have a hunch. > At ApacheCon, we came up with the idea of having a welcome page on the Tika > Server, so that we could point people to it to try Tika, and let them > discover what it offered. Based on that, and the mailing list discussions, we > raised TIKA-1269. > > (Related to that is TIKA-1270, which aims to add endpoints similar to the > --list- ones the Tika CLI has, which is in progress) > > While we work out the best way to allow users to discover + learn about + try > the various REST endpoints on TIKA-1269, I've started with something basic. > This is done with the simple TikaWelcome class, which has a Path of / > > The problem - when the MetadataEP and UnpackerResource are enabled, it > doesn't work! With those to there, when you request / you get a 404 and the > server logs: > rg.apache.cxf.jaxrs.utils.JAXRSUtils findTargetMethod > WARNING: No operation matching request path "/" is found, Relative Path: /, > HTTP Method: GET, ContentType: */*, Accept: */*,. Please enable FINE/TRACE > log level for more details. > > However, if you comment out those two endpoint classes from the > sf.setResourceClasses() call in TikaServerCLI, then the request gets > correctly routed to the welcome page. > > Neither MetadataEP nor UnpackerResource have a path that clashes, so I've no > idea why having them active stops / working. Any ideas? I am having a look quickly whilst traveling but from peeking at the code it looks like the following to me: * MetadataEP - we have no @Produces which will fail in the introspection code on the TikaWelcome class * UnpackerResource - as there is no class level @Path I am suspecting this is clashing with the TikaWelcome as it builds the routes with the method ones being place on the root as well. I don’t have time to test it just now but I wonder what would happen if you reordered TikaWelcome to the top about UnpackerResource? If my hunch is correct it should make the / request work using the self-generated documentation. > (Patch below if you want to try disabling them yourself to investigate) > > Nick > Cheers, Dave
