Christopher Armstrong wrote:
Hi
Would it be possible in your case to inject the Handler objects into the
code that uses them via a setter method? You haven't specified what
bundle is using the handlers, so I'm assuming that there is a third
bundle C that uses the Manager in A to get access to handlers.
If you publish each handler with a service property containing the ID
into the service registry, you can use something like Spring DM or OSGi
Declarative Services to search the service registry for a particular
handler (based on ID or some other property) and inject it into the
POJOs in bundle C. Spring DM and OSGi DS do this declaratively in XML
like Spring so you can implement your strategy pattern without the need
for a third "Manager" object.
I'm working with spring-dm. Generally, I don't like the fact that I now
need to inject everything. As for my real use case, it is not possible,
since the code requires several Handler objects.
Ittay
Ignore this if I've misinterpreted the problem.
Cheers
Chris
On Mon, 2009-04-27 at 22:07 +0300, 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Tikal <http://www.tikalk.com>
Tikal Project <http://tikal.sourceforge.net>
