Reputation: 1436
We are currently moving an EE6 / JSF application from a deployment path someserver.com/app
to its own subdomain app.someserver.com
.
Most things are working smoothly, but we have had unexpected troubles with how the web layer handles the now basically nonexistent context-root.
One thing we found and fixed early was that a cookie we set had its path shortened from "/app"
to ""
, and thus was only readable per folder on the server, not for the entire application.
We have now found a similar problem with hyperlinks that we generate in JSF:
<a href="#{request.contextPath}">Go to home page</a>
This was previously rendered as href="/app"
and worked fine, but now with href=""
the link is understandably no longer active. I want it to say href=""/"
.
Is there an elegant solution for that?
Keep in mind that we also have links of the form
<a href="#{request.contextPath}/projects">Go to projects page</a>
, so simply replacing the empty context path with "/"
is not good enough.
Am I missing something obvious? I saw an explanation here (which matches what we experience), but no elaboration on possible solutions.
Upvotes: 0
Views: 2807
Reputation: 1436
Turns out I wasn't thinking clearly. I was so focused on fixing the string that #{request.contextPath}
produces, that I missed that I basically used it wrong the entire time.
The simplest solution is to just use
<a href="#{request.contextPath}/">...</a>
(with a trailing slash) to get to the root of the application, and never use href="#{request.contextPath}"
without a slash at all.
This solves both cases. If the application is deployed to "some_folder", the link becomes "some_folder/"
. And if the application is deployed to the server root, then the link becomes "/"
.
Hope this helps someone who stumbled into the same trap.
Upvotes: 2