Next in thread →
Next in month →
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:
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>
<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
Next in thread →
Next in month →