Hi,
I cannot reproduce using GlassFish.
What Web container are you using?
There was a fix in 1.4 to properly support URL patterns of the form
<url-pattern>*.xxx</url-pattern>
http://java.net/jira/browse/JERSEY-506
I have found that the edge case of handling "/app" very problematic
with Web containers
Paul.
On Nov 16, 2010, at 10:56 AM, elmar.vaneersel_at_emc.com wrote:
> Hi,
>
> I have a problem with the subresource locator path matching
> algorithm that apparently got changed in 1.4
> It looks like the new (I my opinion incorrect) algorithm assumes
> that a variable subresource path matches everything after the last
> slash when the root resource matches a certain URL, without checking
> that that last URL part does not equal the root resource path
> itself. I verified that both Jersey 1.2 and 1.3 worked the way I
> assumed it would, but both 1.4 and the current 1.5 exhibit this
> changed/unwanted behavior.
>
> An example of what I am talking about will probably be helpful:
>
> Say you have an JAX-RS application registered at “/app” and a root
> resource with @Path(“/”) which in turn contains a subresource
> locator with @Path(“{sub}”).
>
> Before 1.4, the behavior would be that both ‘http://my.host.com/app’
> and ‘http://my.host.com/app/’ would match the root resource while http://my.host.com/app/sub1
> ’,http://my.host.com/app/sub2’ or anything of that form would match
> the sub resource.
>
> In 1.4 and later though, both ‘http://my.host.com/app’ and ‘http://my.host.com/app/sub1
> ’ match the sub resource and only ‘http://my.host.com/app/’ matches
> the root resource.
> I have also, against my expectations, tried the redirection feature
> in the hopes that that may perhaps redirect ‘http://my.host.com/app’
> to ‘http://my.host.com/app/’, but that does not do the trick, which
> makes sense as the redirection feature is only used when there would
> be no match otherwise. Since the subresource is incorrectly matched,
> the redirection does not get triggered.
>
> In case there is no subresource locator for a particular root
> resource than ‘http://my.host.com/app’ results in a 404, while ‘http://my.host.com/app/
> ’ continues to work. In this case the redirection feature does solve
> this problem, but again, before 1.4 this also worked without using
> the redirection feature.
>
> Is this behavior a bug or a deliberate change?
>
> I can live with the latter as needing redirection to solve properly,
> which although a slight pain, is something I can see being
> necessary. The first problem though is something I simply cannot see
> any usecase for and to me seems like a real bug. The complete lack
> of any workaround also means that it becomes nearly impossible to
> make both root resources and subresources available at the same time
> while ensuring things work reliably as well.
>
> Thanks,
>
> Elmar