felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seifert <sseif...@pro-vision.de>
Subject RE: [Converter] Flexible Adpater Rule convert A to X and vice versa
Date Tue, 23 Aug 2016 22:05:35 GMT
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:david.bosschaert@gmail.com]
>Sent: Tuesday, August 23, 2016 5:12 PM
>To: dev@felix.apache.org
>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 <david.bosschaert@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 <sseifert@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
>>>
>>>
>>>
>>
Mime
View raw message