You are viewing a plain text version of this content. The canonical link for it is here.
Posted to axis-tck@ws.apache.org by sc...@us.ibm.com on 2002/06/27 22:29:29 UTC
TCK Summary with Dim's Changes
With dim's changes Axis now passes the javax_xml_rpc.Service tests.
However, the change that allows GetPortsPosTest2 to pass is not
JSR 101 compliant. (See below..)
So the question is "Should we change Axis to pass the TCK even if the
change
is not spec compliant ?"
Test Blocking Issue(s)
----------------------------------------------------------------
jaxrpc.api.javax_xml_namespace.QName ( 7 of 7 PASS)
jaxrpc.api.javax_xml_rpc.Call (29 of 29 PASS)
jaxrpc.api.javax_xml_rpc.JAXRPCException ( 5 of 5 PASS)
jaxrpc.api.javax_xml_rpc.NamespaceConstants ( 1 of 1 PASS)
jaxrpc.api.javax_xml_rpc.ParameterMode ( 1 of 1 PASS)
jaxrpc.api.javax_xml_rpc.Service (21 of 21 PASS)
GetPortsPosTest2 TCK:getPorts with no wsdl should throw
ServiceException, but
TCK incorrectly expects a null iterator.
Axis was
changed to also return a null iterator,
which is why
Axis passes this test.
jaxrpc.api.javax_xml_rpc.ServiceException ( 5 of 5 PASS)
jaxrpc.api.javax_xml_rpc.ServiceFactory ( 7 of 7 PASS)
jaxrpc.api.javax_xml_rpc.Stub ( 7 of 8 PASS)
setPropertyTest5 Axis: Invalid property set
jaxrpc.api.javax_xml_rpc_encoding (33 of 33 PASS)
jaxrpc.api.javax_xml_rpc_handler.GenericHandler ( 0 of 1 PASS)
DoGenericHandlerTest Axis: Deploy client side handlers ?
jaxrpc.api.javax_xml_rpc_handler.Handler ( 0 of 2 PASS)
DoHandlerTest1 Axis: No support in Java2WSDL to have multi
ports in service
DoHandlerTest2 Axis: No support in Java2WSDL to have multi
ports in service
jaxrpc.api.javax_xml_rpc_handler.HandlerInfo ( 8 of 8 PASS)
jaxrpc.api.javax_xml_rpc_handler.HandlerRegistry ( 3 of 3 PASS)
jaxrpc.api.javax_xml_rpc_handler.MessageContext ( 0 of 1 PASS)
DoMessageContextTest Axis: Deploy client side handlers ?
jaxrpc.api.javax_xml_rpc_handler_soap.SOAPMessageContext ( 0 of 1 PASS)
DoSOAPMessageContextTest Axis: Deploy client side handlers ?
jaxrpc.api.javax_xml_rpc_holders (60 of 60 PASS)
jaxrpc.api.javax_xml_rpc_server ( 6 of 6 PASS)
jaxrpc.api.javax_xml_rpc_soap ( 5 of 5 PASS)
jaxrpc.ee.j2w.attachmentstest ( 0 of 1 PASS)
* Axis: Java2WSDL can't handle java.awt.Image,
etc.
jaxrpc.ee.j2w.inheritedinterfacetest ( 0 of 1 PASS)
InheritedInterfaceTest Axis: No support in Java2WSDL to have multi
ports in service
jaxrpc.ee.j2w.marshalltest ( 1 of 8 PASS)
TCK: The MyServiceException.class was not
present
in the original J2WMarshallTest.jar.
This
had to be compiled before running
Java2WSDL.
MarshallPrimitiveTest TCK: XML<->Java Id problem. TCK assumes xml
operation
BooleanTest maps to BooleanTest java method.
Axis
correctly maps BooleanTest to booleanTest.
MarshallStandardJavaClassesTest TCK: Same as above with StringTest
MarshallJavaBeanTest TCK: Same as above with JavaBeanTest
MarshallValueTypeTest TCK: Same as above with ValueTypeTest
MarshallJavaArrayTest TCK: Same as above with StringArrayTest
MarshallJavaMultiArrayTest TCK: Same as above with StringMultiArrayTest
MarshallServiceExceptionTest TCK: Same as above with
MyServiceExceptionTest
jaxrpc.ee.j2w.multiinterfacetest ( 0 of 1 PASS)
MultiInterfaceTest Axis: No support in Java2WSDL to have multi
ports in service
jaxrpc.ee.j2w.multiservicetest ( 1 of 1 PASS)
jaxrpc.ee.j2w.simpletest ( 4 of 4 PASS)
jaxrpc.ee.sec ( 0 of 6 PASS)
* I_HAVE_NOT_HAND_GEND_THESE_TESTS_YET
jaxrpc.ee.w2j.document ( 0 of 4 PASS)
* I_HAVE_NOT_HAND_GEND_THESE_TESTS_YET
THERE_ARE_PROBLEMS_WITH_DOC_LIT_MAPPING
jaxrpc.ee.w2j.rpc.encoded.marshalltest ( 0 of 8 PASS)
* TCK:The TCK depends on each bean being
generated with a full constructor. This
contracticts the JSR 101 specfication.
NOTE: 3 of these 8 tests pass if the full
constructor is generated.
jaxrpc.ee.w2j.rpc.encoded.parametermodetest ( 6 of 11 PASS)
MixTest TCK: TCK/RI has wrong parameter order for
MixText
InSimpleTypesTest Axis?: Problem with marshalling Calendar
InOutSimpleTypesTest Axis?: Problem with marshalling Calendar
OutSimpleTypesTest Axis?: Problem with marshalling Calendar
InStructTest TCK: TCK emits getVarBoolean instead of
isVarBoolean
jaxrpc.ee.w2j.rpc.encoded.simpletest ( 4 of 4 PASS)
jaxrpc.ee.w2j.rpc.encoded.xmlnamemappingtest ( 0 of 2 PASS)
* TCK:The TCK depends on each bean being
generated with a full constructor. This
contracticts the JSR 101 specfication.
TCK: In addition there are problems with the
xml<->java mapping for get<port name>
jaxrpc.sig ( 1 of 1 PASS)
============================================================================
TOTAL (215 of 256 PASS)
Rich 'Shirley' Scheuerle
IBM WebSphere & Axis Web Services Development
512-838-5115 (IBM TL 678-5115)
Re: TCK Summary with Dim's Changes
Posted by Sam Ruby <ru...@apache.org>.
Rich 'Shirley' Scheuerle wrote:
>
> With dim's changes Axis now passes the javax_xml_rpc.Service tests.
> However, the change that allows GetPortsPosTest2 to pass is not JSR
> 101 compliant. (See below..)
>
> So the question is "Should we change Axis to pass the TCK even if the
> change is not spec compliant ?"
I would say that spec compliance is more important than passing the TCK.
Glen Daniels wrote:
>
> Hm. My personal preference is to leave our code be in places where
> we think we're doing the right thing and the spec/TCK might be wrong,
> and take it up with the Sun guys. The failed test will stand as a
> reminder of the issue, and we can fix it later depending on the
> resolution. I'd rather that than passing the test and then
> forgetting about the issue or later saying "well what's done is
> done", especially in cases where the effort to pass the test is a bit
> more than this example here.
I agree. Note: we are not going to hear much from Sun either way for a
week as the entire corporation is on mandatory vacation, but immediately
upon their return, we can set up a conference call with Lance and work
through the issues.
My recommendation is that we start numbering our issues (like Rich has
been doing) and then annotate our TCK summaries with these numbers for
every contested failure.
-Sam Ruby