Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
Description
Mail thread from the mailing list:
http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983ED.1080800%40apache.org%3E
Starting mail:
The resource provider API has grown a lot over time and when we started
with it we didn't really think about potential extensions of the api.
Today, each time we add a new feature, we come up with a new marker
interface. There is also the distinction between a resource provider
(singleton/stateless) and the factory (creating stateful providers).
Although the api is not intended to be used by the average resource api
user (it's an extension), we put it in the same package. And there are
more minor things.
Therefore I think it's time to start a new API that is more future proof
and solves the known problems. I've created a draft prototype at [1].
During the performance analysis by Joel he found out that getParent
calls to a resource a pretty expensive as in the end these are string
based. Therefore, e.g. the JCR implementation can't simply call
getParent on a node and wrap it in a resource. Therefore I think we
should add a getParent(Resource) method to the resource resolver and
have a better way to handle this in a resource provider.
Instead of having a resource provider and a resource provider factory,
we define a single ResourceProvider which is a singleton. If this
provider needs authentication and/or needs to keep state per user, the
PROPERTY_AUTHENTICATE needs to be set to true and in this case the
authenticate method is called. This one returns a data object which is
passed in to each and every method. If auth is not required, the method
is not called and null is passed in as the data object.
For authentication, providers do not support login administrative
anymore, just users and service users.
A provider is mounted at a single root - no more support for mounting it
at different path at the same time; and a provider always owns the root.
So if a provider does not return a resource for a given path, no other
provider is asked. This allows for improved implementations and resource
resolving. If we decided that we need this for compatibility we can
solve it differently.
Instead of using marker interface, we define the ResourceProvider as an
abstract class. This allows us to add new methods without breaking
existing providers.
Each method gets a ResolveContext, containing the resource resolver,
the previously mentioned state data object and other things, e.g. the
parameter support recently added to the resource resolving. In the
future we can pass in additional data without breaking the interface.
Apart from that the resource provider is similar to the aggregation of
the already existing marker interfaces. There are two exceptions,
observation and query which I'll handle in different emails.
Attachments
Issue Links
- breaks
-
-
- Open
-
- incorporates
-
-
- Closed
-
- is related to
-
-
- Closed
-
- supercedes
-
-
- Resolved
-
-
-
- Closed
-