Thank you Guillaume, I've raised https://issues.apache.org/jira/browse/FELIX-2306
Regards, Mark On 28 April 2010 12:06, Guillaume Nodet <[email protected]> wrote: > Could you raise a JIRA for that ? > I think we'd have to wrap the resource the other way for this use case to > work again. > > On Wed, Apr 28, 2010 at 09:06, Mark Nuttall <[email protected]> wrote: > >> 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='(&(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] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
