It looks like the best solution is not to register the Manager, but
register the Handlers ...
This is called the whiteboard pattern and greatly simplifies your
code. Everthing seems to fall in place then. If you do not want the
code that uses the Handler services to know about OSGi, use
Declarative Services, simple and small.
Kind regards,
Peter Kriens
On 27 apr 2009, at 21:07, Ittay Dror wrote:
Hi,
I'd like to get some advice about design patterns in OSGi, I hope
this is appropriate (not being felix specific).
I have a bunch of Handler objects and a Manager that retrieves them
by id.
interface Manager {
Handler get(String id);
}
The Manager implementation is an OSGi service that uses OSGi as the
registry of Handlers. So internally, it finds a ServiceReference
using a filter containing the id as a value to some property.
The question is how can it return the Handler? If it uses its own
bundle context to retrieve the service reference, then it will look
as if that bundle is using the service, which is not correct, also,
there's a question of how the services are released.
I can rewrite the interface to be OSGi specific, but I don't like
that because:
1. it means client code needs to know OSGi
2. it hurts unit testing the client code (with the above interface I
can easily create a mock manager implementation)
So, any suggestions as to how to design this case?
Thank you,
Ittay
--
Tikal <http://www.tikalk.com>
Tikal Project <http://tikal.sourceforge.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
