Hi Justin,
On Wed, Dec 3, 2014 at 10:19 PM, Justin Edelson
<jus...@justinedelson.com> wrote:
> Hi,
> I thought I sent this earlier, but it appears not to have gotten
> through (at least not according to markmail). Weird...
It came through as a separate email with a new subject. Anyway ...
>
> ------
>
> Hi,
> One ongoing problem (which has been a bit exacerbated by Sling Models)
> is when code depends upon the AdapterManager being able to handle a
> particular adaptation. Right now, the only way to deal with this is by
> listening for the AdapterManager events. But these events aren't
> particularly easy to deal with; it would be easier if this was based
> on the service registry.
>
> What I would like to see is that the AdapterManager registers some
> kind of marker service when an adaptation is available.
>
> From the consuming side, it would look like this:
>
> @Component
> @Service
> @Reference(referenceInterface=Adaptation.class,
> target="(&(adaptable=com.myco.MyClass)(adaptable=org.apache.sling.api.Resource))")
> public class Foo {
>
> public void doSomething(Resource resource) {
> MyClass cfgMan =
> resource.adaptTo(MyClass.class)
> }
>
> }
That sounds like a workable way forward. The obvious advantage
compared to the current situation is that we can reliably wait for an
adaption to be available. The downsides IMO are:
- you have to know about this mechanism to use it
- it's a very slight abuse of the service registry, we don't actually
need or use that service anywhere
But for me the trade-offs in making the adaptable mechanism more
stable are worth it. I think you also mentioned in a separate
discussion that we can have a SCR annotation that generates this
reference, which is ideal, something like
@RequiresAdapter(adaptable=Resource.class, adapter=MyClass.class)
( BTW, I think your example @Reference should have adapter=...MyClass,
not adaptable=...MyClass )
Cheers,
Robert
>
> WDYT?
>
> Regards,
> Justin
>
> On Wed, Dec 3, 2014 at 3:11 PM, Robert Munteanu <romb...@apache.org> wrote:
>> Hi,
>>
>> I recently became aware of the following scenario ( and many thanks to
>> David Bosschaert for pointing out why it's failing ).
>>
>> - Bundle A exports package com.foo and registers an adapter factory for
>> com.foo.Service
>> - Bundle B imports com.foo from Bundle A and calls
>> slingRequest.adaptTo(com.foo.Service.class)
>>
>> When Sling starts up, it's perfectly legal for Bundle B to be STARTED
>> while Bundle A is just RESOLVED. This means that while com.foo.Service
>> does not have an AdapterFactory registered, bundle B will call
>> slingRequest.adaptTo(com.foo.Service.class), which will unexpectedly
>> return null.
>>
>> The only 'solution' I see to this is documenting this scenario so that
>> it's less suprising to others.
>>
>> I briefly considered using an OSGi manifest header to declare provided
>> and required adapter factories, but unfortunately you can't always know
>> what the klazz object will be at runtime when writing
>>
>> slingRequest.adaptTo(klazz)
>>
>> Thoughts? Other ideas?
>>
>> Thanks,
>>
>> Robert
>>
--
Sent from my (old) computer
