Thanks for your sharing. It helps me a lot.
I was wondering why you talked about "POJOs could be threaded" ? The
request processing itself is already multi-threaded before your pojos
are called, so I don't see the need to worry about it. Resin and all
application server start a thread from a pool at each request as far as
I use the "service()" function of httpservlet, it handles get and post
Thanks a lot.
On 21/03/13 19:44, Matthew Serrano wrote:
> 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
> When I want to hand the request to a JSP for rendering, I simply call:
> servletContext.getRequestDispatcher(url).forward(req, res);
> <!-- Exclude requests that start with WEB-INF, css, img, js, media -->
> 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.
> ** *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
> <mailto:f...@caucho.com>> wrote:
>> On 3/21/13 10:51 AM, Riccardo Cohen wrote:
>>> 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 :
>>> 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
>> firstname.lastname@example.org <mailto:email@example.com>
> resin-interest mailing list
+33 (0)6 09 83 64 49
1 rue de la Monnaie
resin-interest mailing list