Re: [sca-assembly] Conformance test instantiation

On Mar 2, 2010, at 4:17 PM, Mike Edwards wrote:

Jim,

I apologise that I never responded to this email - it got put to one side in a busy period just before
Christmas and only your recent email reminded me that it still needed to be dealt with.

I've added inline replies.

Yours, Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com

Jim Marino <jim.marino@gmail.com> wrote on 13/12/2009 16:44:54: > [image removed]
> > [sca-assembly] Conformance test instantiation
> > Jim Marino
> > to:
> > OASIS Assembly
> > 13/12/2009 16:49
> > Hi, > > I have another question related to the assembly conformance tests. I'm > confused about the RuntimeBridge.startContribution(..) API: > > /** > * Start the contribution(s) which represent the application under > test in the SCA runtime > * @param contributionLocation a String containing the location > pattern for the contribution(s), > * which is a URI containing one or more "%1" substrings where the > name of the contribution is > * substituted to get the URI of the contribution > * @param contributionNames - an array of contribution names as strings > * @return true if the contributions were loaded and started in the > SCA runtime, false otherwise > */ > boolean startContribution(String contributionLocation, String[] > contributionNames) throws Exception; > > My understanding is the contributionLocation is an encoded location > for the contributions which must be installed. A URL for each > contribution can be derived by iterating the contributionNames and > substituting %1 in contributionLocation with the contribution name. My > first question then is why doesn't RuntimeBridge make this contract > explicit and use a collection of URLs instead: > > boolean startContribution(List<URL> contributions) throws Exception; >

Yes, I can see the merits of this, which basically means moving the current
URI resolution code from the runtime bride implementation back into the
BaseJAXWSTestRunner class.

Yes, otherwise this forces the runtime bridge to make assumptions about the parameters that is not codified in the API, e.g. they can be turned into URLs through substitution. It also forces bridge implementations to provide code that can be generalized.

> Related to this, I noticed the following entry in oasis-tests- > sca.properties: > > org.oasis.sca.tests.assembly.contribution.location=file:/C:/ > OASIS_TESTS/SCA-Assembly/TestCases/%1/target/%1.zip > > I think this could just be handled programmatically by default using > an offset relative from the location of a .class file for one of the > test classes (e.g. RuntimeBidge.class.getResource(".") ). However, if > the RuntimeBridge API is modified to pass a collection of URLs this is > less of an issue (although it requires a bit of extra setup which > could be eliminated). >

No, I don't agree with this approach. This is where we started out and
the requirement to have the Contributions located in a location relative
to some Java class known to the test runner code eventually caused a whole
load of hassle. It is very inflexible.

The newer approach using the properties file and the substitution string
works well and requires minimal setup. I prefer to stay with that.

I'm not following why this is a hassle. From a design point of view, shouldn't the test harness provide the location of the contribution to the runtime bridge as opposed to providing an out-of-band mechanism (the properties file). What problems were encountered and why was it inflexible?

> My second question is what contributions are expected to be started in > RuntimeBridge.startContribution(..)? I see from the > TuscanyRuntimeBridge implementation that it pulls a composite name > from an instance of TestConfiguration that is provided via > RuntimeBridge.setTestConfiguration(). However, that composite does not > appear to be marked as a deployable. I'm assuming this is the > composite that must be deployed. I may be missing something but there > appears to be two problems with this: > > 1. Only deployables should be deployed and it appears most of the test > contributions are *not* marked as deployable composites

Yes, 99.9% of the Contributions have no composites marked as "deployable"
- this is deliberate, allowing the Composite(s) to run to be controlled
by the RuntimeBridge SPI
> 2. My understanding is providing the composite name out of band to > deploy it is not specified in the assembly spec. Is that correct? If > so, I think we are only left with runtime-specific mechanisms for > handling deployment which is a problem since it will require > modification of the test suite and potentially the test artifacts by > each vendor. >

There is a problem here that the Assembly TC needs to consider. Clearly any
SCA runtime must have means of installing Contributions and means of starting
one or more Composites. If not, then the runtime isn't worth much.

However, in trying to be flexible, we may have painted ourselves into a corner.

<deployable/> elements in the sca-contribution.xml file can be used to mark one
or more composites in a contribution as "deployable", but the SCA runtime is not
obliged to do anything with them:

"An SCA runtime MAY deploy the composites in <deployable/> elements found in the
META-INF/sca-contribution.xml and META-INF/sca-contribution-generated.xml files.
[ASM12029] "

Note the "MAY". There is no obligation here.

Then there are "deployment composites" as described in section 10.5.2. Those too
are optional.

Finally, there is the section on the Domain-Level Composite (10.7) and in particular
section 10.7.1 "Add to Domain-Level Composite", which is preceded by the following:

"The abstract domain-level functionality for modifying the domain-level composite is as follows, although a runtime
can supply equivalent functionality in a different form:"

It is THIS function that I was depending on when writing the SPI for the test runner. I make the assumption that the
capability to add a composite to the Domain Level Composite MUST be available in some form. The RuntimeBridge
interface simply supplies the name of a Composite which IS present in one of the Contributions and the assumption is
that the RuntimeBridge implementation knows how to find the actual location of the named Composite and then call
on the "add to Domain-Level Composite" function in the SCA runtime, however it is supplied.

But I note that there are no normative statements in section 10.7 that absolutely require there to be an implementation
of "add to Domain-Level Composite".

It may be the case that we need to add a normative requirement for this capability to be present in some form - we can be
flexible about HOW it is done, but to make any sense, it must be possible for an SCA runtime to do this.

Comments welcome!!

This is definitely an issue and it probably needs to be worked out by clarifying the Assembly spec. Otherwise, runtimes may exhibit very different behaviors.

However, as a short-term solution, couldn't the test cases be updated to mark composites as deployable in the contribution manifest and have the test runner provide the runtime bridge with a list of QNames corresponding to the deployable composites to be run for a particular test?

> Jim > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php>

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

sca-assembly message