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 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 resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest