ResourceProvider implementation seems to be what I need.
@Component
@Service
@Properties({
@Property(name = ResourceProvider.ROOTS, value={"/imgs"})
})
public class SyntheticResourceProvider implements ResourceProvider {
@Override
public Resource getResource(ResourceResolver resourceResolver, String
path) {
log.info("getResource: path: {}", path);
return new SyntheticResource(resourceResolver, path, "saml");
}
Then, I can create a servlet:
@Component
@Service
@Properties({ @Property(name="service.description", value="Hello World Type
Servlet"),
@Property(name="service.vendor", value="The Apache Software
Foundation"),
@Property(name = "sling.servlet.resourceTypes", value = "saml")
})
public class ByResourceTypeServlet extends SlingSafeMethodsServlet {
And, these work
GET /imgs/foo/bar.html
GET /imgs/foo/bar.xml
GET /imgs/foo/bar.jpg
On Tue, Dec 20, 2011 at 1:18 PM, Colin Flanagan <[email protected]>wrote:
>
> Could a SlingOptingServlet be adapted for this purpose?
>
>
> On Dec 20, 2011, at 10:37 AM, Felix Meschberger <[email protected]>
> 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
> >> <[email protected]>wrote:
> >>
> >>> On 19.12.11 23:35, "Alexander Klimetschek" <[email protected]> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >
>
