Hi Tim, PR is ready. Set levels: MediaType.TEXT_PLAIN_TYPE, MediaType.APPLICATION_JSON_TYPE, MediaType.TEXT_HTML_TYPE, MediaType.TEXT_XML_TYPE Also, json became default because of the default compare mechanism. It is treating that extra path and path param as an important factor. It was causing issues, with my earlier implementation as well. So changed it with a commit (part of PR). And now pure priority is checked. If priority check also fails, then only default check (though, it will not happen, as one handler has only one produce type, and no chance of two methods producing same type).
Thanks and Regards, Subhajit Das On Apr 16 2021, at 1:19 am, Tim Allison <[email protected]> wrote: > XML sorry and thank you... > > Fellow devs, any objections? > > On Thu, Apr 15, 2021 at 2:53 PM Subhajit Das <[email protected] > (mailto:[email protected])> wrote: > > Ok, so priority should be lik: > > > > No accept header: highest priority in list > > The list: > > MediaType.TEXT_PLAIN_TYPE, > > > > > MediaType.APPLICATION_JSON_TYPE, > > > MediaType.TEXT_XML_TYPE, > > > MediaType.TEXT_HTML_TYPE > > I didn't see any produce type method as XHTML. HTML is used for produce > > type. > > Raised https://issues.apache.org/jira/browse/TIKA-3357. But please don't > > accept the PR yet. will make a few mods for this. > > Thanks and Regards, > > Subhajit Das > > > > > > > > > > > > > > > > > > On Apr 15 2021, at 11:47 pm, Tim Allison <[email protected] > > (mailto:[email protected])> wrote: > > > Oh, this would be great! > > > > > > I guess after the first one, it won't matter? That is, if they don't > > > add an "accept:" header, then they'll only get one thing, whereas if > > > they do, then we won't have to guess? > > > > > > If we were to rank them, I'd go with xhtml as the first option out of > > > historical precedence. > > > > > > On Thu, Apr 15, 2021 at 1:53 PM Subhajit Das <[email protected] > > > (mailto:[email protected])> wrote: > > > > > > > > How about ?: > > > > > > > > MediaType.TEXT_PLAIN_TYPE, > > > > MediaType.APPLICATION_JSON_TYPE, > > > > MediaType.TEXT_XML_TYPE, > > > > MediaType.TEXT_HTML_TYPE > > > > > > > > with added application/json (lower in list, higher the priority). > > > > On Apr 15 2021, at 11:01 pm, Subhajit Das <[email protected] > > > > (mailto:[email protected])> wrote: > > > > > > > > Hi Tim, > > > > > > > > It is possible as it is, with simple addition of ResourceComparator. I > > > > have made one, which selects resource endpoint based on the produce > > > > type. > > > > > > > > I am thinking of this order: > > > > > > > > private static final List<MediaType> PRIORITIZED_MEDIA_LIST = > > > > Arrays.asList( > > > > MediaType.TEXT_PLAIN_TYPE, > > > > MediaType.TEXT_XML_TYPE, > > > > MediaType.TEXT_HTML_TYPE > > > > ); > > > > > > > > Lower (higher index) has higher priority. > > > > > > > > What should be the final list, please suggest. > > > > > > > > > > > > On Apr 15 2021, at 10:04 pm, Tim Allison <[email protected] > > > > (mailto:[email protected])> wrote: > > > > > > > > Can we programmatically specify the default order for ambiguous calls? > > > > For example, I recently added a json output for the /tika endpoint, > > > > and that is now the default...if the client does not specify "accepts" > > > > in the header. That'll be a breaking change, which I don't want. > > > > > > > > Is the problem the design of our api? Or can we fix this as is... > > > > > > > > Thank you! > > > > > > > > Best, > > > > > > > > Tim > > > > > > > > On Wed, Apr 14, 2021 at 1:29 PM Subhajit Das <[email protected] > > > > (mailto:[email protected])> wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > In Tika server, if a request is made against a REST resource and if > > > > > it is matched with multiple resource handler method (like getXML and > > > > > getText), then, is there predefined order of resolving method? > > > > > > > > > > There is always an warning printed, in such case. > > > > > > > > > > Practically I have seen uncertainty in method. > > > > > > > > > > > > > > > > > > > > Thanks and Regards, > > > > > > > > > > Subhajit Das > > > > > > > >
