I am trying to tackle the same problem right now, with an additional wrinkle. The public canonical URL for a certain page type is significantly different than the underlying resource path in the repository. Not only will I need to register a servlet with the HttpService for handling inbound requests, but I will also need to rewrite the internal resource path back to the canonical URL in html responses. And unfortunately, a regular expression replacement in a mapping config node is not sufficient for outbound rewriting.
Might there be a recommended way to override the ResourceResolver.map() method with a custom implementation (perhaps with a ResourceDecorator and a wrapping ResourceResolver), or do you think this will require a custom transformer factory? Thanks, Mark Adamcin Acquity Group On Tue, Dec 20, 2011 at 7:37 AM, Felix Meschberger <fmesc...@adobe.com>wrote: > Hi > > Am 20.12.2011 um 16:22 schrieb sam ”: > > > sling.servlet.paths = "/imgs" only registers the servlet for: > > > > GET /imgs > > > > The servlet should be registered for: > > GET /imgs/blah/blah.jpg, too. > > It would also be for > > GET /imgs.ext/blah/blah/blah.jpg > > where /blah/blah/blah.jpg would be the request suffix. > > Other than that, we don't currently have a mechanism in Sling to register > a servlet for a subtree. > > Outside of Sling you could register a servlet for /imgs directly with the > OSGi Http Service. You would just have to provide an OSGi HttpContext > implementation whose handleSecurity method calls the > AuthenticationSupport.handleSecurity method. > > Regards > Felix > > > > > > > > > On Mon, Dec 19, 2011 at 5:42 PM, Alexander Klimetschek > > <aklim...@adobe.com>wrote: > > > >> On 19.12.11 23:35, "Alexander Klimetschek" <aklim...@adobe.com> wrote: > >>> Also, you could put it under /content/imgs or /libs/imgs > >> > >> Ups, I meant /apps/imgs or maybe /etc/imgs (/apps & /libs should usually > >> be closed as much as possible for public instances to avoid any chance > of > >> exposing code or configuration). > >> > >> Chees, > >> Alex > >> > >> -- > >> Alexander Klimetschek > >> Developer // Adobe (Day) // Berlin - Basel > >> > >> > >> > >> > >> > >
