hello david. thanks a lot for the quick prototype - that was exactly what i thought of.
unfortunately further experimenting with this enhanced functionality it still does not work fort solving the "nested configuration" usecase - i currently cannot think of an elegant way to bring it together with the converter concept, because always the underlying resource hierarchy is involved as well. see this comment [1] and svn ref [2] for details. stefan [1] https://issues.apache.org/jira/browse/SLING-5982?focusedCommentId=15433697#comment-15433697 [2] http://svn.apache.org/viewvc/sling/trunk/contrib/extensions/contextaware-config/impl/src/main/java/org/apache/sling/contextaware/config/impl/ConfigurationBuilderImpl.java?r1=1757438&r2=1757437&pathrev=1757438 >-----Original Message----- >From: David Bosschaert [mailto:[email protected]] >Sent: Tuesday, August 23, 2016 5:12 PM >To: [email protected] >Subject: Re: [Converter] Flexible Adpater Rule convert A to X and vice >versa > >Hi Stefan, > >I have prototyped more flexible adapter rules a little bit and committed >the current state to the Converter codebase. > >The adapter now tries to find the most specific adaptation rule available >for a given conversion, but it walks up the class hierarchy. So you could >specify that you want to convert from ValueMap.class to Object.class where >object will behave as a full wildcard. > >Then, if you use the Rule class [1] to specify the adapter rule, you >receive a callback to the following functional interface method [2]: > T convert(F obj, Type targetType) > >which gives you access to the target type that the object needs to be >converted to. You can also return the special value CANNOT_CONVERT >indicating that the adapter rule cannot handle a given conversion. > >You can see some examples in the following testWildcardAdapter() test case >[3]. > >Would this help you with your use-case? > >Best regards, > >David > >[1] >https://svn.apache.org/viewvc/felix/trunk/converter/src/main/java/org/osgi/ >service/converter/Rule.java?view=markup >[2] >https://svn.apache.org/viewvc/felix/trunk/converter/src/main/java/org/osgi/ >service/converter/ConvertFunction.java?view=markup >[3] >https://svn.apache.org/viewvc/felix/trunk/converter/src/test/java/org/apach >e/felix/converter/impl/AdapterTest.java?view=markup#l71 > > >On 22 August 2016 at 10:43, David Bosschaert <[email protected]> >wrote: > >> Hi Stefan, >> >> I see the use-case and in a different context I also came across a >> use-case for 'wildcards' in the rules. I think this would be a good >> feature. I'll try to prototype something for that over the coming few >days >> and ping back here once I have something to try out. >> >> Cheers, >> >> David >> >> On 19 August 2016 at 23:16, Stefan Seifert <[email protected]> >wrote: >> >>> we want to use the converter service as part of the sling context-aware >>> configuration, and started with a first implementation. [1] >>> >>> in sling we have a special form of map (a ValueMap) which supports >>> additional features like typed access (with a resource provider-specific >>> conversion magic under the hood), and support for nested maps. we want >to >>> map such valuemaps to annotation classes. this is working fine, but it >does >>> not use the special valuemap typed methods, and nested classes are not >>> supported either because the child resources are not represented as >nested >>> maps in the valuemap. >>> >>> what we need is a custom rule to provide some code to the converter how >>> to handle the valuemap specifics. but neither the current converter >>> implementation nor the API defined in [2] seems to support this >currently. >>> >>> what is supported are rules von converting class A to B and vice versa, >>> but A and B have to be well-known. what we need is A to X and vice >versa, >>> where A is well-known, but X can by any class (e.g. any project-specific >>> annotation class). details what we want to do described in [3]. >>> >>> is it planned to add such a more flexible rule to the specification (and >>> implementation)? in the current implementation only one of the rule- >related >>> methods are implemented. >>> >>> stefan >>> >>> [1] https://svn.apache.org/repos/asf/sling/trunk/contrib/extensi >>> ons/contextaware-config >>> [2] https://github.com/osgi/design/raw/master/rfcs/rfc0215/rfc- >>> 0215-object-conversion.pdf >>> [3] https://issues.apache.org/jira/browse/SLING-5982 >>> >>> >>> >>
