Hi,
I thought I sent this earlier, but it appears not to have gotten
through (at least not according to markmail). Weird...

------

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)
    }

}

WDYT?

Regards,
Justin

On Wed, Dec 3, 2014 at 3:11 PM, Robert Munteanu <[email protected]> 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
>

Reply via email to