On 30 Sep 2010, at 16:20, Justin Edelson wrote: > On Thu, Sep 30, 2010 at 11:15 AM, Ian Boston <i...@tfd.co.uk> wrote: >> >> On 30 Sep 2010, at 15:59, Justin Edelson wrote: >> >>>>> >>>>> >>>>> http://codereview.appspot.com/2333042 >>>> >>>> This looks like an elegant solution to me (ok, I am biased because it >>>> just reuses my own stuff ;-) ). >>>> >>>> +1 >> >> Thanks >> >>>> >>>> Regards >>>> Felix >>> >>> Made one nit-picky comment on the code, but otherwise +1. Would also >>> like to see an integration test :) >> >> Thank you, will do. >> >>> >>> That said, I'm still confused as to why Pax Web filter registration >>> isn't working for you, but I agree it would be appropriate to have >>> support for "container"-level filters like this. >>> >>> Justin >> >> >> I think it would work with the SlingMainServlet http context, but since that >> was registered first, at /*, any other http context or path does not appear >> to bind onto the SlingMainServlet. >> >> I suspect if I created a http context, registered a servlet at say >> /system/testing and then registered a filter on /system/* on the same http >> context the filter would bind to the servlet. >> >> Ian >> >> > > I believe you :), I just wonder why Pax has this restriction (that you > need to use the same HttpContext in Filters and Servlets) and Felix > HttpService doesn't. But since the OSGi Alliance hasn't standardize > Filters, it's hard to say who is correct.
Ahh, agreed. I have been running the Thread Monitor in YourKet for the last hour and I get large number of blocks and waits in o.a.jr.core.ItemManager.getItem, getNode and getChildNodes All the threads are read, no writes The blocks appear to come from SlingHttpContext.handleSecurity and SlingMainServlet.doFilter, however these may not be 100% accurate sources. Looking in the code most of those methods are synchronised, which feels wrong as it will make the server single threaded to read, write I can understand, but not read. I thought Jackrabbit was multithreaded on read? Do you know the reasoning behind this ? Ian > > Justin
