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>
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
