Thanks for the summary. ...ant
On Wed, Oct 21, 2009 at 4:34 PM, Raymond Feng <[email protected]> wrote: > 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 > >
