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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

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


Subject: Re: [sca-j] Analysis of CAA spec untested conformance items


On 5/23/2011 3:34 AM, Mike Edwards wrote:

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: mike_edwards@uk.ibm.com  
 
 




From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
To: OASIS Java <sca-j@lists.oasis-open.org>
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>


<ask>
I'm certainly open to other ideas wrt testing. Not sure how one would go about testing this.
I suppose we can leave it as MAY and agree that this is untestable (in the same sense that certain MUSTs are untestable).
</ask>


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>


<ask>
Let's discuss this on the call.
</ask>


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>



<ask>Ok, thanks! </ask>

I'll wait to see if there is any email discussion before filing new issues.


<ask>Please file away ;-) </ask>

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








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