Uploaded image for project: 'Sling'
  1. Sling
  2. SLING-4750

New Resource Provider API




      Mail thread from the mailing list:

      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.



        Issue Links



              rombert Robert Munteanu
              cziegeler Carsten Ziegeler
              0 Vote for this issue
              6 Start watching this issue