I checked in the changes to make most of the usage of Monitor to be request
scoped. It was a massive commit as it touches quite a lot classes.
* Refactor the ArtifactProcessor/ModelResolver to take a ProcessorContext
that holds context such as Monitor, Contribution for the
contribution/artifact processing methods
* Refactor the Builder to take a BuilderContext that holds context such as
Monitor, Definitions, Base Binding URIs for the building methods
* Change the processor/resolver/builder implementation classes to not cache
the Monitor. They are now complete stateless.
[1] http://svn.apache.org/viewvc?rev=825773&view=rev
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Tuesday, October 13, 2009 10:28 AM
To: <[email protected]>
Subject: Re: [2.x] [DISCUSS] Monitor related issues in Tuscany
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
