Develop Reference

Spring #RequestMapping redirect to same path with additional info

A somewhat unusual scenario perhaps, but we need to redirect in a Spring MVC controller from:
/js/hal-browser/browser.html
to:
/js/hal-browser/browser.html#/some_path/
All my attempted solutions to date have resulted in a redirect loop, as Spring performs the redirect but is then repeatedly matching /browser.html in the redirect URL, regardless of the additional info. What I need to say is 'match /browser.html ONLY if it's the end of the path'.
I have tried setUseSuffixPatternMatch(Boolean.FALSE); on the PathMatchConfigurer to no avail, also tried the following URI template regex pattern in the request mapping itself:
"/js/hal-browser/{file:browser\\.html$}"
..but still get a redirect loop. Ideas appreciated - this is Spring 4.1.6 in a SpringBoot 1.2.3 microservice, by way of context.
Update:
On further investigation and a better understanding of the URL fragment in use by the HAL browser to determine which path it will make a request to within the microservice itself, I believe the solution may lie not in trying to redirect off browser.html, as Spring will map this to the same controller method on every request regardless of the fragment value, but instead either reverting to the default context path for the application (/), which the HAL browser has set as its default entry point, or finding a way to configure the embedded tomcat container to respond with something sensible (not just a 404) on the default context path even though the app is mapped to /some_path.
As further context, we can redirect no problem at all from a convenience path of /browser (or whatever) into the HAL browser with the correct entry point fragment as the context path of the service - that works fine. The issue is the browser itself has a 'Go to entry point' button which, when pulling it in as a webjar, is hardcoded to /. The other alternative is to ditch the webjar and just copy in the static files for the browser and update the entry point.

The part after the # will never be sent to the server so in this case you'll always end-up with the same request within the loop.
What you can do is add a custom header in your controller, and make your controller intercept only the code where the header is not present by using the negation of the headers attribute, here's a pseudo code
#RequestMapping(value=[YOUR MAPPING], method=RequestMethod.GET, headers="!CustomHeader")

You could try not redirecting the user, but sending back the content you intended with some javascript to make the client browser to jump to the anchor on the after it loads, e.g. something like:
window.location.hash="/some_path/";

I need to create absolute URL's for my SPRING application using Thymeleaf

I have a SPRING application running (using spring boot) either directly on Java or on a Tomcat 7 server. I need to create absolute URL's for a couple of pages (mappings) so that these links can be sent via e-mail.
I thought this would be simple, but now it seems hard. I would prefer a solution that is 100% written in Thymeleaf, but if that is not possible, I can certainly provide Thymeleaf with some variables from my Java code.
Anyone solved this before in Thymeleaf?

In my opinion, you should provide a server URL in a property file and than access it in Thymeleaf. You can do it by accessing Spring Bean in a view:
<div th:text="${#urlService.getApplicationUrl()}">...</div>
In the above example, the urlService is a Spring Bean.
Please see this answer: https://stackoverflow.com/a/675903/718515
You may be also interested in #ctx variable that gives you access to servletContext. See Thymeleaf docuementation: http://www.thymeleaf.org/doc/html/Using-Thymeleaf.html#base-objects
I hope it helps!

I just did something similar where I was using Thymeleaf to generate an HTML email (and so of course links had to be made absolute). I used Thymeleaf's built-in #{} link syntax to create the appropriate URL relative to the server (since it calls the HttpServletResponse.encodeURL() which I needed to do as I had a custom implementation to do some additional URL munging), and then uses Spring's ServletUriComponentsBuilder to make the URL absolute using the HttpServletRequest server information.
<p th:with="
relativeCustomerInfoPath=#{|/my/path/${customer.code}/info/|},
customerInfoPath=${T(org.springframework.web.servlet.support.ServletUriComponentsBuilder).fromContextPath(#httpServletRequest).replacePath(relativeCouponPath).toUriString()}">
Go see your info at
<<a th:href="${customerInfoPath}" th:text="${customerInfoPath}">Link</a>>.
</p>
There may be a better way, but this worked well for me and does the making of the URL absolute entirely within Thymeleaf (though using Spring's library).

Today I made an integration that suggested using the full Url for compatibility.
The base should change according to enviroment (I just send it as attribute).
The last #{/js/i/dyn} is to get the contextPath.
<script th:src="${'https://' + base} + #{/js/i/dyn}"></script>
ref: http://www.thymeleaf.org/doc/articles/standardurlsyntax.html

Java - Managing Context Path

I have been working on an application that is currently being to deployed to numerous environments. However, we are having issues with the context path when deployed to certain environments. This is a Java/Spring application running on Tomcat 6. The deployment process is handled by system administrators so I don't have much visibility into the process so I'm trying to come up with some ways of handling the scenario. With all URLS, we prepend them with request.getContextPath(). Under normal circumstances, this works fine. For example, if WAR has the filename site1.war, it gets deployed to
/site1/
However, we have a couple of other environments where the WAR is deployed and it contains a rootpath outside of the application root so it ends up with
/otherroot/site1/
So the application root path is /site1/ and is unaware of this other rootpath /otherroot/. In this case, calling getContextPath() returns /site1/ when in reality the path that we want is /otherroot/site1/.
Now, one thing that has me confused is that when we use #{request.contextpath} within a JSF page when defining images (images, stylesheets or javascript files), the URL is correct when looking at the source. For example, given the /otherroot/site/ url, if I set
<img src="#{request.contextPath}/image1.png"/>, when I look at the source of the rendered page, I see /otherroot/site1/image1.png. Now, if I set some JS variable to hold the context path every time the page is rendered, I get a different result. For example,
<script>
APP.ROOT_PATH = '#{request.contextPath}';
</script>
This renders the following:
APP.ROOT_PATH = '/site1'
This is causing some issues because we make use of asynchronous requests so we use the url to properly request data from the client side.
So my question is, what is the best strategy for writing an application that can run under any given path?

You can achieve this by using interceptors which would identify the environment for you. You can pass the environment path through model to UI which could be used by UI.
For eg. /otherroot/site1/ , in this site1 is the context name and otherrrot is the environment.
When yo hit your server to render a jsp, interceptor will analyze this url and come to know that url has something to do with otherroot1. This environemnt and related data can be set in model which could be used to fetch js, images etc and for any other ajax call.
No need to rely on url context path once page is rendered.

How to know which is the JSP webpage that is showing my servlet

I have a project that I can see the JSP's... However Jboss shows me the servlets so in the address bar all i can see is:
"appservleer?=AppDev"
This is an example not the actual address...but with that info only how can I know which JSP is being displayed at that moment by JBoss.
or am I understanding this Jboss, servlet, JSP incorrectly?
Some guidance would be appreciated.
Thanks.

You cannot know which jsp is being displayed unless the developer decided to give hints about it.
A jsp is just a view technology that the servlet uses to render a response. That is, typically, the jsp will be parsed and html will be generated. However, the developer of the servlet may decide to write to the response himself. So nothing can really tell you if what you got came from a jsp or from another source, even if you had a url like www.mydomain.com/page.jsp. Nothing guarantees the response you are seeing in your browser was generated from a jsp.

The only way to know for sure which JSP is used for rendering is to look at the source code of the servlet that is mapped under (in your example) "appservleer".
Look in web.xml which servlet is mapped with this path, and open the source code of this servlet. Then figure out the execution path, starting with the doGet(...) or the doPost(...) method, and see to which JSP it is forwarded in the end...
Good luck.

You should always start with the web.xml file which will eventually lead you to the actual jsp file that is displayed. Start with the servlet mapping and check which servlet is invoked for the url. Then dig into the servlet to find out which jsp it is redirected to. If you are using any application framework then look for the implementation to findout the mapping. For e.g. in spring the spring configuration files or the controller classes tells you where the calls are redirected to.

What contract is between URL bar address and page/file/action in JSF web app?

I see that address is not changed after going to second page (file) through bean action.

#Bozho is correct.
If you want to update the URL, the default mechanism is to use an outcome like /foo/bar?faces-redirect=true to redirect after the POST. There is also a <redirect/> instruction if you're using faces-config.xml navigation-rules. Details can be found in section 7.4.2 Default NavigationHandler Algorithm of the JSF 2 specification.

jsf actions happen by submitting the form to the same URL. JSF then decides, based on request parameters, which action to invoke. After that navigation rules are resolved in order to show the user the correct page. But navigation rules are by default using forward (server-side redirect), and so the client does not see a change in the url.