So here is my story.
I am developing a spring web application. The reloading of static content (js, css, jsp) was broken and found a solution in the following thread:
Getting resources in VFrabric Server to deploy without causing container to reload
In order for reloading to work I couldn't have the root URL '/'. So I change that to '/project' and my reloading works. Great!
But then comes the next problem. I have a lot ajax requests to '/typeahead/searchUniversities/%QUERY' for example, this would need to be changed to 'project/typeahead/searchUniversities/%QUERY'. And when I upload it to the production server I would need to change it back to '/typeahead/searchUniversities/%QUERY'
Since '/project' is just for development
So the I read about profiles but I'm not sure if this is the way to go. I might overdoing it?
I was also thinking of having something like '${baseurl}/typeahead/searchUniversities/%QUERY' and then just change in one place before production. But not sure how to do this.
If someone could guide me with an example of how to do this it would be great.
Thank you!
Edit : add another more direct way to get the context path in a JSP
The url should never be static in the webapp : the context path is determined at deployment time and not at compile time. If you are using spring tag library, you can make use of <spring:url> tag, if not of the JSTL <c:url> tag. Both will automatically add the context path for you.
BTW : in a JSP <%= application.getContextPath() %> gives the context path without any additional taglib.
But please only use relative paths where it has sense and never for "top level" URLs.
Your application shouldn't depend on the context path it is deployed under. One solution to this particular issue would be to use relative paths in your ajax requests,
e.g.
'typeahead/searchUniversities/%QUERY' rather than '/typeahead/searchUniversities/%QUERY'
Related
In my application every link generated is surrounded by response.ecodeURL. On some servers encodeURL adds the context-path to the URL.
The application is named "appl". Creating a link /a/b/c.jsp creates on DEV-system the url /a/b/c.jsp, on Prod it creates /appl/a/b/c.jsp
The tomcat is behind an Apache Webserver which connects via ajp, not sure if thats a relevant fact.
EDIT:
The Webserver isn't relevant. I tried going directly on port 8080 and the same happend again.
<c:url> always pre-pends the context path to URLs: this is standard practice and should always be done. If you are using <c:url> then you shouldn't add your own prefix. Also note that <c:url> runs the URL through HttpServletResponse.encodeURL for you. That method adds URL-based session-tracking information (e.g. the ";jsessionid" path parameter) if appropriate.
You should always add the context prefix to all URLs, whether you use something like <c:url> or do it yourself. You just shouldn't do both. When you use the ROOT context, the context path with be "" (i.e. empty string) and nothing will be pre-pended to your URLs.
I am trying to understand how the requests works. Unfortunately I was thrown at coding first and only then at understanding.
I wrote some really basic webapplication in java few years ago and it did work as expected. On its main web-page(.jsp) I had following as one of the menu buttons:
<p>test</p>
I am currently writing new webapp and forgot a lot. This time I am doing it with Spring MVC and properly. I can't really understand why this snippet no longer brings me to the home.jsp in current webapplication and why at first I did use it in old app.
Apache gives: The requested resource () is not available.
It is not that I need that sort of direct interaction, it is just I am trying to understand whether resources are accessible via URL? Does Spring MVC brings me extra security, where only servlet handled requests can result in a view? Am I missing something really trivial?
Moreover in that same old web app menu I had direct link to the servlet, but currently I can't make such direct reference to the servlet in the new webapp. I can make relevant request which will be captured by the servlet, but not by the name of it.
Apache gives: The requested resource () is not available.
Reference to servlet from menu:
<% if((String) session.getAttribute("passengerFound") != null){ %>
<img style="border:0" src="menuButtons/My Trips.png" alt="My Trips"/> <%} %>
Thanks, I bet it is really simple. I really want to understand, please help.
I know that it has something to do with Front Controller(dispatcherServlet), but I can't form logical and firm explanation in my head.
it is just I am trying to understand whether resources are accessible
via URL
In short, no. The default behavior and recommended configuration when using Spring MVC is to map the Spring DispatcherServlet to the / url pattern, meaning ALL requests are sent to the DispatcherServlet. Out of the box, the dispatcher-servlet will NOT service any requests for static resources. If this is desired, the two main options are
Map the DispatcherServlet to another pattern than root, effectivly isolating the Spring MVC portion to a sub-context
Add a resource-mapping to your spring context (your applicationContext.xml).
<mvc:resources mapping="/res/**" location="/res/" />
This above would tell spring mvc to treat all request to /res/** as requests for static resources (like images etc) and that those resources are physically located in the /res/ folder in the application root.
You might just be missing a "/" as in "/home.jsp" instead of "home.jsp"
I've got a struts2 application running under a contextpath "/path" on my local tomcat without problems. When I deploy it on a webserver (using a proxy to redirect from "http://www.domain.com" to "myserver:8080/path/") Struts does all kinds of strange things.
First, it includes the context in -tags. That can be turned off by an attribute. But sadly, it also includes the path in the action attributes of my forms, so a login form points to "http://www.domain.com/path/login.action" instead of "http://www.domain.com/login.action" ...
Is there a possibility so somehow change the default context that is added here or turn this off for forms? (I'd like to keep the -tags, only way round seems to be to use default HTML forms.) Thanks in advance!
I found that others also had the problem, but the framework makers don't seem to think that this is an issue. My solutions:
use includeContext="false" in all s:url-tags
instead of the s:form tag, use a usual form, set the action to "actionname.action" and include a simple table with tablerows () for each field. You still can use s:textfield and such.
sadly HTTP sessions won't work anymore as they get set for the path "/path" (the ApplicationPath). This is due to the cookie that saves the JSESSIONID being set to /path. This means that your visitors will only get session variables stored when they're at http://www.domain.com/path/login.action and that those will be lost when they get redirected back to http://www.domain.com/interestingstuff.action ... my solution is a hack that requires setting the JSESSIONID cookie clientside via JavaScript as described here: Struts2: Session Problem (after reverse proxy)
Hope this helps someone ... if you find nicer solutions, please let me know. :-)
Though am answering very late to this question, but I reached this page recently when I was facing the same problem.
The application that I was working upon was appending the context-root viz. 'myContextRoot' to my url on localhost and it was working perfectly there. For eg., as mentioned above the action 'myAction' was becoming
http://localhost:8050/myContextRoot/myAction.action
But the moment I deployed it on a server, it stopped working, then after searching like hell, I found a solution for me. I am deploying an EAR file on glassfish and there we have a file application.xml. In application.xml I had a tag 'context-root' whose value was 'myContextRoot' which I changed to '/' and after that I got my url as on localhost and
Hope it may help :)
I have a web application, which was designed and always worked under root context ("/"). So all css, js and links started with / (for example /css/style.css). Now I need to move this web application to some different context (let's say /app1). It is easy to change server.xml configuration file and bring up web application in new context app1 using [Context path=""] item. But web pages are broken because all links are now incorrect. They point to old root context /css/style.css instead of new app1 context.
Is there any magic way to fix this problem without fixing each link by prefixing with some "context" variable?
Used server - Tomcat 5. Application is written with Java and uses JSP, Struts2, Spring and UrlRewrite filter. More interesting is to hear real experience in fighting with such problems that theoretical debates.
Thank you.
P.S. I do not see how UrlRewrite filter can help me because it will work only in app1 context. So requests to links like /css/style.css will not be passed to it.
If you use URL rewriting to redirect ROOT to your application, won't that eliminate the ability to have a an application in ROOT? If so, what is gained by switching the context?
I think the general way to link resources is to either append a "context" variable and make the link absolute: ${pagecontext.request.contextpath}/css/style.css or just make the link relative: css/style.css
Unless you have specific reasons for being unable to modify the code, I would do a search/replace on the links and be done with it. You should have no more than three or four expressions to find, /css, /images, /javascript, etc.
You should always create urls via url re-writing, not only so that session info can be added to the url, if required, but also so that the context path can be added. You should create all urls as absolutely paths from the top of the application and then let url-rewriting handle adding the context-path to the front, as appropriate.
<c:url value="/css/site.css"/>
That will render /<context-path>/css/site.css or /<context-path>/css/site.css;jsessionid=134345434543 into a jsp file if they don't have cookies enabled. You can also use the c:url tag to render the url into a variable and then use that variable multiple times throughout your document. Just add a var="x" attribute to the tag and then ${x} will render the url into your doc. If you aren't using jsp to render your output, you'll need to find the appropriate mechanism for your view layer, but they will all have one. If you are rendering a url in java code, just take a look at the source code to the c:url tag and you'll see how it is done.
The one awkwardness is that CSS files (and js files) aren't processed, so urls in css and js files need to be relative paths or they will break whenever you change the context path. Most js already uses relative paths since library maintainers don't know what path you are going to install their library to. CSS backround images, on the other hand, are often specified as absolute urls, since the same CSS file may be included into html files at different levels of a file hierarchy. There is no easy fix for this that I am aware of other than to create appropriate symlinks such that the relative url always works or else serve up the problem CSS files via a JSP so that the urls can be rewritten as appropriate. I'm sure there are probably filters or apache modules you can run which will do the url replacement, but then you've still got to manually update your filter/module whenever you deploy to a new context path.
I'm working on a webapp that uses struts 2, spring, URL Rewrite Filter and a couple of other dependencies that I'm not sure are relevant to this. One of the url's we construct is constructed as follows:
<s:url id="blah" includeParams="get">
This works fine when deploying in jboss as a normal webapp dropped in deploy/. So then all urls are of the form http://localhost:8080/mywebapp/... and when using this tag all the get parameters get included as expected.
However we wish to deploy this code in the root context (so everything ends up under http://localhost:8080/...), so we deployed it as ROOT.war. Suddenly, all the get parameters no longer show up in the URL. I've been looking for a while and can't seem to figure out what might cause this. First I thought it was to do with the URL rewriting but it seems to be working fine. Any tips, pointers, further questions for clarification are welcome. To add to the confusion, this all also works fine when deployed in jetty (where root context is the default).
edit: I've also tried removing ROOT.war and using jboss-web.xml to deploy to root context, this exhibits the exact same problem though.
I tracked this partly down to the url rewriting being misconfigured, the get parameters weren't being added to the urls to be rewritten because 'include-query-string' wasn't set to true on urlrewrite. this meant that 'blah?querystring' wasn't being redirected to 'blah.action?querystring'. It still doesn't seem to work right now because of interrelated problems, but I will separate those out to another question.