]
Ken H reopened WFLY-3758:
-------------------------
As I continue working through this, I'm discovering numerous places where the
functional change of getContextPath returning "/" instead of an empty string is
breaking functionality. It is undoubtedly a breaking change causing issues in downstream
libraries and any application that uses getContextPath in, say a servlet filter to apply
security rules and generate redirects. I feel like this change should seriously be
reconsidered.
Unable to run JSF applications deployed to "/"
-----------------------------------------------
Key: WFLY-3758
URL:
https://issues.jboss.org/browse/WFLY-3758
Project: WildFly
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JSF, Web (Undertow)
Affects Versions: 9.0.0.Beta1
Environment: WildFly master at 50a830205c, JDK 1.7
Reporter: Ken H
Assignee: Tomaz Cerar
I don't think the patch in pull request 6338 is right. I experienced the issue
defined in WLFY-3448 on 8.1.0.Final, then built master at 50a830205c and the new behavior
is different but still broken. Now requests to
http://host/login throws a Not Found, the
server is expecting
http://host//login (which explodes because it isn't valid). If I
hit
http://host then the redirect is generated to
http://host//welcome because
httpServletRequest.getContextPath() is returning "/" (when it was returning an
empty string in 7.x).
From web.xml:
{code}
<welcome-file-list>
<welcome-file>/</welcome-file>
</welcome-file-list>
{code}
From jboss-web.xml:
{code}
<jboss-web>
<context-root>/</context-root>
</jboss-web>
{code}
My app is packaged as a war, so no application.xml exists to define context-root.
I would say this is a regression caused by the resolution to WLFY-3448