Hi,
I found some flaws in the design/implementation/usage of the Monitor
utility. ATM, the code assumes the Monitor as a singleton.
1) DefaultMonitorFactory.createMonitor() returns the same instance
2) The Monitor instance is kept as a state of some extension point or
extension implementations
* 1 & 2 causes problems where multiple nodes are started in the same
NodeFactory. For example, if first Node fails to load the contributions, the
Monitor is populated with a set of problems. When the second Node starts, it
sees the problem from the first Node and gets confused.
3) We can only pass in the resource bundle as a String and assume it can be
found on the classpath of the Monitor/Problem implementations. This will be
problematic in OSGi where Monitor module typically doesn't have dependencies
on other modules.
* I had to add DynamicImport-Package to the Monitor module so that it can
see all the resource bundles under OSGi.
I propose that we improve the Monitor so that it can be used in different
ways.
a) Request-scoped: Pass the Monitor as an argument on the method
b) Thread-scoped: Set a Monitor on the thread so that it can used by all
code running on the same thread (or child threads)
c) System-scoped: Have Node (or other objects) own a Monitor, and the Node
can pass it down to other functions
I prefer to use style a) whenever possible, especially for the methods on
extension points or extensions (including utilities). This gives the full
control to the caller who wants to see the problems without interfering with
other calls. Meanwhile, it keeps the extension points/extensions to be
stateless so that they can be reused in the same runtime by multiple nodes.
On the resource bundle side, we should investigate to see if we should pass
some context (such as the classloader or resource bundle) with the problem
objects so that the Monitor can correctly represent the Problem.
BTW, Eclipse has interesting ideas of the Process Monitor [1]. We can
leverage some ideas from that.
[1] http://www.eclipse.org/articles/Article-Progress-Monitors/article.html.
Thanks,
Raymond
---
Raymond Feng
Apache Tuscany PMC Member: http://tuscany.apache.org
Co-author of Tuscany In Action (A book on Tuscany SCA):
http://tuscanyinaction.com/
