On Mon, Apr 7, 2008 at 4:33 PM, Hasan Muhammad <[EMAIL PROTECTED]> wrote:
> Currently, i see that we have various places where we can plug in
> validation
> monitoring. Some of the ones that i found are in the
> ReallySmallRuntimeBuilder as shown below:
>
> public static CompositeBuilder createCompositeBuilder(AssemblyFactory
> assemblyFactory,
> SCABindingFactory
> scaBindingFactory,
>
> IntentAttachPointTypeFactory intentAttachPointTypeFactory,
>
> InterfaceContractMapper interfaceContractMapper,
> List<PolicySet>
> domainPolicySets) {
> return new CompositeBuilderImpl(assemblyFactory, scaBindingFactory,
> intentAttachPointTypeFactory, interfaceContractMapper, domainPolicySets,
> null);
> }
>
> public static DomainBuilder createDomainBuilder(AssemblyFactory
> assemblyFactory,
> SCABindingFactory scaBindingFactory,
> IntentAttachPointTypeFactory intentAttachPointTypeFactory,
> InterfaceContractMapper interfaceContractMapper,
> List<PolicySet> domainPolicySets) {
> return new DomainWireBuilderImpl(assemblyFactory,
> scaBindingFactory,
> intentAttachPointTypeFactory, interfaceContractMapper, domainPolicySets,
> null);
> }
>
> Instead of passing null, we can pass in our own CompositeBuildMonitor. Are
> these the only places where we need to do this? or are there other places
> as
> well?
>
> Hasan
>
Hi Hasan
There are a few places that logically we need to be able to validate input
and hence add monitors. The story is changing a little as we are moving
toward the new "workspace" code for managing contributions but logically I
would expect to be running validating on at least the following
- Contribution processing
- dependency (imports/exports) analysis
[org.apache.tuscany.sca.workspace.builder.impl.ContributionDependencyBuilderImpl]
- Composite read
- schema compliance
[org.apache.tuscany.sca.contribution.processor.DefaultValidatingXMLInputFactory
- only appears to be initialized in ReallySmallRuntimeBuilder so need to
look at this in context of workspace]
- policy intent matching
[org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor]
- extension availability [General artifact processor hierarchy]
- Composite resolve
- ensure that artifacts required by the composite are available [General
artifact resolver hierarchy]
- Composite build
- ensure that the composite is valid and consistent, e.g. unique
component names, valid reference targets etc.
[org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl]
I've noted in the square brackets where this function currently is. Note
also that I'm making no comment here about whether the construction of the
in-memory composite model is for use purely for contribution processing or
is going to activated and started in a runtime. This validation is
appropriate in both cases although you may choose to use different monitors
in the two cases.
So what I suggest as a first step is that you go ahead and change
ReallySmallRuntimeBuilder to plug a monitor into CompositeBuilderImpl to see
how it works. We can work here to build a consistent view of
- all the places a monitor is required
- what should the plugin model for monitors be
- the flow of control (monitors vs exceptions)
- what extra features may be required, I18N etc.
I'm going to try a few experiments too to familiarize myself with this a bit
more.
Regards
Simon
