You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Mark Nuttall <mn...@apache.org> on 2010/04/27 15:55:35 UTC
Problem filtering against a complex property
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'.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problem filtering against a complex property
Posted by Mark Nuttall <mn...@apache.org>.
Thank you Guillaume, I've raised
https://issues.apache.org/jira/browse/FELIX-2306
Regards,
Mark
On 28 April 2010 12:06, Guillaume Nodet <gn...@gmail.com> 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 <mn...@apache.org> 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 <he...@ungoverned.org> 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: users-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> > For additional commands, e-mail: users-help@felix.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problem filtering against a complex property
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <mn...@apache.org> 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 <he...@ungoverned.org> 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: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Problem filtering against a complex property
Posted by Mark Nuttall <mn...@apache.org>.
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 <he...@ungoverned.org> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problem filtering against a complex property
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org