OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-assembly] [ASSEMBLY 205] TEST_ASM_12001 has empty composite name -Proposal



Jim,

You make fair points here, but the difficulty is that those points are not the subject of Assembly 205.

I'm for resolving Assembly 205 by withdrawing testcase ASM_12001 and then raising one or more new issues to address the actual points
that you are making.


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



From: Jim Marino <jim.marino@gmail.com>
To: OASIS Assembly <sca-assembly@lists.oasis-open.org>
Date: 24/02/2010 02:18
Subject: Re: [sca-assembly] [ASSEMBLY 205] TEST_ASM_12001 has empty composite name - Propose CNA





Mike,

Assembly-205 is *not* arguing the test case is invalid. Below is the issue text for reference:

"TEST_ASM_12001 in TestConfiguration provides an empty composite name (the test attempts to verify that all deployables in a composite are deployed if no composite is specified). Besides being a dubious test (it relies on the runtime bridge and runtime deployment API to do this), it demonstrates Testconfiguration is not intuitive as the composite to run comes from multiple sources in TestConfiguration."

Assembly-205 is raising two points:

1. The test harness API/SPI is inconsistent and can be simplified
2. The test case as it is implemented may not test what it is intended to



<mje>
I agree that the Test Client SPI could do with a) documentation  b) simplification/making consistent.
Guilty as charged - the SPI developed over time and has not been rationalized.

As for testcase ASM_12001 I believe that it does test exactly what it was intended to test - but that I
think that we have now agreed that the function concerned is actually optional.  The present test
suite is not designed for testing optional features and as a result, I think that this particular testcase
should be removed.

As I said elsewhere, we could enhance the test suite to test optional features, but I think that doing this
properly will be a lot of work and I think that should be left to SCA version 1.2.
</mje>

To start with the first, I found the runtime bridge API confusing, in part because configuration is not handled consistently and there is no API documentation.  I outlined the inconsistencies and proposed a solution in an email dated 13 December 2009, which was not responded to. The email was cited in Assembly-205:

http://lists.oasis-open.org/archives/sca-assembly/200912/msg00043.html

One of the main inconsistencies is the scattering of test configuration sources. Consider the following two methods on RuntimeBridge:

public interface RuntimeBridge {

public void setTestConfiguration(TestConfiguration testConfiguration);

boolean startContribution(String contributionLocation,  String[] contributionNames) throws Exception;
 
//.....

}

and TestConfiguation:

public class TestConfiguration {
public String composite;
public String[] contributionNames;
// ....
}

Why are two sets of contribution names present in the API, those passed into setTestConfiguration via a TestConfiguration instance and those passed as a parameter to startContribution? What SCA assembly concept does the composite field on TestConfiguration map to? Is it a deployment composite? If it is not, where in the SCA specifications does it allow for composites that are not marked as deployable in the contribution manifest to be directly included in the domain? If the composite field is null, how should it be treated? Two ways to solve these issues is to make composite field represent a deployment composite or remove it entirely and rely on the deployable mechanism in the contribution manifest (i.e. a "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").  However, the issue with the latter is that it is an optional behavior, which means the test case should be marked as such.

The second point is that given these inconsistencies, that test must rely on the implementation of RuntimeBridge to figure out the correct behavior such as interpreting a null composite name to include all deployables. This arguably means the test does not correctly verify the test case.
<mje>
Yes the SPI is inconsistent and ill documented.

However, it is the intention that the contributions are passed via the SPI startContribution method rather than the testConfiguration
parameter - clarifying this should in my opinion remove the ambiguity that you are pointing at.

This should be the subject of a separate new issue.
</mje>


Jim

 
 

On Feb 23, 2010, at 7:09 AM, Mike Edwards wrote:


Folks,


Assembly issue 205 (
http://www.osoa.org/jira/browse/ASSEMBLY-205 ) argues that
testcase ASM_12001 is invalid since the TestConfiguration contains a set of Contributions to use, but

does not supply the name of any Composite to run.


My view is that the testcase is valid and does not need to be changed.  Hence we should close this issue with no action.


Here is the configuration in the test client:


           config.
testName                 = this.getClass().getSimpleName().substring(0, 9);
           config.
input                         = "request";
           config.
output[0]                         = config.testName + " " + config.input + " service1 operation1 invoked" ;
           
// null composite supplied - the name of the composite to run comes from the sca-contribution.xml
           config.
composite                 = null;
           config.
testServiceName         = "TestClient";
 
           config.
contributionNames        = new String[] { "ASM_12001", "General", "General" + _Lang };

The relevant things are:


a) the list of contribution names assigned to config.contributionNames

b) the value of config.composite, which is null


In the design of all the testcases, the configuration has one or more Contributions, which are intended to contain the artifacts to use, plus

the name of a Composite to run.  It is expected that the Composite exists somewhere in the supplied Contributions.


In this testcase, one of the contributions - ASM_12001 - has an SCA contribution which has a contribution.xml file as follows:


<
contribution
       
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912"
       
xmlns:test="http://docs.oasis-open.org/ns/opencsa/scatests/200903">


       
<deployable composite="test:TEST_ASM_12001"/>
       
<import namespace="http://docs.oasis-open.org/ns/opencsa/scatests/200903"/>  <!-- Contributions namespace -->
       
<import namespace="http://test.sca.oasisopen.org/"/>                                                  <!-- WSDL namespace -->
       

</
contribution>

Note the presence of the <deployable/> element, referencing a specific Composite.


The design of this test is intended to check that the SCA runtime will deploy the composite referenced by the <deployable/> element.

Either this test is correct as written, or the argument must be made that an SCA runtime does not have to do anything with the <deployable/> element.

If that is the case, then the whole testcase should be removed as the function is optional.




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




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












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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]