Hello Richard,
Thank you for your reply. Moving up to the very latest level causes me
other problems. I have a resource class that implements
org.osgi.service.obr.Resource. When I call Resolver.add(myResource) I
get a ClassCastException:

Caused by: java.lang.ClassCastException:my.resources.MyResource
incompatible with
org.apache.felix.bundlerepository.impl.wrapper.ResourceWrapper
        at 
org.apache.felix.bundlerepository.impl.wrapper.Wrapper.unwrap(Wrapper.java:59)
        at 
org.apache.felix.bundlerepository.impl.wrapper.ResolverWrapper.add(ResolverWrapper.java:40)
        at my.provisioning.impl.OBRProvisioner.resolve(OBRProvisioner.java:496)

Looking at Wrapper.java:

    public static Resource unwrap(org.osgi.service.obr.Resource resource) {
        return ((ResourceWrapper) resource).resource;
    }

I've passed in a class that implemented obr.Resource which this code
is attempting to cast to ResourceWrapper: this fails. We got there
via,

   // ResolverWrapper.java
   public void add(org.osgi.service.obr.Resource resource) {
        resolver.add(Wrapper.unwrap(resource));
    }

At no time was my Resource wrapped before it was unwrapped. I'm
porting from 1.4.1 to 1.6 and so may not have understood the new API.
Can my resource still implement org.osgi.service.obr.Resource
directly? What am I missing?

In the meantime I'll see if I can find an version between 1.4.1 and
1.6. Thank you!

Regards,
Mark

On 27 April 2010 22:22, Richard S. Hall <[email protected]> wrote:
> On 4/27/10 9:55, Mark Nuttall wrote:
>>
>> Hello,
>> I wonder if anyone can help me in my attempt to write a filter that
>> resolves against a complex property. I am using
>> org.apache.felix.bundlerepository-1.4.1.jar. I have constructed a
>> repository including a resource with,
>>
>> <capability name='service'>
>> <p n='service' v='service'/>
>> <p n='osgi.service.blueprint.compname' v='server'/>
>> <p n='objectClass' t='set' v='my.componenttest.Server'/>
>> <p n='service.ranking' v='0'/>
>> <p n='service.intents' t='set' v='propagatesTransaction,confidentiality'/>
>> <p n='mandatory' v=''/></capability>
>>
>> I am attempting to resolve a set of requirements including a service
>> reference,
>>
>> <require extend='false' multiple='false' optional='false'
>> name='service'
>> filter='(&amp;(service.intents=confidentiality)(service=service)(objectClass=my.componenttest.Server)(mandatory:&lt;*service))'>
>>
>> This test worked until I added the service.intents property into the
>> resource and filter. Resolver.resolve() now fails. The first value
>> returned by getUnsatisfiedRequirements() is,
>>
>>
>> (&(service.intents=confidentiality)(service=service)(objectClass=my.componenttest.Server)(mandatory:<*service))
>>
>>  When I use a debugger to inspect ResolverImpl I am surprised to see
>> that m_admin.m_repoMap[0].value.m_resources[2].m_capList[1].m_map[4]
>> has a key of 'service.intents' and a char[37] value of
>> 'propagatesTransaction,confidentiality' - i.e. it's just a simple
>> String or char array with a comma in: there's bo indication that the
>> value was of t='set'.
>>
>
> I am not sure what it's not matching, but I'd expect the value to be just a
> string because the right-hand side is always a string in an LDAP filter, it
> is only coerced to a different type based on the left-hand side when the
> comparison is made. Looking at the code in FilterImpl, you can see this
> happening for the set operations:
>
>    if (op == SUBSET || op == SUPERSET)
>    {
>        StringSet set = new StringSet(s);
>        if (op == SUBSET)
>        {
>            return set.containsAll((Collection) obj);
>        }
>        else
>        {
>            return ((Collection) obj).containsAll(set);
>        }
>    }
>
> So, otherwise, I'm not sure. Did you try against the newer version of OBR?
>
> -> richard
>
>> So far I have been able to take my OSGi blueprint reference's runtime
>> filter syntax and use that directly when constructing my OBR filters.
>> Am I doing something obviously wrong? I am worried that OBR might be
>> expecting some sort of set-specific filter syntax instead of
>> (service.intents=confidentiality) - that would be a problem since at
>> the point of parsing the blueprint xml I can not know whether the
>> service property service.intents is multiple or not.
>>
>> I'd be very grateful for some assistance! Thank you!
>>
>> Regards,
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to