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 <[email protected]>wrote: > > > > 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> > > -- *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
