1. MonitorFactory.createMonitor() now returns a new instance. MonitorFactory
has a few methods to set/get/remove thread context Monitor which is shared
by the same thread.
2. ExtensionPoint or Extension implementations should avoid to cache the
Monitor to keep them stateless
3. Artifact processors, model resolvers and builders now receives the
ProcessorContext or BuilderContext from the methods. The context can be used
to get the Monitor instance of that request.
4. Each Node creates new ProcessorContext/BuilderContext which contains a
new instance of Monitor and pass it down to the processors or builders.
5. Code can create its Monitor for its calling stack if necessary. In such
cases, the Monitor is only visible to its own stack.
I'll look into DefaultValidatingXMLInputFactory .
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Wednesday, October 21, 2009 2:02 AM
To: <[email protected]>
Subject: Re: [2.x] [DISCUSS] Monitor related issues in Tuscany
I haven't been paying close attention to all the Monitor changes,
could someone give a brief summary of how Monitors should be used now?
Specifically how/when they should be created and got hold of? I'm
asking in relation to the new otests failures where Monitors are
created and then get lost so the problems aren't picked up by the
runtime, eg DefaultValidatingXMLInputFactory creates a Monitor in its
constructor which is used for schema validation problems but those
problems don't then get found by the runtime.
...ant
