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);

<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 

Hope this is useful. I too am self-taught and certainly no expert but what 
works and is simple tends to rule my development.

* 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 

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);
>> 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.
>> 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 sounds 
> like a reasonable
> architecture to me.
> -- Scott
>> I must say I'm a bit afraid of these big frameworks like spring/struts
>> that brings many features that already exists in Resin, like
>> persistency, tag library, dependency injection etc. One of the reason I
>> like resin, apart from performances, is that there is everything in it.
>> Thanks for your help.
> _______________________________________________
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest

resin-interest mailing list

Reply via email to