Thank you, Scott.  That's unfortunate, but it's an answer.

Thanks Scott. Do you know what the turn around time is for this type of request?

Thanks, but I am familiar with setting the cq:layout to editbar. My question is specifically about setting the layout to auto. The documentation describes auto as "The choice is left to the client side code". I interpret this as meaning that the choice between editbar and rollover is made at page render time, determined by some client code (JSP/JavaScript/something else?). I am looking for an example or documentation for the "client code" that would dictate which layout to use.EDIT: you beat me ...

*bump*

Thank you again, Kunal. I had already searched for the source of SlingRequestProcessorImpl for setStatus, and found none; I did, however, overlook the calls to sendError, which I suppose my wrapper also needs to implement, in order to set status code. Once again, thank you.

kunal23 wrote... I guess you used the RequestResponseFactory service to get the dummy request, response objects for sending a request to the SlingRequestProcessor. The request, response objects this service creates are just mock objects and they do not have any implementation of setStatus and getStatus methods. To get the status of the response you can create your own response class implementing the HTTPServletResponse interface. In the setStatus method you can set the value passed in the method...

Another excellent response, thank you so much.

Happy to help. I've seen several other individuals trip over this before as well. I'm not sure how it is that the problem is so common, as it seems to require that a user delete/renames a node that they should not, but it does seem to happen alarmingly frequently. I'd love to see Adobe make the Projects and Site Admin interfaces more durable, so they don't just fail silently under these conditions.