microsling homepage

Sling request processing, reduced to the max!

Overview

The goal of microsling is to demonstrate the Sling HTTP request processing in the simplest possible way, to help the community converge on the goals and architecture of this module.

microsling test links

• Content creation forms : use this page to create content and test the rendering mechanisms.
• Velocity templates : explains how to use Velocity templates to render content.
• Server-side javascript and ESP templates : explains how to use server-side javascript and javascript-based ESP templates to process requests.
• FreeMarker templates : explains how to use FreeMarker templates to render content.

Show me the code

Here's a brief description of how microsling processes HTTP requests. Follow the links to the source code for more details.

• The main MicroSlingServlet handles HTTP requests. That's probably where you want to start studying the code.
• RequestFilter objects process the incoming requests before passing them on to SlingServlet objects which do the actual processing.
  • The ResourceResolverFilter selects the Resource (currently a JCR Node, OCM is not used yet) to process.
  • The ResponseContentTypeResolverFilter computes the desired Content-Type for the response, so that rendering scripts or SlingServlets know what output format to generate.
  Other filters would include Locale selection, client capabilities analysis, etc.
• After applying the RequestFilters, the MicroSlingServlet selects a SlingServlet to process the request. The first SlingServlet where canProcess(...) returns true is used.
• The SlingRequestContext is stored as a request attribute, and gives access to Sling-specific objects (Resource, repository Session, etc.) used for request processing.
• A few SlingServlet classes are implemented (source code here):
  • The SlingPostServlet allows Nodes to be created by POSTing to URLs ending with ".sling".
  • The VelocityTemplatesServlet and RhinoJavascriptServlet execute server-side scripts in those languages to process requests.
  • The DefaultSlingServlet is used when no other SlingServlet wants the request.
• The SlingScriptResolver is used by the scripting SlingServlet classes to locate scripts in the repository. See comments in that class for how script paths are computed based on the Resource's resourceType and the request method and extension.
• Rendering scripts can generate various output formats, for example a Velocity script named "get.xml.vlt" will cause a page with Content-Type=text/xml to be generated by the VelocityTemplatesServlet.
• The microsling architecture allows additional scripting engines (JSP, JRuby, BSF,...) to be plugged in easily - and this would of course be much easier with OSGi.
• We'll probably need a ResponseFilter interface at some point, but for now it's not needed. It could be useful to apply "rendering standards" to the output, adding header/footers/glitter to HTML pages for example.

If you have followed the links to source code in the above descriptions, you've seen most or all of the interesting microsling source code. What's remaining are a few simple support classes.

No OSGi

To keep things simple, microsling does not use OSGi. We will of course continue to use OSGi in the real Sling, and there are many places in the code which say TODO - use OSGi plugins here. Keeping things "static" for this example makes it easier to concentrate on the basics.

More test links

• repository-info, dumps the JCR repository properties.
• WebDAV mount point: use this URL to mount the repository via WebDAV (login = admin/admin).