You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Ittay Dror <it...@tikalk.com> on 2009/04/27 21:07:48 UTC
osgi design pattern question
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>
Re: osgi design pattern question
Posted by Christopher Armstrong <ca...@fastmail.com.au>.
Hi
On Tue, 2009-04-28 at 05:39 +0300, Ittay Dror wrote:
> >
> 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.
IMHO, I don't see how you can avoid "injection" without actually
coupling against an API. You will either be coupled against OSGi's API,
or your own method for obtaining the handlers (Manager.get() method). If
you're not keen on setter injection, I believe iPOJO supports field
injection (which means that you'll only need to write instance variable
declaratios instead of methods). Spring DM might to too heavyweight for
your needs, but if you're already using it for something else (like its
JMS or JTA helpers) its probably best to stick with that.
I don't really see the problem with injection if you only have a few
handlers per POJO, but if you have dozens or need to manage them
dynamically, you may want to rethink how you're going about things. OSGi
supports service filtering based on an OSGI filter expression, which may
better suit your requirements (as you can construct the string at
runtime in a helper class and use that to obtain the services).
Furthermore, if you need to inject an array of handlers, it should be
possible to do that too.
Cheers
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: osgi design pattern question
Posted by Ittay Dror <it...@tikalk.com>.
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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
--
Tikal <http://www.tikalk.com>
Tikal Project <http://tikal.sourceforge.net>
Re: osgi design pattern question
Posted by Christopher Armstrong <ca...@fastmail.com.au>.
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.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: osgi design pattern question
Posted by Ittay Dror <it...@tikalk.com>.
For those interested, I found this:
http://wimpi.coalevo.net/2007/09/osgi-design-practice-loose-coupling.html
Executive Summary:
* Manager has an internal registry (hash with ids as keys)
* Handlers are added / removed from the registry by using a listener
Ittay
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>
>
--
Tikal <http://www.tikalk.com>
Tikal Project <http://tikal.sourceforge.net>
Re: osgi design pattern question
Posted by Ittay Dror <it...@tikalk.com>.
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 <it...@tikalk.com> 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>
Re: osgi design pattern question
Posted by Toni Menzel <to...@okidokiteam.com>.
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.
Tonii
On Mon, Apr 27, 2009 at 9:07 PM, Ittay Dror <it...@tikalk.com> 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>
>
>
--
Toni Menzel
Independent Software Developer - Looking for new projects!
Professional Profile: http://www.osgify.com
Blog: tonitcom.blogspot.com
toni@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
Re: osgi design pattern question
Posted by Peter Kriens <pe...@aqute.biz>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org