Sorry for trying hard to be a pita :) but again, can we please let all these discussions take place in the mailing list? I think it's easy to first discuss a topic in the mailing list and then create a jira which either sums up the discussion or references the mailing list archives.
Carsten Felix Meschberger (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/SLING-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535850 > ] > > Felix Meschberger commented on SLING-64: > ---------------------------------------- > >> ... to use factories, or rather, mappers. > > Which is at the core of my proposal. Speaking in OSGi terms, Servlets are > registered as OSGi services and specify in their service properties the > resource type(s) they are willing and able to handle requests for. The > Servlet Mapper looks at those registered servlets and selects one on behalf > of Sling. > > And yes, I ultimately suggest dropping the SlingServlet interface including > the canProcess method. Not because I do not like it per-se, but I think it > will not scale - rotating to a possibly big number of servlets asking each in > turn whether it may handle the request may prevent the system from working. > > But this proposal is just about modifying the general working : not looping > through servlets but (1) look for servlets by resource type, (2) check for a > script and (3) fall back to a defaul servlet. There will be another issue > handling the first step in more detail. > >> Refactor Servlets and Script resolution >> --------------------------------------- >> >> Key: SLING-64 >> URL: https://issues.apache.org/jira/browse/SLING-64 >> Project: Sling >> Issue Type: Improvement >> Components: microsling >> Reporter: Felix Meschberger >> Fix For: 2.0.0 >> >> Attachments: SLING-64.patch >> >> >> microsling currently defines a SlingServlet interface which has a canProcess >> method used to decide whether a servlet is capable of handling a request or >> not. I think, this mechanism will not scale well if we add more script >> engines or more servlets. >> As a first step towards a simpler approach, I propose the following: >> * Merge the DefaultSlingServlet and the SlingPostServlet to a single >> DefaultSlingServlet >> * Replace Rhino and Velocity servlets by respective ScriptEngines (and >> define the interface for that) >> * Refactor the SlingScriptResolver such that after resolving the script, >> it is also evaluated through a ScriptEngine >> * Refactor MicroSlingServlet such, that >> (1) check for a servlet by resource type >> (2) try to evaluate a script >> (3) fall back to the DefaultSlingServlet >> * Also in the MicroSlingServlet register servlets by type (currently >> there are none of course) > -- Carsten Ziegeler [EMAIL PROTECTED]
