[ 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.