sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <>
Subject Re: Everything is a Resource
Date Thu, 03 Jan 2008 10:42:37 GMT

This sounds like "reinventing the wheel"....

Am Donnerstag, den 03.01.2008, 12:18 +0200 schrieb Jukka Zitting:
> No. I'd use nodes for configuring Servlets and Filters and have a
> mechanism in the Sling framework for mapping those configuration nodes
> to the runtime instances of the components they represent.

These runtime instances are OSGi services. Each service is registered
with a set of properties. In Sling we generally use the Declarative
Services specification. That is, each service has a declaration, and the
Declarative Services implementation (called SCR for Service Component
Runtime) cares for managing instantiation, registration and dependency

So, each servlet or filter we register in Sling, always has properties
and the filter.scope and filter.order properties are just part of the
service descriptor. In fact, it is generally only the filter coder, who
knows the correct values for these properties. So they are generally
defined at programming time not at run time.

Filter Programmers do not expect the casual user (or the administrator)
to tamper with these values if not foreseen by the filter programmer.

In addition to that: Consider a filter (or servlet) packaged into a
bundle. How would the "initial configuration" come into the repository ?
Of course we have the content loader, but then a filter (or servlet)
programmer would do the following:

   1. Create the Filter (or Servlet)
   2. Care for defining the Descriptor for SCR
   3. Add initial content for the JCR

We already have support for 1. and 2. in place. 3. would just be another
step with additional error possibilities.

> This way you could use normal JCR editing tools for configuring and
> modifying the application.

Well, another thing, which already has been taken care of by OSGi:
Through the Configuration Admin Service, configuration of service
properties is very easy. And the Configuration Admin integrates nicely
with the Declarative Services.

So everything is already in place for these properties to be
configurable, provided the programmer agrees in configurability of the

>  Even better, with scripting support the
> filter nodes could even be nt:files (or contain nt:files) with the
> actual filter script that you could then modify in-place.

Well, my "Everything is a Resource" paradigm IMHO better solves this


View raw message