We Keep Coding

Where to store form error message content

I am working on a jsp/servlet web application. I currently use a switch statement within my servlet to select the appropriate error message for each form field (according to the input) and then set that message as a request attribute.
I now want to internationalize the web page (have it available in another language). I was thinking to do this by having a separate directory for the other language and placing the jsps in the other language in that directory. Then a filter will redirect to the appropriate directory via a session attribute.
The problem is that my custom error messages are currently written in the servlet. I was not planning to reroute to different servlets according to the language (ie: same servlet will run for all languages).
The only way that I can think of to do this would be to write each of the custom error messages on the jsp and then have the servlet set a request attribute that identifies the error type.
This solution would require adding a lot of text to the jsps (some fields have 10 different error messages and different messages depending on user type).
Any suggestions of a better approach for making the form error messages multi lingual are welcome.
Also, if there are any general suggestions on a better way to internationalize my site altogether that is also welcome.
Thank you,
.

Read jsp page output from my application

I would like to read jsp page from my application and save it to a file - it's output, not the code itself. Plus, my application has basic authentication (username+password).
If it was a Servlet, I could just access it's doGet method.
One solution I've found is this - Open URL connection, provide authentication details and read the stream.
I'm wondering if there's another option, maybe accessing the generated Servlet in the web container and then using reflection to call the class doGet.

You can precompile the JSP and then call the servlet (you don't have to use reflection even).
If you try to call the JSP's servlet without precompiling then it might not exit yet (because usually the server only compiles the JSP after it was called for the first time).
To precompile the JSP, check your web server documentation.
Personally I think you're better of using URL connection. Precompiling JSPs is not portable (as in you need to do it in a different way for each web server).
Edit
You can also use RequestDispatcher.include() method with a wrapped response object as described in this answer.

In the context of Java Servlet what is the difference between URL Rewriting and Forwarding?

As a developer of Java web application, when do I need to use URL Rewriting and what is the difference between URL Rewriting and Forwarding?
I searched on other websites, I get contradictory information depending upon whom you are talking to like SEO people would answer this question differently.
AFAIK in both cases the client (browser) is not informed of the change and the end user sees exactly same URL that the client originally requested when the repose is returned from the server.
Please that this question is in the context of Java Servlet API in which forward method and sendRedirect methods are defined in which redirecting and forwarding are completely 2 different things. This question is about the difference between forward (as defined by forward method in the Servlet API's) and URL rewriting. The question clearly states that the answer should be in the context of Java servlet. Most importantly when do I need to use URL rewriting, again in the context of developing Java web application.

The term "forwarding" is ambiguous in this question. In JSP/Servlet world, "forwarding" is more known from the MVC concept that the request URL (as visible in browser address bar) effectively calls the servlet (as matched by its URL pattern in web.xml or #WebServlet) which acts as a controller to prepare the model and uses a JSP as view to present the model. That JSP in turn is been called by "forwarding". This is done by RequestDispatcher#forward():
request.getRequestDispatcher("/WEB-INF/foo.jsp").forward(request, response);
This does indeed not reflect the JSP's URL in the browser address bar. This takes place entirely server side. Basically, the servlet "loads" the JSP and passes the request/response to it so that it can do its job of generating the HTML stuff. Note that the JSP in the above example is hidden in /WEB-INF folder which makes it inaccessible for endusers trying to enter its full path in browser address bar.
In general web development world, the term "forwarding" is also known from "URL forwarding" which is essentially the same as URL redirection. This in turn indeed causes a change in the browser address bar. This is in JSP/Servlet world more formally known as "redirecting" (although most starters initially confuse it with "forwarding"). This is done by HttpServletResponse#sendRedirect():
response.sendRedirect("another-servlet-url");
Basically, the server tells the client by a HTTP 3nn response with a Location header that the client should make a new GET request on the given Location. The above is effectively the same as the following:
response.setStatus(302);
response.setHeader("Location", "another-servlet-url");
As it's the client (the webbrowser) who is been instructed to do that job, you see this URL change being reflected back in the browser address bar.
The term "URL rewriting" is also ambiguous. In JSP/Servlet world, "URL rewriting" is the form of appending the session ID to the URL so that cookieless browsers can still maintain a session with the server. You'll probably ever have seen a ;jsessionid=somehexvalue attribute in the URL. This is by default not done automatically, but most Servlet based MVC frameworks will do it automatically. This is done by HttpServletResponse#encodeURL() or encodeRedirectURL():
String encodedURL = response.encodeURL(url); // or response.encodeRedirectURL(url)
// Then use this URL in links in JSP or response.sendRedirect().
(Which in turn is -again- an ambiguous term. With "URL encoding" you'd normally think of percent encoding. There's no Servlet API provided facility for this, this is normally to be done by URLEncoder#encode() or, MVC-technically more correct, in the JSP by JSTL's <c:url> and <c:param> or any UI component provided by the servlet-based MVC framework, such as JSF's <h:outputLink>)
In general web development world (especially with Apache HTTPD / PHP folks), "URL rewriting" is more known as whatever Apache HTTPD's mod_rewrite is doing: mapping incoming URLs to the concrete resources without reflecting the URL change in the client side. In JSP/Servlet world this is also possible and it's usually done by a Filter implementation which uses RequestDispatcher#forward(). A well known implementation is the Tuckey's URLRewriteFilter.
I admit that this has also confused me for long when I just started with JSP/Servlet, for sure while having my roots in the Apache HTTPD / PHP world.

Rewriting is a layer (often before your servlet) that causes a URL to be handled like a different URL by modifying the URL before the request is served. The servlet responds through a single request as if the rewritten URL was requested, usually having never known the rewrite occured.
Forwarding (or redirection) is performed by the browser (typically automatically) when instructed by the server via some 3xx error codes (when redirection is allowed by the client). In this case two requests would be served (not necessarily both from your servlet); the first responding with an error code and a URL to redirect to, and the second serving the proper request after the client redirects.

understanding jboss framework - URL

I am trying to figure out what the following url does.
http://server/abc/testmodule/runtest.do?action=edit&id=123
I am new to jboss/jsp but I am very familiar with .net.
When I see this url, I expect to see the physical folder called "abc" and subfolder called "testmodule" and a physical file "runtest". am i wrong? what does runtest.do? is "runtest" class and "do" is a method within it?

It could be anything--URLs can map to arbitrary resources. It might be a Struts action, it might be a servlet, it might be a Spring controller, etc.
You'd need to check your web.xml file and/or any framework configuration files, or provide more information.
(Also, JBoss isn't a framework, it's a Java EE container :)

The /abc entry is the name of the context in which the application is running. If it's a web app, deployed in a WAR file, that would be the name of the WAR that's deployed (abc.war).
The .do extension suggests a Struts or JSF action mapping.
There are two parameters passed in the GET: action, with value edit, and id, with value 123. Looks like a REST-ful API to me.

Changing Tomcat web application context

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.