FYI, I have made a design proposal for Core R6 to allow prototype scope services which can create multiple service objects for a client bundle. For backwards compatibility reasons, this will require both the producer and consumer to "opt-in" to using prototype scope services. The design proposal also includes updated to DS and Blueprint to allows easy use of the new feature.
But this does not help you now... :-( -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Raymond Auge <[email protected]> To: OSGi Developer Mail List <[email protected]>, Date: 2012/12/19 12:15 Subject: Re: [osgi-dev] best pattern for instance factories Sent by: [email protected] 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é | Senior Software Architect | Liferay, Inc. --- 24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012 16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012 _______________________________________________ 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
