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/apache/felix/converter/impl/AdapterTest.java?view=markup#l71 On 22 August 2016 at 10:43, David Bosschaert <david.bosscha...@gmail.com> 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 <sseif...@pro-vision.de> 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 >> >> >> >
