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='(&(service.intents=confidentiality)(service=service)(objectClass=my.componenttest.Server)(mandatory:<*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]
