Toni Menzel wrote:
Hi Uttay,
solution is not necessarily osgi specific.
You "lifecycle" problem sounds good to apply dynamic proxy,
invokationhandler and friends.
Have a look at
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/reflect/Proxy.html
This way you can easily get and unget the real service reference.
Thank you for your reply.
I'm working with spring-dm which does a lot with proxies, yet, I'm not
sure this is the right solution here.
The Manager is created in bundle A and used in bundle B. So when it
returns a Handler proxy, it can only return it with reference to bundle
A's context. But I want the service to be gotten from bundle B's context.
Ittay
Tonii
On Mon, Apr 27, 2009 at 9:07 PM, Ittay Dror <[email protected]> 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>
--
Tikal <http://www.tikalk.com>
Tikal Project <http://tikal.sourceforge.net>
