Ricardo,

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 
under load.

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.

m


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 
> transparantly.
> 
> Thanks a lot.
> bye
> 
> 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
>> checks.
>> 
>> When I want to hand the request to a JSP for rendering, I simply call:
>> servletContext.getRequestDispatcher(url).forward(req, res);
>> 
>> *WEB.XML*
>> <servletservlet-name="MyController"servlet-class="com.company.web.control.MyController"/>
>> <!-- Exclude requests that start with WEB-INF, css, img, js, media -->
>> <servlet-mappingurl-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
>> <mailto: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 <mailto: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
>> 
> 
> -- 
> Riccardo Cohen
> +33 (0)6 09 83 64 49
> Société Realty-Property.com
> 1 rue de la Monnaie
> 37000 Tours
> France
> 
> <http://www.appartement-maison.fr>
> 
> _______________________________________________
> 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

Reply via email to