The suggested solution is to provide a property (accessed via the bundle context)
which is a hint to the service registry that AttributeFilter.toString() should be
used as a 'native' filter (for those ServiceRegistry implementations that happen to
support string-based filters).

The OSGiServiceRegistry implementation will be enhanced so that when this property is
configured, it will register service listeners using AttributeFilter.toString() along
with the class. These listeners will therefore only be shared between client requests
using the same class and filter string.

This gives users complete control over the filter string passed to the OSGi service
registry while not affecting the public API. It may have a slight impact on memory
because we could end up registering a few more listeners than in the general case,
but certainly nothing major.

Clients using this property must ensure that AttributeFilter.toString() returns a
valid native filter string for whatever service registries they have configured in
their module bindings. (This will be true for almost all users)

This solution is not perfect as the property is bundle-wide, meaning that the hint
applies to all bindings used by a bundle. However additional granularity would only
be possible by extending the API or adding an annotation to the service type - both
of which would introduce more complexity and impact more client code, for not much gain.

TODO: choose an understandable property name...

Suggested property name: "org.ops4j.peaberry.filter.native" (comments welcome)

I also wondered about using an annotation on AttributeFilter instances to say whether
toString() can be used as a native filter. The downside of this approach is that we'd
either have to tag our LDAP AttributeFilter (thereby affecting all users of the LDAP
implementation, regardless of whether they need native filters) or supply two
versions which would then be confusing.

So while the annotation approach is tempting, I think I'll stick with the property
setting for now (unless anyone can convince me that annotations are the way to go).

So...

  "org.ops4j.peaberry.filter.native"

or

  "org.ops4j.peaberry.filter.toString"

thoughts, other suggestions... ?

Hi Stuart,

Another possibility (though entails runtime cost) could be to attempt to convert the
AttributeFilter.toString() to an LDAP filter and if this is successful add it along
side the class lookup.

If you don't like this then for property option I think "native" is more expressive
than "toString" for property key - but obviously your choice.

Regards,

Dave

Hi Dave,

The thing is that would also effect anyone using the provided LDAP implementations of
AttributeFilter (see comment 3). At the moment peaberry registers one listener per
class which is then shared between lookups using different filters - testing shows
this is a sweet spot on the scale from having a singleton listener for all services
(and doing all the filtering in peaberry) to having one lister for each class+filter
combination (and leaving it up to the registry to do the filtering).

One listener per class means we don't create too many listeners, but also we don't
introduce event contention between different service types (which would happen with a
singleton listener).

So ideally I'd like this toString() behavior to only occur when people definitely
need it, which means it can't be based on whether toString() is a well-formed LDAP
expression - because this is going to be true of a lot of filters used by clients
(such as all filters created using the ldap() utility method).

I'm also leaning towards using "native" in the property name, should have it all
coded up this evening - then I'll adapt the existing Spring-DM chainlink example over
the weekend to use peaberry :)

Successfully verified using Newton Framework (http://newton.codecauldron.org)
Will attach the 'chainlink' example code + docs to the wiki later on today.

Minor changes to work with Newton 1.4
(http://newton.codecauldron.org/dist/1.4.0/newton-1.4.0.41.zip), tested with
guice-2.0.jar in peaberry-1.1.1 dir.

	peaberry-1.1.1-newton-example.zip
	76.9 KB Download

The example revised for Newton 1.4.0.41 fails for me on Mac OS X 10.5.7 PowerPC with the following in the 
distributed case:

> cds publish remote examples/peaberry/xml/publish-peaberry-1.1.1.xml peaberry-1.1.1
> installer install examples/peaberry/xml/peaberrychaincli.composite
> installer install examples/peaberry/xml/remote-link-a.composite
> Exception in thread "Thread-46" java.lang.NullPointerException
	at 
org.cauldron.newton.component.impl.ComponentImpl$ComponentServiceAvailabilityListener.serviceAvailable(
ComponentImpl.java:223)
	at 
org.cauldron.newton.implementation.bundle.BundleImplementation.notifyAvailablityListeners(BundleImpleme
ntation.java:234)
	at 
org.cauldron.newton.implementation.bundle.BundleImplementation.access$300(BundleImplementation.java:4
5)
	at 
org.cauldron.newton.implementation.bundle.BundleImplementation$UpdateQueueProcessor.serviceAdded(Bun
dleImplementation.java:353)
	at 
org.cauldron.newton.implementation.bundle.BundleImplementation$UpdateQueueProcessor.run(BundleImple
mentation.java:321)
	at java.lang.Thread.run(Thread.java:613)

In looking at ComponentImpl's ComponentServiceAvailabilityListener's serviceAvailable() method, I see that it 
expects the service name to exist in a map from the name to a target. So apparently either not all services 
have targets, in which case the serviceAvailable() method is naïve and needs to conditionalize the 
manipulation of the target, or there is a bug elsewhere (perhaps in the example's configuration, even?) that 
prevents the service's target from being mapped.

Please let me know if there is any additional color that I can provide on this issue.

Hi Paul,

I have cross posted your issue to Newton Jira

http://jira.codecauldron.org/browse/NEWTON-368

Please follow the comments there.

Gustavo