Hi all,
let me sum up the discussion a bit:
Advantages of JCR are the visibility, explorability and easy
editability with standard tools (eg. mount as webdav, use your
operating systems file system support). Combined with the paradigm
"Everything is content" and pure scripting, Sling is simple and
everything of it gains from JCR's advantages.
Now with the use of the OSGi platform in Sling, developing java
servlets is better due to a much better software lifecycle support.
But this needs an additional abstraction to include nodes, servlets
and services (IIUC, correct this list if I am wrong) called Resource.
These Resources are another tree, automatically combined based on
registered OSGi services (including servlets or even scripts)
configured by the service properties (e.g. filter.scope or
filter.order) and based on the JCR tree of nodes with content and
scripts (using sling:resourceType and some /apps, /libs etc.
convention for placing scripts inside the repository).
The main problem of the resource tree is that it is completely
virtual, ie. it is invisible, non-explorable, non-editable (and not
standardized, both the structure nor the API) - which are IMHO more or
less serious drawbacks against pure JCR. This is independent whether
you are a strict content vs. "managed" code or "everything is
content" (even scripts) supporter, because it makes the runtime
structure of the framework much more visible, which is important for
debugging and understanding existing systems.
So why not making this resource tree visible somehow. Either by
displaying it inside the sling web console or by making it a virtual
part if the JCR repository - but I don't know how to technically
achieve that. But this way the resource tree would be even accessible
by a standardized API.
Alex
--
Alexander Klimetschek @iPhone
[EMAIL PROTECTED]
Am 03.01.2008 um 11:42 schrieb Felix Meschberger <[EMAIL PROTECTED]>:
Hi,
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
management.
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
properties.
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
issue.
Regards
Felix
