This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
I am trying to do something unusual here. I want to customize the way tomcat looks for jsp files after parsing the url. For example, a url like www.abc.com/hello.jsp, tomcat would read the name hello.html and look for it in the web-inf folder. What I am trying to do is to edit tomcat to decode a url like www.abc.com/msncs and have tomcat produce the hello.jsp file. So basically I want to edit tomcat to read the url and instead of looking for the file 'msncs' directly, it would lookup the code in the database and get the actual name of the file to look for and the rest of the process remains the same. Later on I would also like to add support for parameters, as in www.abc.com/msncs?param=hello. So basically the system is a huge database of codes and a jsp file associated with it. I guess it can be done with web.xml by creating an alias for the generated servlet, but the only problem is that I cannot edit web.xml file dynamically i.e I cannot add codes into web.xml file as i can do using a database from an external client.
I would like to know what section of tomcat I need to edit and how it would affect other normal requests. I know its a crazy thing to do, but I have a crazy boss with crazy ideas and crazy requirements
It's not crazy at all. It's called URL rewriting and is extensively used in websites and webapps - whether it's java apps or PHP apps or other languages.
Lots of benefits - users see friendly readable URLs, search engines get SEO friendly URLs, domain names can be changed without affecting search rankings.
In fact, the typical URLs like .jsp / .do / .html / .php that programming books and tutorials show in their app listings are a bad practice. Why should users care what technology is behind the URL?
One way to do this in java web apps is using a servlet that receives all requests ("/*"), examines the last segment of URL, looks it up in DB, decides on the view to display, and then forwards the request to that view.
Another way to do this is using a servlet filter to manipulate the URL before it's reached any servlet.
Though it's feasible to map names to JSP files in principle, it can run into problems, because JSPs are deployment artifacts while the database entries are runtime artifacts.
You or somebody has to login into the database, and update some rows to keep it in sync correctly, each time you add a new page or changes its filename. If it has 1000s of rows, it's easy to make mistakes with this kind of a workflow.
If each of your JSP is very different in layout, then perhaps this is the only way.
But if all your JSPs are very similar in layout - or the set of layouts is small - and it's only the content that changes for each entry, then it's better to store those content values in DB.
On receiving a request, read that content from DB, select one of the JSP templates, and render that content in that JSP using JSTL tags.
Thanks for the reply
I tried using a single servlet for all requests and then looked up in the database. But when I tried to redirect it to the appropriate web page it passes through the same servlet again and runs into loops. I need to figure out a way to stop that from happening.
Anyways thanks for the answer
Joined: Apr 04, 2009
Oops, sorry about that - my mistake. If using /*, best to use a servlet filter instead of servlet. Forwarding from servlet will make it go into infinite recursion.
Deploy your app as ROOT.war.
Keep all your JSPs under a "/pages" directory in the WAR.
In your filter, check whether URL startwith "/pages". If so, let it pass through the filter chain; it'll be eventually handled by the JSP servlet.
If not, do the DB lookup and forward it to appropriate JSP.
It should be like