Hi, 2012/7/30 Felix Meschberger <[email protected]>: > Hi all, > > I just had a quick look at the current (Rev. 1366999) of the Resource API > (o.a.s.api.resource) and have some remarks on that:
Thanks, really appreciated! The whole stuff is still a work in progress (although it should be functional right now). > > * What is the behaviour of the deprecated PersistableValueMap ? Will > the save method still persist changes (Session.save() in JCR speak) ? Yes, we don't change the behaviour here. > > * What is the spec of the exceptions declared on the new ResourceResolver > methods (delete, addChild) ? They throw NPE if required arguments are null, they throw an unsupported op exception if the path of the resource is not handled by a modifying resource provider. PersistenceException is thrown if something goes wrong. > > * The new ResourceResolver methods commit and revert are spec-ed without > exceptions (except PE on commit). Could there be exceptions thrown like > UnsupportedOperationException ? No, I don't think so - the resolver just delegates to modifying providers. So even if there is no modifying provider, commit or revert do not throw unsupported operation exception as this is the same situation as if there are modifying providers but no changes. > > * I think the ResourceResolver.addChild method should be caled "create" > and the syntax of the "name" argument be defined: is this a simple > name (without slash characters) or a relative path ? If relative path, > what about missing intermediate nodes ? The "name" argument is a name without a slash - an exception is thrown in this case. That's why Bertrand suggested to name this method addChild instead of create to make it clear that the string argument is more a name than a path. I'm fine with addChild and I would be fine with create as well. > > * The JavaDoc of ResourceProviderFactory methods should be fixed (they > look like copied from ResourceResolverFactory) I think they are :) I'll do that. > > * On QueriableResourceProvider: > - I think null is a valid result indicating non-support for > the query language. No results would probably require an empty > iterator. Good idea. > - Thus unsupported query languages just cause the methods to > to return null. Yepp > - A service property should be added (String or String[]) indicating > the query languages supported by the service. For > ResourceProviderFactory provided QueriableResourceProvider > instances this property must be defined on the > ResourceProviderFactory service. Agreed. I'll clarify the javadocs and add the prop. Thanks Carsten > > WDYT ? > > Regards > Felix -- Carsten Ziegeler [email protected]
