Hi Daniel,
See:
https://jersey.dev.java.net/issues/show_bug.cgi?id=355
This rather embarrassing bug was fixed in Jersey 1.1.2-ea.
Paul.
On Oct 1, 2009, at 1:12 PM, Daniel Larsson wrote:
> Hi all,
>
> I've dabbled a bit with URI content negotiation, i.e. setting up
> extension mappings to languages like so:
>
> public class ServletContainer extends
> com.sun.jersey.spi.container.servlet.ServletContainer {
>
> @Override
> public void initiate(ResourceConfig rc, WebApplication wa) {
> super.initiate(rc, wa);
> rc.getLanguageMappings().put("en", "en");
> rc.getLanguageMappings().put("sv", "sv");
> rc.getLanguageMappings().put("da", "da");
> rc.getLanguageMappings().put("no", "no");
> }
> }
>
> Trouble is this isn't working very well, depending on the name of
> the resource I'm trying to retrieve. It looks like the uriconneg
> code is looking for the extensions in the part following the last
> slash, but it doesn't check for a preceding ".". Or rather, it does
> the check after looking for the "extension". This means when I try
> to access a URI like "http://localhost/document.en", the code finds
> "documENt.en", figures out the "en" isn't preceded by a ".", and
> goes on to the next mapping.
>
> The end result is it tries to find a resource named "document.en"
> rather than "document" with "Accept-Language: en".
>
> I've attached a small maven project to illustrate the problem.
> Should I file an issue?
>
> Daniel Larsson
> <
> uriconneg
> .tgz
> >---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net