The API being developed in the context of SLING-2973 - [Tooling] Align Eclipse tooling to proposed structure Closed is very complex and also not consistently used all over the code yet ( SLING-3089 - Investigate using the same model between the repository sync and the Sling (JCR) content provider Open and SLING-4043 - The JCR properties view does not display escaped properties with escaped values correctly Open ). Also the API in the current form has some drawbacks: SLING-3733 - Remodel API for more natural usage of IO operations Open , SLING-3684 - Executed commands should expose the fine-grained operations that have been performed Open , SLING-3780 - Enrich the ResourceProxy model to hold more information about the property metadata Open .
The refactored API being outlined in this page should address those concerns. Feel free to discuss this approach on the dev mailing list and directly add comments.
Resource in Sling.
Instances are retrieved/created through the
Represents a resource with properties and ordered child resources (tree structure).
No easy way to get the parent of an existing
ResourceProxy (but shouldn't be necessary)
For reading it provides the methods
List<ResourceProxy> getChildren()return values should be java.util.Collections.unmodifiableList(...)
Map<String, Object> getProperties()immutable, clarify which types are supported, only array types but not collection types for multivalue properties!
Object getMetaData(String name)custom meta data depending on the
ResourceManagerbeing used to create this instance. E.g. node type (for JCR) or file path (for ResourceProxies being created through a FS backed manager).
For writing it optionally provides the methods
boolean setProperty(String key, Object value)
valuecould be array type, no collections are supported
ResourceResolver in Sling.
ResourceManagerFactory.getResourceManager(Type, Credentials, URI).
ResourceProxy getResource(String path)may support lazy loading?
putResource(ResourceProxy parent, String name, Map<String, Object> metaData)
reorderChildResources(ResourceProxy parent, String name, String afterName)not supported by Sling API though so may not have an effect when being serialized/pushed to a server
deleteResource(ResourceProxy parent, String name)
boolean validate(ResourceProxy parent, ResourceProxy child), validates if the given ResourceProxy child is valid (e.g. might validate if there are node type restrictions being violated)
AutoClosableand release all underlying resources (i.e. closing the remote repository and get rid off all http connections or closing file handles/input streams)
commit()for persisting the changes
JCR DavEx Implementation
Uses remote JCR API calls through Sling's DavEx Support bundle.
FileVault FS Implementation
Uses filesystem calls together with the FileVault Serialization Manager. Maybe even some more code from Jackrabbit FileVault can be reused.
Package Manager Implementation
Probably not that useful, but may use package manager ReST API for mass-transfers. Would need to create the serialization format though internally.
Problem is that one
ResourceProxy is not necessarily bound to one serialization file. FileVault sometimes packages more than one resource in one XML file and sometimes a
ResourceProxyis split up into multiple files (e.g. to separately store binary properties, see http://jackrabbit.apache.org/filevault/vaultfs.html).
SerializationData serialize(ResourceProxy, int depth, OutputStream)
ResourceProxy deserialize(InputStream)may support lazy loading of Resource proxies!
FileVault Serialization Manager
- Should use ContentParser
SerializationManager must have access to NodeTypeRegistry!