Watch/unwatch on Import

[mcculls]

Originally reported on Google Code with ID 43

Usually one will watch the changes of services related to an import so an 
watch/unwatch method on the import will be useful and makes no harm. 
This watch / unwatch should have only one parameter: the service watcher.

Reported by adreghiciu on 2009-09-28 07:56:31

[mcculls]

Hi Alin - are you suggesting adding these two methods to Import<T> ?

This would be a major change because Import is a key type that forms the basis of the
peaberry design. It's meant to be simple as possible so I would be extremely wary of
any change that added methods here, especially as it could lead to more entanglement.

Could you provide a concrete use-case to show how this would be used, and how you
can't achieve the same behaviour using the existing API?

Reported by mcculls on 2009-09-28 08:30:07

[mcculls]

Using the current API the only "easy" way to add a service watcher is via the static
usage 
of Peaberry fluent api. But if, as in my case, I only have the imports I cannot get
from 
the Import what are the settings for that import such as class of imported service
or 
attributes filter.

I'm not keen of getting this into the Import interface. I just want an easy way, that
given 
an Import, I can watch it.

Reported by adreghiciu on 2009-09-28 08:45:42

[mcculls]

What you describe still isn't a use-case imho, but more an implementation approach.
Could you elaborate on what you're trying to solve that requires watching any given
Import? Note that you can get the attributes (including objectClass) from the Import
but some of those will be unrelated to the filtering so, as you say, this can't tell
you what the filter was that selected the import to begin with...

The current design allows Imports to be shared between registries. In that sense
specifically watching an Import itself doesn't make sense as the Import doesn't
change. It comes and goes from registries, and so the registry is really what you watch.

Reported by mcculls on 2009-09-28 09:08:04

[mcculls]

You are right about the fact that I do not watch an import but a service registry. The

only thing I need from the import is the imported service interface and the attribute

filter.
What I actually want to watch is the service under the import. The service that I get

by calling get(). So I "watch" when a service is bounded/ unbounded.

UC: I want to be able to watch changes on the imported service but allow the 
configuration (actual binding) to be done by a user of my functionality. This means

that I do not know upfront the filter that the user will use, so I can make the call
to 
"watch". (But this would require to be able to inject Import<Service> ;) )

Reported by adreghiciu on 2009-09-28 09:34:13

[mcculls]

Use case:

Using an whiteboard pattern I'm watching for Servlets that I automatically register
with 
an HttpService. In this case my whiteboard watcher should be able to re-register the

watched servlets  with the http service if the http service changes.
This is a functionality I provide and a user of this functionality is the one that
actually 
does the binding of the watched servlets (via Iterable<...>) and the http service (maybe

filtering on attributes)

Reported by adreghiciu on 2009-09-28 09:52:30

[mcculls]

This still looks more like 'how' to do something, than 'what' it solves. Also direct
injection of Import<T> is definitely discouraged unless you really know what you're
doing, and are prepared to handle proper cleanup of services yourself.

Perhaps you could put it in terms of an external user: what are you trying to solve
for them (ie. external functionality)? Note that if you want to intercept a user's
bindings you could give them a utility class to simplify configuration, which could
then also record what settings they use.

My gut feeling is that this is probably solvable with the current API - and that if
a
change is required, it is likely to be something like a binding introspection API
rather than a change to Import<T>.

(Especially as there is no direct link between an Import<T> and the original filter)

Reported by mcculls on 2009-09-28 09:53:01

[mcculls]

OK, the situation described in #c5 sounds definitely doable using the current API. Do
you have a prototype somewhere or is this still in the design stage?

Reported by mcculls on 2009-09-28 09:56:37

[mcculls]

@comment #6

Binding introspection API sounds good to me. As I told you I just need a way to get
to 
the service interface / attribute filter for a certain imported service, not that it
must be 
in the Import iface.

Reported by adreghiciu on 2009-09-28 10:02:09

[mcculls]

Reported by mcculls on 2012-08-04 21:53:39

• Status changed: WontFix