You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2011/01/13 10:14:45 UTC

[jira] Resolved: (SLING-1923) Improve the (internal) resource handling

     [ https://issues.apache.org/jira/browse/SLING-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carsten Ziegeler resolved SLING-1923.
-------------------------------------

    Resolution: Fixed

We now have a four stage processing:

- Installable resource provided by a provider (jcr, file etc.)
- Internal resource copy of the installable resource for processing within the installer
- Registered resource resources for the transformation stage, once transformer task resources are created
- Task resource are the final resources processed by the install task services

Both, registered and task resources, are implemented by the same class

> Improve the (internal) resource handling
> ----------------------------------------
>
>                 Key: SLING-1923
>                 URL: https://issues.apache.org/jira/browse/SLING-1923
>             Project: Sling
>          Issue Type: Improvement
>          Components: Installer
>    Affects Versions: Installer Core 3.0.0
>            Reporter: Carsten Ziegeler
>            Assignee: Carsten Ziegeler
>             Fix For: Installer Core 3.1.0
>
>
> The current resource handling has some drawbacks - one is that a resource is always copied into the local data store even if it did not change; another one is that integrating new concepts like the resource transformer etc is difficult and error prone.
> The first thing we should change is the resource types, currently we have CONFIG and BUNDLE - this assumes that the client knows what resources it is providing - however it is not the task of the client to decide this; in many cases the client has even not the knowledge about it. Therefore we should introduce two new resource types PROPERTIES and FILE.
> However, if the client really knows what it is dealing with, it can use one of the two new types OSGI_BUNDLE or OSGI_CONFIG - we introduce these new types, to be more compatible - the old constants CONFIG and BUNDLE will be deprecated and aliases for PROPERTIES and FILE!
> When a new resource provider is registering itself or an update of resources takes place, merging of resources should be done immediately - the sync first does some general sanity checks on the incoming data and then uses URL and digest of the data to check for updates/removes. If a resource with the same URL and digest is already available, it is assumed to be the same and no further processing is required! This avoids unnecessary copies.
> We further decide between incoming resource type (usually PROPERTIES or FILE) and processing resource type. The new resource transformer services are responsible for this transformation (maybe in combination with data transformation). A resource transformer can omit one or more resources with resource type and data.
> If a resource has a processing resource type, this resource is used to be processed by the osgi installer task factories. As long as the resource has no processing resource type, it is not processed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.