Folks,
Comments inline
Yours, Mike
Dr Mike Edwards
Mail Point 137, Hursley
Park
STSM
Winchester, Hants SO21
2JN
SCA & Services
Standards
United Kingdom
Co-Chair OASIS SCA
Assembly TC
IBM Software Group
Phone:
+44-1962 818014
Mobile:
+44-7802-467431 (274097)
e-mail:
From:
Anish Karmarkar <>
To:
OASIS Java <>
Date:
21/05/2011 00:17
Subject:
[sca-j] Analysis of CAA spec untested
conformance items
I went through the CAA spec and the test suite and
here is an analysis
of untested conformance items:
1) Issue 1: Mark the following as untestable --
JCA90024 through JCA90039
It is marked as untested because it is an optional feature. Optionality
isn't the issue here. But this is related to redeployment, which is a
little difficult to do in a machine-processable way as there is no API
defined for this.
<mje>
Well, same result...
;-)
</mje>
2) Issue 2: untested items that contain MAY/SHOULD, but in fact do not
need the 2119 keywords. Remove the keywords --
a) [JCA20009] The SCA runtime MAY use by-reference semantics when
passing input parameters, return values or exceptions on calls to
remotable services within the same JVM if both the service method
implementation and the service proxy used by the client are marked
“allows pass by reference”.
s/MAY/can/
<mje>
Hmm - tricky.
There are two "targets"
for this statement - one is the SCA runtime, the other is the component
implementation code.
"MAY" here indicates
a genuine choice - the runtime can either stick with "pass by value"
or, in
this one case it can choose
to use "pass by reference". Either is valid.
The MAY warns the component
implementation code that there is no guarantee that the parameters
will be "pass by reference",
only that it might happen.
Downgrading to a "can"
seems less that ideal, but I suppose I might be persuaded to live with
it.
</mje>
3) Issue 3: untested items that contain MUST, but in fact do not need
the 2119 keywords. Remove the keywords --
[JCA80052] The SCAClientFactory.getService method MUST throw a
NoSuchServiceException if the domainURI of the SCAClientFactory does not
identify a valid SCA Domain.
This is marked as untestable as it is impossible to obtain a
SCAClientFactory instance with an invalid domainURI. If this is indeed
the case, then we don't need this at all. Remove the conformance item.
<mje>
OK with that
</mje>
4) Issue 4: Add new tests
a) [JCA80055] The implementation of the SCAClientFactoryFinder.find
method MUST return an object which is an implementation of the
SCAClientFactory interface, for the SCA Domain represented by the
doaminURI parameter, using the supplied properties and classloader.
Marked as "Untestable unless we make the vendor implementation of
SCAClientFactoryFinder a conformance target". Since this is essentially
an SPI, the vendor's implementation code is what will be tested. Add a
new test for this.
b) [JCA80056] The implementation of the SCAClientFactoryFinder.find
method MUST throw a ServiceRuntimeException if the SCAClientFactory
implementation could not be found.
Marked as "Untestable unless we make the vendor implementation of
SCAClientFactoryFinder a conformance target". Since this is essentially
an SPI, the vendor's implementation code is what will be tested. Add a
new test for this.
<mje>
I object to the adding
of new tests here. I don't think that it is necessary or desirable
to
do this and I have absolutely
no idea how to write a harness for such code.
The comment about making
the vendor implementation a conformance target was well
meant - and to the point.
If necessary, I will vote
to remove the relevant normative statements, not to write new tests.
</mje>
c) [JCA100007] For SCA reference interfaces defined using
interface.java, the SCA runtime MUST support a Java interface which
contains the additional client-side asynchronous polling and callback
methods defined by JAX-WS.
This is marked as not tested as this is optional. This is not
optional. Add new test for this.
<mje>
This is actually a fault
in the TA document, where TA-11007 is erroneously marked as "optional".
In fact there are 3 testcases
that use a reference interface that has all 3 forms of JAX-WS client-side
interface methods:
JCA_11006
JCA_11007
JCA_11008
The interface is Service1WithAsyncMethods.java
The fix is straightforward
- change the TA document to say "mandatory" and the testcases
document
to point to one of the
above (or all of them).
</mje>
I'll wait to see if there is any email discussion before filing new issues.
Thanks.
-Anish
--
---------------------------------------------------------------------
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
