On Thu, Dec 20, 2012 at 1:44 PM, <[email protected]> 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?
Collection<ServiceReference<Handler>> references =
_bundleContext.getServiceReferences(Handler.class, filter.toString());
for (ServiceReference<Handler> 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
> [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
