>Ok, this would mean the following I think: >1. move/copy on the resource resolver >2. optional move/copy on a provider >3. if the resource resolver impl detects that a move is within a >provider, it calls the move/copy on the provider >4. if the move/copy is across providers, the resource resolver impl does >this brute force.
perfect! >> 4. is it good to have only an abstract class? this makes mocking more >difficult. I would prefer to have an interface plus an abstract class. >> if one decides not to use the abstract class he has the risk to get >problems on additions, but the interface is clean. > >Having both will lead to the problem that once we add stuff to the >interface, a provider might not work (resolve) anymore. You'll find the >approach with the abstract class in some OSGi specs and it seems to work >pretty well. >I'm not an expert, but I think mocking of abstract classes is not a problem. yes, seems so: http://stackoverflow.com/a/4317631 - ok >> 5. for what are the getAttribute/getAttributeNames properties? do they >return OSGi properties? makes this sense? or what else is returned for what >purpose? >This is already part of the current provider interface. Providers can >provide attributes which are available through the respective resource >resolver calls. hmm, did not see them in the existing interface? https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceProvider.java stefan
