Re: [osgi-dev] best pattern for instance factories
If you're worried about lots of handlers (and those handlers are coupled
anyway, then you can always use generics
interface Factory {
T T create(ClassT c) {}
}
You very likely need to clean up because the objects you get from the create
method are somehow tied to implementation classes. There is no need to
unregister them but if the Factory service disappears, you have to remove any
references otherwise you hold on to the class loader. In DS this is trivial if
you use static dependencies. Not cleaning up is sloppy programming and will
hurt you in the end.
In your example I do not understand why you need factories. Why not just
register the handlers and iterate over them? I.e. the whiteboard pattern?
Kind regards,
Peter Kriens
On 19 dec. 2012, at 17:54, Raymond Auge wrote:
On Wed, Dec 19, 2012 at 11:27 AM, Felix Meschberger fmesc...@gmail.com
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
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
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
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] best pattern for instance factories
On Thu, Dec 20, 2012 at 11:14 AM, Peter Kriens peter.kri...@aqute.bizwrote:
If you're worried about lots of handlers (and those handlers are coupled
anyway, then you can always use generics
interface Factory {
T T create(ClassT c) {}
}
You very likely need to clean up because the objects you get from the
create method are somehow tied to implementation classes. There is no need
to unregister them but if the Factory service disappears, you have to
remove any references otherwise you hold on to the class loader. In DS this
is trivial if you use static dependencies. Not cleaning up is sloppy
programming and will hurt you in the end.
In your example I do not understand why you need factories. Why not just
register the handlers and iterate over them? I.e. the whiteboard pattern?
I don't actually want factories, nor do I want to avoid cleanup. But the
system is already built, has been in use for 10+ years, has thousands of
clients with custom extensions, and it's complex.
What I need is a bridge between getting handlers into an existing system
(which probably doesn't do everything right) the legacy way, and a smarter
more plugable, moduler way; all without completely breaking backward
compatibility.
I'm tied to some behaviors of the legacy system, but besides that the
underlying implementation is completely subject to redefinition.
I'll take any suggestions and I'll definitely try yours Peter. I gladly
defer to everyone here's expertise on the matter.
Sincerely,
- Ray
Kind regards,
Peter Kriens
On 19 dec. 2012, at 17:54, Raymond Auge wrote:
On Wed, Dec 19, 2012 at 11:27 AM, Felix Meschberger fmesc...@gmail.comwrote:
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
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
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.*
Re: [osgi-dev] best pattern for instance factories
Ray,
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.
This is a classic use case for the whiteboard pattern; the handler
registers itself as a provider of the Handler service and the event source
uses the framework to track changes in the Handler population. This is
very easy using Declarative Services, but it can also be done with a good
ol' ServiceTracker. That does mean that your handlers have to register
with the framework, but this can be as easy as serviceRegistration =
bundleContext.registerService(Handler.class.getName(), this, new
Hashtable()) on the way in and serviceRegistration.unregister() on the
way out.
HTH
Chris
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] best pattern for instance factories
On Thu, Dec 20, 2012 at 1:44 PM, chris.g...@k-embedded-java.com wrote:
Ray,
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.
This is a classic use case for the whiteboard pattern; the handler
registers itself as a provider of the Handler service and the event source
uses the framework to track changes in the Handler population. This is
very easy using Declarative Services, but it can also be done with a good
ol' ServiceTracker. That does mean that your handlers have to register
with the framework, but this can be as easy as serviceRegistration =
bundleContext.registerService(Handler.class.getName(), this, new
Hashtable()) on the way in and serviceRegistration.unregister() on the
way out.
This is great. I'm glad that I was at least on the right track.
However, I do have some concerns with this:
- currently a handler is instantiated then released (to GC aether)
This insures, among other things, that no state is mistakenly preserved due
to the fact that some handlers actually provide multi-stage lifecycle in
which they may retain instance or local state:
for (Handler handler : ...) {
handler.init(context);
.. some other logic
handler.dosomething();
}
- thread safety (we're not exactly sure that some plugin developer won't
break the system with non-thread safe code) so mitigate that by not letting
their object live beyond the lifecycle of event (granted we could also be
causing a memory leak because they place their handler instance in a
static map or some such.. :-/ )
- low to no contention for simply getting the list of handlers? Namely, was
the bellow example indended to support a high degree of
concurrency/contention?
CollectionServiceReferenceHandler references =
_bundleContext.getServiceReferences(Handler.class, filter.toString());
for (ServiceReferenceHandler reference : references) {
Handler handler = _bundleContext.getService(reference);
handler.init(context);
handler.doSomething();
_bundleContext.ungetService(reference);
}
I'm kind of concerned with the fact that there is an implied registration
here which in this particular scenario sounds either too costly or simply
not nessecary.
Basicly I guess I'm asking how much abuse this pattern can take, say it if
were to trigger potentially thousands of times per request (not all for the
same event handler)?
Perhaps I'm over thinking it problem (or just entirely incorrectly, which
is quite possible)?
- Ray
HTH
Chris
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
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/spain2012http://www.liferay.com/spain2012
16 November 2012 |* Liferay **Italy Symposium* |
liferay.com/italy2012http://www.liferay.com/italy2012
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] best pattern for instance factories
I'm going to test the whiteboard approach and see if that addresses it.
However, again it sounds like I may have to create an awefully large number
of trackers.. like for each event case .. or perhaps not. I'll try that.
Thank you all for indulging me.
Sincerely,
- Ray
On Thu, Dec 20, 2012 at 2:35 PM, Raymond Auge raymond.a...@liferay.comwrote:
On Thu, Dec 20, 2012 at 1:44 PM, chris.g...@k-embedded-java.com wrote:
Ray,
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.
This is a classic use case for the whiteboard pattern; the handler
registers itself as a provider of the Handler service and the event source
uses the framework to track changes in the Handler population. This is
very easy using Declarative Services, but it can also be done with a good
ol' ServiceTracker. That does mean that your handlers have to register
with the framework, but this can be as easy as serviceRegistration =
bundleContext.registerService(Handler.class.getName(), this, new
Hashtable()) on the way in and serviceRegistration.unregister() on the
way out.
This is great. I'm glad that I was at least on the right track.
However, I do have some concerns with this:
- currently a handler is instantiated then released (to GC aether)
This insures, among other things, that no state is mistakenly preserved
due to the fact that some handlers actually provide multi-stage lifecycle
in which they may retain instance or local state:
for (Handler handler : ...) {
handler.init(context);
.. some other logic
handler.dosomething();
}
- thread safety (we're not exactly sure that some plugin developer won't
break the system with non-thread safe code) so mitigate that by not letting
their object live beyond the lifecycle of event (granted we could also be
causing a memory leak because they place their handler instance in a
static map or some such.. :-/ )
- low to no contention for simply getting the list of handlers? Namely,
was the bellow example indended to support a high degree of
concurrency/contention?
CollectionServiceReferenceHandler references =
_bundleContext.getServiceReferences(Handler.class, filter.toString());
for (ServiceReferenceHandler reference : references) {
Handler handler = _bundleContext.getService(reference);
handler.init(context);
handler.doSomething();
_bundleContext.ungetService(reference);
}
I'm kind of concerned with the fact that there is an implied registration
here which in this particular scenario sounds either too costly or simply
not nessecary.
Basicly I guess I'm asking how much abuse this pattern can take, say it if
were to trigger potentially thousands of times per request (not all for the
same event handler)?
Perhaps I'm over thinking it problem (or just entirely incorrectly, which
is quite possible)?
- Ray
HTH
Chris
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
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/spain2012http://www.liferay.com/spain2012
16 November 2012 |* Liferay **Italy Symposium* |
liferay.com/italy2012http://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/spain2012http://www.liferay.com/spain2012
16 November 2012 |* Liferay **Italy Symposium* |
liferay.com/italy2012http://www.liferay.com/italy2012
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] best pattern for instance factories
Raymond Auge wrote:
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.
I wrote:
This is a classic use case for the whiteboard pattern; the handler
registers itself as a provider of the Handler service and the event source
uses the framework to track changes in the Handler population. This is
very easy using Declarative Services, but it can also be done with a good
ol' ServiceTracker. That does mean that your handlers have to register
with the framework, but this can be as easy as serviceRegistration =
bundleContext.registerService(Handler.class.getName(), this, new
Hashtable()) on the way in and serviceRegistration.unregister() on the
way out.
[Ray]
This is great. I'm glad that I was at least on the right track.
However, I do have some concerns with this:
- currently a handler is instantiated then released (to GC aether)
This insures, among other things, that no state is mistakenly preserved
[...]
This is indeed stretching the envelope of the whiteboard pattern, which
is more often used when each handler will be invoked many times during its
lifetime, as opposed to just once.
- thread safety (we're not exactly sure that some plugin developer won't
break the system with non-thread safe code) [...]
In my example you would need to control the lifecycle of the handlers in
order to perform the registration and deregistration, so simply abandoning
them to the tender mercies of GC is probably not an option.
- low to no contention for simply getting the list of handlers? Namely,
was
the bellow example indended to support a high degree of
concurrency/contention?
CollectionServiceReferenceHandler references =
_bundleContext.getServiceReferences(Handler.class, filter.toString());
for (ServiceReferenceHandler reference : references) {
Handler handler = _bundleContext.getService(reference);
handler.init(context);
handler.doSomething();
_bundleContext.ungetService(reference);
}
I'm kind of concerned with the fact that there is an implied
registration
here which in this particular scenario sounds either too costly or
simply
not nessecary.
This code avoids the problem of creating a list of direct references to
the handlers by creating a list of ServiceReferences instead. SRs are
reference-counted, so the get/ungetService calls in this example are
basically just incrementing/decrementing a counter.
If the turnover of the handlers is as high as you say then some degree of
contention is inevitable. A COW list should minimise the impact on the
list traversal.
Basicly I guess I'm asking how much abuse this pattern can take, say it
if
were to trigger potentially thousands of times per request (not all for
the
same event handler)?
I'm still a bit unsure about how your system works. How are all of these
single-use event handlers conjured into existence?
BTW it should be said that Peter Kriens is patron saint of whiteboards, so
you should pay extra attention to what he says on the subject.
- Chris
Perhaps I'm over thinking it problem (or just entirely incorrectly,
which
is quite possible)?
- Ray
HTH
Chris
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
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/spain2012http://www.liferay.com/spain2012
16 November 2012 |* Liferay **Italy Symposium* |
liferay.com/italy2012http://www.liferay.com/italy2012
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] best pattern for instance factories
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 raymond.a...@liferay.comwrote:
On Wed, Dec 19, 2012 at 11:27 AM, Felix Meschberger fmesc...@gmail.comwrote:
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
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
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/spain2012http://www.liferay.com/spain2012
16 November 2012 |* Liferay **Italy Symposium* |
liferay.com/italy2012http://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/spain2012http://www.liferay.com/spain2012
16 November 2012 |* Liferay **Italy Symposium* |
liferay.com/italy2012http://www.liferay.com/italy2012
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] best pattern for instance factories
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
hargr...@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
From: Raymond Auge raymond.a...@liferay.com
To: OSGi Developer Mail List osgi-dev@mail.osgi.org,
Date: 2012/12/19 12:15
Subject:Re: [osgi-dev] best pattern for instance factories
Sent by:osgi-dev-boun...@mail.osgi.org
On Wed, Dec 19, 2012 at 11:27 AM, Felix Meschberger fmesc...@gmail.com
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
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
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
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
