On Mon, Dec 21, 2015 at 10:30 AM, Stefan Seifert <sseif...@pro-vision.de> wrote: > >>I know. But I don't want to deploy the Sling mocks library as a bundle >>along with my Sling-based application to the OSGI container (haven't >>checked if it's a bundle at all). I also don't want to embedd this jar file >>into a custom bundle just because I need these few classes. > > sling-mocks is definitely not supposed to be deployed in an OSGi container > (and will fail due to unresolvable internal dependencies if tried to). it's > only supposed for unit test environment. > > refactoring the servlet api mocks from sling-mock to a separate and > lightweight bundle would be an option. imho it should be a separate bundle > instead of including them in the sling API. > > here are the classes > https://svn.apache.org/repos/asf/sling/trunk/testing/mocks/sling-mock/src/main/java/org/apache/sling/testing/mock/sling/servlet > > most of them have no dependencies except some to commons-lang and guava which > could be eliminated if required. > > if there is need for using them standalone please create a ticket. > > stefan
Since this is about utilizing the SlingRequestProcessor [1], some handy/convenient light-weight implementations of request and response would be pretty beneficial here. I've seen quite a number of projects end up having to make their own implementations of the request and response classes to utilize the request processor, which is the path Jörg here is implicating he's needing to go down currently as well. I think it'd be something for the Sling project to look at evaluating here to make SlingRequestProcessor's usage more convenient going forward. Or at least, that's my opinion. - Steven [1] https://sling.apache.org/apidocs/sling8/org/apache/sling/engine/SlingRequestProcessor.html
