Folks,

2009/7/28 Simon Laws <[email protected]>

> Some thoughts on B-1.
>
> I'm looking at the otests and, because of the way the build is set up
> at the moment, some of the types that policy intents constrain are not
> found. A warning is raised to point this out and I would like to add
> appropriate context to this warning. The information I think is
> appropriate in this case is:
>
> Contribution name
>  definitions file name
>     intent name *
>       missing constrained type name *
>
> Those items marked * are already included in the warning by the
> current code as follows.
>
> warn("ConstrainedTypeNotFound", intent, extensionType, intent);
>
> So I need to be able to add the contribution name and the definitions
> file name. The stack that leads to this particular warning is as
> follows.
>
> Thread [main] (Suspended (breakpoint at line 241 in IntentProcessor))
>        IntentProcessor.resolveContrainedTypes(Intent, ModelResolver) line:
> 241
>        IntentProcessor.resolve(Intent, ModelResolver) line: 313
>        IntentProcessor.resolve(Object, ModelResolver) line: 1
>
>  
> DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(Object,
> ModelResolver) line: 416
>        ExtensibleStAXArtifactProcessor.resolve(Object, ModelResolver) line:
> 196
>        DefinitionsProcessor.resolve(Definitions, ModelResolver) line: 201
>        DefinitionsProcessor.resolve(Object, ModelResolver) line: 1
>
>  
> DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(Object,
> ModelResolver) line: 416
>        ExtensibleStAXArtifactProcessor.resolve(Object, ModelResolver) line:
> 196
>        DefinitionsDocumentProcessor.resolve(Definitions, ModelResolver)
> line: 199
>        DefinitionsDocumentProcessor.resolve(Object, ModelResolver) line: 1
>
>  
> DefaultURLArtifactProcessorExtensionPoint$LazyURLArtifactProcessor.resolve(Object,
> ModelResolver) line: 357
>        ExtensibleURLArtifactProcessor.resolve(Object, ModelResolver) line:
> 121
>        ContributionContentProcessor.resolve(Contribution, ModelResolver)
> line: 226
>        ContributionContentProcessor.resolve(Object, ModelResolver) line: 1
>
>  
> DefaultURLArtifactProcessorExtensionPoint$LazyURLArtifactProcessor.resolve(Object,
> ModelResolver) line: 357
>        NodeFactoryImpl.configureNode(NodeConfiguration, List<Contribution>)
> line: 504
>        ...
>
> As you can see the two items are not available in the intentProcessor.
> This is nearly always the case when doing read/write/resolve as the
> interfaces are very simple. So given B-2 we could thrown and exception
> and add the context higher up. This is not an option here though as
> it's a warning and I don't want to disrupt the processing. So I'll
> have to extend the resolve interface to allow context to be passed
> down. So how should this be provided? For example,
>
> Change
>
> void resolve(M model, ModelResolver resolver) throws
> ContributionResolveException;
>
> To be
>
> void resolve(M model, ModelResolver resolver, MonitorContext context)
> throws ContributionResolveException;
>
> Where MonitorContext would be something like
>
> class MonitorContext {
>  List<String> contextInfo;
>  ...
> }
>
> I'm laboring this point as this is going to affect a *lot* of things
> if I dive in and start changing these interfaces. I rather only do it
> once.
>
> Simon
>

Please let's not go down this road. The Monitor is already available in
these classes - add the context information in the Monitor and there is no
need to go adding explicit context parameters to all the method calls.

The Monitor is there for error reporting.  So let's use it for that purpose.
Place the context into the Monitor.


Yours,  Mike.

Reply via email to