On Wed, Apr 9, 2008 at 12:49 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:
>
>
> On Wed, Apr 9, 2008 at 12:00 PM, Hasan Muhammad <[EMAIL PROTECTED]> wrote:
>
> > Hi Simon,
> >
> > I am on revision 634808. The ContributionServiceImpl has changed since
> > then,
> > and with the one that i have, it would lead through the
> > CompositeProcessor
> > instead of the CompositeDocumentProcessor. Hence the difference in
> > exceptions..
> >
> > Also, dont you think that with the error that you got should throw an
> > exception with schema validation, rather than just a warning?
> >
> > Hasan
> >
> > On Wed, Apr 9, 2008 at 6:36 AM, Simon Laws <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Tue, Apr 8, 2008 at 2:58 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > Hi Simon,
> > > >
> > > > Thank you for the good information. First up i am trying to verify
> > > whether
> > > > the schema validation works when we point to our schemas. Can you
> > let me
> > > > know what is a simple error that i can introduce so that i can
> > verify
> > > > this?
> > > > I tried doing this to my composite file (In block red):
> > > >
> > > > <component name="MyServiceComponentNew">
> > > > <implementation.java
> > > class="mysca.test.myservice.impl.MyServiceImpl"/>
> > > > *<binding.ws/>*
> > > > <property name="location" source="$newLocation"/>
> > > > <property name="year" source="$newYear"/>
> > > > </component>
> > > >
> > > > This resulted in the following exception, but i think this is part
> > of
> > > the
> > > > validation done by artifact processor and would result even if we
> > > comment
> > > > out the schema validation.
> > > >
> > > >
> > org.apache.tuscany.sca.contribution.service.ContributionReadException:
> > > > Unexpected <binding> element found. It should appear inside a
> > <service>
> > > or
> > > > <reference> element
> > > > at
> > > >
> > > >
> > >
> > org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:373)
> > > > at
> > > >
> > > >
> > >
> > org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:75)
> > > > at
> > > >
> > > >
> > >
> > org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.read(ExtensibleStAXArtifactProcessor.java:83)
> > > > at
> > > >
> > > >
> > >
> > org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:475)
> > > > at
> > > >
> > > >
> > >
> > org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:383)
> > > > at
> > > >
> > > >
> > >
> > org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202)
> > > > at
> > > >
> > > >
> > >
> > com.ibm.ws.soa.sca.runtime.impl.DomainCompositeHelper.addContribution(DomainCompositeHelper.java:75)
> > > > at
> > > >
> > > >
> > >
> > com.ibm.ws.soa.sca.runtime.impl.SCAContainerComponentImpl.startComposite(SCAContainerComponentImpl.java:235)
> > > > at
> > > >
> > > >
> > >
> > com.ibm.ws.soa.sca.admin.runtime.tuscany.SCATuscanyRuntimeHandlerImpl.startModule(SCATuscanyRuntimeHandlerImpl.java:125)
> > > > at
> > > >
> > > >
> > >
> > com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:349)
> > > > at
> > > >
> > > >
> > >
> > com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:446)
> > > > at
> > > >
> > > >
> > >
> > com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:331)
> > > > at
> > > >
> > > >
> > >
> > com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:126)
> > > > at
> > > >
> > > >
> > >
> > com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:281)
> > > > at
> > > >
> > > >
> > >
> > com.ibm.ws.runtime.component.CompositionUnitMgrImpl$CUInitializer.run(CompositionUnitMgrImpl.java:768)
> > > > at
> > > >
> > > >
> > >
> > com.ibm.wsspi.runtime.component.WsComponentImpl$_AsynchInitializer.run(WsComponentImpl.java:348)
> > > > at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1487)
> > > >
> > > >
> > > > regards
> > > >
> > > > On Tue, Apr 8, 2008 at 5:56 AM, Simon Laws <
> > [EMAIL PROTECTED]>
> > > > wrote:
> > > >
> > > > > 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
> > > > >
> > > >
> > >
> > > Hi Hasan
> > >
> > > The change you suggest should cause a schema validation error. I made
> > the
> > > change locally in samples/calculator and see the following output in
> > > stdout
> > >
> > > 08-Apr-2008 22:41:54
> > >
> > org.apache.tuscany.sca.contribution.processor.ValidatingXMLStreamReader$1
> > > error
> > > WARNING: XMLSchema validation problem in: null, line: 28, column: 5
> > > cvc-complex-type.2.4.a: Invalid content was found starting with
> > element '
> > > binding.ws'. One of '{"http://www.osoa.org/xmlns/sca/1.0":include, "
> > > http://www.osoa.org/xmlns/sca/1.0":service, "
> > > http://www.osoa.org/xmlns/sca/1.0":property, "
> > > http://www.osoa.org/xmlns/sca/1.0":component, "
> > > http://www.osoa.org/xmlns/sca/1.0":reference, "
> > > http://www.osoa.org/xmlns/sca/1.0":wire, WC[##other:"
> > > http://www.osoa.org/xmlns/sca/1.0"]}' is expected.
> > > 08-Apr-2008 22:41:54
> > >
> > >
> > org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
> > > read
> > > WARNING: Element
> > > {http://www.osoa.org/xmlns/sca/1.0}binding.ws<http://www.osoa.org/xmlns/sca/1.0%7Dbinding.ws>
> > <http://www.osoa.org/xmlns/sca/1.0%7Dbinding.ws>cannot be
> > > processed. ([row,col {unknown-source}]: [28,5])
> > >
> > > No exception is raised though.
> > >
> > > Let me take a look at what has changed.
> > >
> > > Simon
> > >
> >
>
> Ok, thanks for that Hasan. I see the change you are referencing. I'm not
> sure why the exception is no longer thrown. The code is still in the
> CompositeProcessor to trap the case but maybe the offending element is
> removed from the stream because of the validation warning.
>
> I would argue that we shouldn't mandate that an exception is thrown in
> this case but that the validation mechanism is opened up to the monitor API
> so that a monitor can be attached and those who are embedding tuscany can
> decide how they want to deal with errors like this.
>
> Simon
>
>
>
Hi
I've just been through the original list again looking at what happens with
validation types errors (by which I mean a workspace type admin console
would reasonably want to display based on user input/changes). This is what
I found.
- Contribution processing
- dependency (imports/exports) analysis
org.apache.tuscany.sca.workspace.builder.impl.ContributionDependencyBuilderImpl
uses a ContributionDependencyBuilderMonitor
- Composite read
- schema compliance
org.apache.tuscany.sca.contribution.processor.DefaultValidatingXMLInputFactory
Uses writes to local JDK Logger
- policy intent matching
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor
Throws exceptions
- extension availability
General artifact processor hierarchy
Throws exceptions
- SCA compliance, e.g. annotation correctness
General artifact processor hierarchy
Throws exceptions
- Composite resolve
- ensure that artifacts required by the composite are available
General artifact resolver hierarchy
Throws exceptions
- 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
uses a CompositeBuilderMonitor
I would like to look for a more consistent approach across these various
elements of validation. The aim being to make it more obvious how to
recognize validation type errors and act accordingly. There has been a
relatively lengthy debate about how to group and report errors in [1] which
is worth a read. The scenarios I have in mind are workspace administration
type scenarios where, for example, A user may
Add a contribution and be notified that contributions that it depends on are
not available
Look at a composite and be notified that there are XML and/or SCA errors
etc.
>From [1] we want to capture as many errors as possible before reporting back
to the user. Two things come immediately to mind.
1 - Pull up the Monitor API and make it more generic (and from previous
comments here make it an extension point)
2 - Rely on a Tuscany specific JDK logger and remove the monitor (or at
least don't extend it further).
I'm going to think some more about these options. Any thoughts or more
options?
Simon
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg29878.html
