snip... > 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.
As we have changed the design of the Node such that it shares infrastructure with other nodes and hence means that each node must have its own monitor instance I agree that a) is the most satisfactory of these. > > 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. The classloader of the bundle that raised the problem should hold the properties file that needs to be used to provide the message text. I say "should" here as this is not strictly true since we have moved the builders out of assembly. Easy enough to fix but wanted to write that down so we don't forget. Would need to do some work on how we exploit the stored classpath/bundle to retrieve the correct resource bundle and provide it to the logger. Simon
