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
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: OASIS Assembly <sca-assembly@lists.oasis-open.org>
- Date: Tue, 2 Mar 2010 10:02:29 +0000
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]