Hi, On 22.10.2010 17:24, Justin Edelson wrote: > Thanks Felix. > > Perhaps this should just be configurable. I can see the pre-1842 behavior > being useful in dev, but the post-1842 being preferable in production.
Not so sure: The SLING-1842 behaviour was absolutely strict: no error handling (except a single error message in the log) if the response has been committed. This means: error handlers are not called at all and the new error level filters are called neither. What we could make configurable, though, is what the Sling error handler (the DefaultErrorHandler from the Engine and the configurable error handler support in the Servlet Resolver) do when called .... For now, they just write into the response (optionally resetting the response if possible) ... we could limit this ... Regards Felix > > Justin > > On Oct 22, 2010, at 10:56 AM, Felix Meschberger <fmesc...@gmail.com> wrote: > >> Hi all, >> >> I found the problem: The exceptions are not written back into the >> responses any more because I recently cleanup what is getting written >> back to the client in case of an error: >> >> As part of SLING-1842 I also modified the error handlers to not write an >> error stuff into the response if the response cannot be reset. The idea >> here is to not interfere with any content already sent back... >> >> But maybe, this is a completely wrong assumption and this should be >> reverted ... Done with SLING-1850. >> >> Regards >> Felix >> >> [1] https://issues.apache.org/jira/browse/SLING-1842 >> [2] https://issues.apache.org/jira/browse/SLING-1850 >> >> On 20.10.2010 22:27, Sandro Boehme wrote: >>> Hi Justin, >>> >>> I get the two test failures: >>> testMaxCallsDetection(org.apache.sling.launchpad.webapp.integrationtest.JspIncludeTest) >>> >>> testInfiniteLoopDetection(org.apache.sling.launchpad.webapp.integrationtest.IncludeTest) >>> >>> Attached you find more detailed information and logs. >>> >>> Best, >>> >>> Sandro >>> >>> Am 20.10.10 21:34, schrieb Justin Edelson: >>>> Sandro- >>>> If you get a chance, please try out trunk now. I just committed a fix >>>> which seems to be working for me, but it'll be a while before Hudson >>>> confirms. >>>> >>>> Thanks, >>>> Justin >>>> >>>> On 10/20/10 3:21 PM, Sandro Boehme wrote: >>>>> I'm glad it was not a user error ;-). The problem simply was, that I >>>>> checked out the trunk while it was not yet working properly. >>>>> I should have had a look at the hudson build before updating from trunk. >>>>> Using git (git://git.apache.org/sling.git) now to be able to easily >>>>> revert my local experiments to the last working version of the trunk >>>>> (right now this should be commit 129f4d btw). >>>>> >>>>> Best, >>>>> >>>>> Sandro >>>>> >>>>> Am 20.10.10 01:23, schrieb Sandro Boehme: >>>>>> Hello, >>>>>> >>>>>> mvn clean install of sling on a fresh checkout from trunk did not show >>>>>> any errors. Also running Jetty works and all bundles are active. But >>>>>> the >>>>>> scripts of the Sling Explorer don't get executed and the >>>>>> HtmlRendererServlet is show like that: >>>>>> ========================================================= >>>>>> >>>>>> >>>>>> Resource dumped by HtmlRendererServlet >>>>>> >>>>>> Resource path: */index.html* >>>>>> >>>>>> Resource metadata: *{sling.creationTime=1287529282337, >>>>>> sling.contentType=text/html, sling.resolutionPathInfo=.explorer.html, >>>>>> sling.modificationTime=1287528833921, sling.contentLength=5898, >>>>>> sling.resolutionPath=/index.html}* >>>>>> >>>>>> Resource type: *nt:file* >>>>>> >>>>>> Resource super type: *-* >>>>>> >>>>>> >>>>>> Resource properties >>>>>> >>>>>> jcr:createdBy: *admin* >>>>>> jcr:created: >>>>>> *java.util.GregorianCalendar[time=1287529282337,areFieldsSet=true,areAllFieldsSet=true,lenient=false,zone=sun.util.calendar.ZoneInfo[id="GMT+02:00",offset=7200000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2010,MONTH=9,WEEK_OF_YEAR=43,WEEK_OF_MONTH=4,DAY_OF_MONTH=20,DAY_OF_YEAR=293,DAY_OF_WEEK=4,DAY_OF_WEEK_IN_MONTH=3,AM_PM=0,HOUR=1,HOUR_OF_DAY=1,MINUTE=1,SECOND=22,MILLISECOND=337,ZONE_OFFSET=7200000,DST_OFFSET=0]* >>>>>> >>>>>> >>>>>> >>>>>> jcr:primaryType: *nt:file >>>>>> * >>>>>> >>>>>> ========================================================= >>>>>> *The bundle of the Sling Explorer is marked active in the console. >>>>>> * >>>>>> >>>>>> Also the simple script from the 15min tutorial that renders the title >>>>>> property does not get executed. Instead the HtmlRendererServlet dumps >>>>>> the Resource like that: >>>>>> ========================================================= >>>>>> >>>>>> >>>>>> Resource dumped by HtmlRendererServlet >>>>>> >>>>>> Resource path: */content/mynode* >>>>>> >>>>>> Resource metadata: *{sling.resolutionPathInfo=.html, >>>>>> sling.resolutionPath=/content/mynode}* >>>>>> >>>>>> Resource type: *foo/bar* >>>>>> >>>>>> Resource super type: *-* >>>>>> >>>>>> >>>>>> Resource properties >>>>>> >>>>>> title: *some title* >>>>>> sling:resourceType: *foo/bar* >>>>>> jcr:primaryType: *nt:unstructured >>>>>> *========================================================= >>>>>> >>>>>> The curl commands that create the WebDAV folders and upload the script >>>>>> are executed successfully. And via WebDAV I can see that the script is >>>>>> there (/apps/foo/bar/html.esp). >>>>>> >>>>>> I debugged some resolver classes, searched at Google and tried to >>>>>> find a >>>>>> solution to that for quite some time now. But I have no idea left. >>>>>> Does somebody have a hint what I could try to get it working? >>>>>> >>>>>> Best, >>>>>> >>>>>> Sandro >>>>>> >>>>>> >>>>> >>>> >>>> >>> >
