You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Glen Daniels <gd...@macromedia.com> on 2002/08/23 19:39:50 UTC

RE: cvs commit: xml-axis/java/src/org/apache/axis/utils axisNLS.p roperties

Hi Rich!

> 1) The namespace.pop() change is breaking the functional tests.  I am
> investigating.

Interesting!  I was actually going to write up a test with XML like this:

<ns:outer xmlns:ns="http://good-ns">
  <ns:inner xmlns:ns="http://bad-ns"/>
  <ns:checkMe/>
</ns:outer>

...to confirm that the "checkMe" element is in fact in the right namespace, since it seemed at first glance that failing to do the pop() would cause problems in situations like this.

If you find the problem, let's make sure to add a unit test for it (as opposed to a func test).  I can back out the change for now, too.  Let me know if you want a hand.

> 2) Could you explain in more detail the changes in RPCHandler.
>    a) do we need a check to make sure that the paramDesc has 
> a non-null
> javaType. Is this an assertion check that should be added to 
> OperationDesc
> or ServiceDesc ?

Life is OK if we pass a null class to getDeserializer(), in which case it just picks the default mapping.  There may be cases where just the XML type is set (I'm thinking client side in particular), so I'd like to think some more about it before adding any assertions like that.

>    b) Was the code to check isConvertable at this point wrong or just
> redundant.  Don't we want to know conversion problems at this 
> point so that
> we don't have to investigate the remaining parameters ( I am 
> thinking of
> the overloaded operations).  Or perhaps we want to only do the
> isConveratable check if we are doing overloading.

We still do the isConvertible() check, but we now only do it in situations where the Deserializer doesn't guarantee us the correct type (i.e. there was no exact xmlType/javaType match).

--Glen