Ok, I think what I may need is in fact a Handler registry service whereby bundles get the handler service and register any handler instances they have by event type.
Later when an event requires processing, the handler service is called to locate handlers by type. This is pretty much the osgi EventAdmin I believe. On Wed, Dec 19, 2012 at 11:54 AM, Raymond Auge <[email protected]>wrote: > On Wed, Dec 19, 2012 at 11:27 AM, Felix Meschberger <[email protected]>wrote: > >> Hi, >> >> Am 19.12.2012 um 17:12 schrieb Raymond Auge: >> >> Hello All, >> >> I'd like to asked what is the suggested method for creating instance >> factories according to the service pattern. >> >> i.e. I would like to obtain a list of stateless instances which are >> single use and which are subsequently simply collected. >> >> >> Maybe you just register a service which happens to be the factory: >> >> public interface FooFactory { >> Foo createFoo(...) >> } >> >> Clients would get the FooFactory service and call the createFoo method to >> get Foo instances. Assuming these are throwaway instances. >> > > > Ok, sigh, this just means I have lots of boiler plate code to write (each > Impl will need a "service" which generates it). I'm trying to fit an > existing pattern into a more modular design and we have tons of event > handlers. > > > >> >> >> I'm thinking service factory but I'm not sure if there are further >> implications regarding the registration of outputted instances, like >> automatic tracking of service references. >> >> >> ServiceFactory is not what you are looking for: This is just a kind of >> factory managed by the framework such that each bundle getting the service >> in fact gets its own instance. In other words with the ServiceFactory >> pattern you get delayed service object creation plus more freedom in >> creating the services -- but at most one instance per requesting bundle. >> >> >> Effectively I would like to simply register (a factory) to an interface >> as usual, and later get the list of matching services.. but the output >> would be stateless pojos which I later don't have to "unget" as it were. >> >> >> You mean the Foo objects will also be registered as services on their own >> once created ? >> > > > In fact the opposite. The Foo instances would never be registered anywhere > and would be thrown away after use, a stateless event handler for instance. > > > >> In this case you will have to do some cleanup, service unregistration, at >> the end. >> > > > This is what I'm hoping to avoid because it means significant management > overhead on a very large scale. > > > >> >> If you want this the Declarative Services ComponentFactory components >> come to mind: You define the Foo class as a ComponentFactory component. To >> get insances consumers get ComponentFactory service registered on behalf of >> the Foo service and call its newInstance(Dictionary) method. This creates >> Foo instances and if declared as services also registers them. The drawback >> is, that you have explicitly dispose off these instances for cleanup. >> > > I don't think this fits either. > > What we have is a typical event handler scenario: > > processEvent(Event event) { > Handler[] handlers = getHandlers(key); > > for (Handler handler : handlers) { > handler.process(event); > } > } > > I'd like to be able to use osgi to affect the handlers result set during > runtime. > > > Thanks for your help. > > - Ray > > >> >> Regards >> Felix >> >> >> Make sense? >> >> - Ray >> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay, > Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> > > --- > > 24-25 October 2012 |* Liferay **Spain Symposium* | > liferay.com/spain2012<http://www.liferay.com/spain2012> > > 16 November 2012 |* Liferay **Italy Symposium* | > liferay.com/italy2012<http://www.liferay.com/italy2012> > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay, Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> --- 24-25 October 2012 |* Liferay **Spain Symposium* | liferay.com/spain2012<http://www.liferay.com/spain2012> 16 November 2012 |* Liferay **Italy Symposium* | liferay.com/italy2012<http://www.liferay.com/italy2012>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
