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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> http://maillist.caucho.com/mailman/listinfo/resin-interest >> >> >> >> _______________________________________________ >> resin-interest mailing list >> [email protected] >> 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 > [email protected] > http://maillist.caucho.com/mailman/listinfo/resin-interest _______________________________________________ resin-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/resin-interest
