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
