I share your fear of frameworks so I created my own request handlers using
Resin 4 and a couple of simple classes. Not sure why you specifically want to
handle JSP requests with a servlet so I might be missing something but:
I put all my JSPs under WEB-INF for privatization (WEB-INF/views/*.jsp).
Set a regex in web.xml to send everything except WEB-INF (and other non-logic
requests like css, js, images, etc) to a single controller*.
Controller inspects the URL (using an enumeration for speed and simplicity) and
then calls a POJO via reflection**.
In addition, the Controller holds injected resources (Datasource, Hessian
services) that it can then pass to the POJO along with the request and
response. It also performs authorization and access control checks.
When I want to hand the request to a JSP for rendering, I simply call:
servletContext.getRequestDispatcher(url).forward(req, res);
WEB.XML
servlet servlet-name=MyController
servlet-class=com.company.web.control.MyController /
!-- Exclude requests that start with WEB-INF, css, img, js, media --
servlet-mapping url-regexp=^/(?!WEB-INF|css|img|js|media).*
servlet-name=MyController /
What this leaves is a very minor configuration in web.xml (2 lines) and
complete control over the URL handling in a single class. To add a new URL, I
add a new enum entry (URL path, fully-qualified POJO name, method to invoke on
the POJO) and I add the POJO java file.
As an aside, Resin has a couple other features that I absolutely love.
1. XML configuration injection into resin.xml
I utilize Resin's configuration injection to automatically load
app/environment-specific configuration into Resin from a single external XML
file. I create an app-env.xml and deploy it along with my war files. My Resin
config is set to load all XML files in the web apps directory so when Resin
starts, it loads the XML and the WAR; datasource, hessian services, and other
environment data defined in the XML is loaded into/injected into the app
automatically which makes multi-environment (dev, qa, prod) deployment trivial
and allows the exact same WAR file to travel through all the stages since there
isn't any environment-specific data in the WAR itself.
2. Multipart form request handling
I add multipart-form enable=true / to web-app-default and then multipart
requests provide all the uploaded file details as request parameters. Super
convenient.
Hope this is useful. I too am self-taught and certainly no expert but what
works and is simple tends to rule my development.
matt
* Controller is a simple extension of HttpServlet and I send both GET and POST
requests to a single custom execute method. The execute method just passes
along the request so that the handlers can decide to treat GETs and POSTs
however they choose. The execute method is also where all the URL handling,
authorization, etc is performed.
** The POJOs could be threaded for more scalability but I haven't yet hit a
threshold where I need to take on the cost of reprogramming these for
concurrency.
On Mar 21, 2013, at 11:00 AM, Scott Ferguson f...@caucho.com wrote:
On 3/21/13 10:51 AM, Riccardo Cohen wrote:
Hello
I'm refactoring my url requests processing and need some advice. I've
learnt mostly by myself, and I'm not sure to make the good choices.
Presently my request processing is a mixing of servlet configurations like :
servlet-mapping url-pattern=*.jsp servlet-name=resin-jsp/
servlet-mapping url-pattern=/fr/* servlet-name=urlmanager/
and some java code in UrlManager.java servlet, analysing the url
request, processing the request, and calling at the end :
req.getRequestDispatcher(/page.jsp).forward(req,res);
QUESTION 1:
When I call req.getRequestDispatcher(/page.jsp).forward(req,res); this
goes through a certain process depending on resin.xml conf (first line
above), analysing the pseudo-request /page.jsp, and finally calling
service() of the instance of com.caucho.jsp.JspServlet created by resin.
I was wondering how to call directly the JspServlet instance myself ? It
would be much quicker because I know this is a jsp page (systematic
final step of the processing).
Since all that processing is cached, the cost is really just a hash map
lookup, which
probably isn't noticeable.
You could also use ServletContext.getRequestDispatcher(...) in an
init() method (or lazily) and save the RequestDispatcher object. The
RequestDispatcher is reusable.
So calling directly shouldn't actually be a measurable gain.
QUESTION 2
What I would like is having a better control on requests, by gathering
all the processing in one point, not half configuration, half java code.
My solution would be to have all requests handled by my unique
urlmanager servlet, and I would dispatch them myself with built-in resin
servlets. Any suggestion will be appreciated, as long as performance is
very good.
Someone else would be in a better position to answer, but that
