Should have said thread safe. I was thinking to make the POJOs reusable to
allow for fewer objects to be created. As it stands now, every requests
instantiates and destroys a handler POJO. From time to time I consider
restructuring these into a worker queue of instantiated objects to eliminate
the overhead of creating so many objects. Like I said, haven't had any
performance issues yet but I do worry about large amounts of object creation
When I first started programming I remember being told not to use the service
method. Not sure why and never really investigated it since but glad to know
you don't have any issues.
On Mar 22, 2013, at 2:06 AM, Riccardo Cohen <r.co...@realty-property.com> wrote:
> Hi Matthew,
> 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 know.
> 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
>>> email@example.com <mailto:firstname.lastname@example.org>
>> resin-interest mailing list
> Riccardo Cohen
> +33 (0)6 09 83 64 49
> Société Realty-Property.com
> 1 rue de la Monnaie
> 37000 Tours
> resin-interest mailing list
resin-interest mailing list