Comments for BasePatterns.org http://basepatterns.org Trends in software design Tue, 06 Oct 2009 22:37:18 +1100 http://wordpress.org/?v=2.9 hourly 1 Comment on OSGi Service Locator by fortuna http://basepatterns.org/2009/09/osgi-service-locator/comment-page-1/#comment-27 fortuna Tue, 06 Oct 2009 22:37:18 +0000 http://basepatterns.org/?p=74#comment-27 <a href="#comment-21" rel="nofollow">@Costin Leau</a> Hi Costin, Thanks I probably should have made the point that the <em>Service Locator</em> pattern is possibly the least desirable mechanism for retrieving service references in an OSGi context, due to the dynamic nature of service availability that you mention. Sometimes however (particularly when dealing with legacy code and third-party libraries), approaches such as the <a href="http://www.osgi.org/wiki/uploads/Links/whiteboard.pdf" rel="nofollow">whiteboard pattern</a> and/or <em>Dependency Injection</em> may not be applicable. In such cases a Service Locator may be considered (albeit with caution!). regards, ben @Costin Leau

Hi Costin,

Thanks I probably should have made the point that the Service Locator pattern is possibly the least desirable mechanism for retrieving service references in an OSGi context, due to the dynamic nature of service availability that you mention.

Sometimes however (particularly when dealing with legacy code and third-party libraries), approaches such as the whiteboard pattern and/or Dependency Injection may not be applicable. In such cases a Service Locator may be considered (albeit with caution!).

regards,
ben

]]> Comment on OSGi Service Locator by Costin Leau http://basepatterns.org/2009/09/osgi-service-locator/comment-page-1/#comment-21 Costin Leau Wed, 30 Sep 2009 17:03:12 +0000 http://basepatterns.org/?p=74#comment-21 One thing to add - one must not forget about the OSGi dynamics: a service can be unregistered at any time so ideally, on each call, the client would locate the service, invoke the methods needed and then discard the instance. Otherwise, if the service gets unregistered, any further invocations will lead to unpredictable behaviour. There are frameworks that handle this case (among other features) in a non invasive fashion (using dependency injection) - I'll mention the ones I know best, namely Spring DM and OSGi Blueprint Services. Cheers, Costin Leau Lead, Spring Dynamic Modules One thing to add – one must not forget about the OSGi dynamics: a service can be unregistered at any time so ideally, on each call, the client would locate the service, invoke the methods needed and then discard the instance.
Otherwise, if the service gets unregistered, any further invocations will lead to unpredictable behaviour.

There are frameworks that handle this case (among other features) in a non invasive fashion (using dependency injection) – I’ll mention the ones I know best, namely Spring DM and OSGi Blueprint Services.

Cheers,
Costin Leau
Lead, Spring Dynamic Modules

]]> Comment on Ghost in the machine by Branko http://basepatterns.org/2006/05/ghost-in-the-machine/comment-page-1/#comment-6 Branko Thu, 25 May 2006 13:11:53 +0000 http://blogs.modularity.net.au/thenextbigthing/?p=8#comment-6 Intelligence and everything else may have happened already. Assuming that it has, then the physical world we live in exists as such to allow us to make a physical journey through it. Through this journey, both we and computer systems alike are destined to evolve into intelligent thinking machines. Therefore it probably will happen automatically, as you say. Intelligence and everything else may have happened already. Assuming that it has, then the physical world we live in exists as such to allow us to make a physical journey through it. Through this journey, both we and computer systems alike are destined to evolve into intelligent thinking machines. Therefore it probably will happen automatically, as you say.

]]>