axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@optonline.net>
Subject Re: About JAX-RPC 1.1 compliance of JAXRPCException and ServiceException
Date Wed, 12 May 2004 10:59:16 GMT
Ias,

You CANNOT talk about the TCK in this way in a public forum.  In fact, 
since we don't have a controlled list yet, you can't talk about it on 
any list.

You cannot discuss what passes, what doesn't pass, or what Sun is doing 
in the TCK, etc.

Lets continue to talk about this off-list.

geir

P.S. As a user, I think that excluding 1.3 is a bad idea.  There's lots 
of 1.3 code running out that that could use Axis...


On May 12, 2004, at 3:29 AM, Ias wrote:

> FYI,
>
> 1. If we can choose JDK 1.4 as a build target of Axis, we also can take
> advantage of standard cause mechanism introduced since JDK 1.4. For 
> example,
>
> package javax.xml.rpc;
> public class JAXRPCException extends RuntimeException {
>     public JAXRPCException() {}
>     public JAXRPCException(String message) {
>         super(message);
>     }
>     public JAXRPCException(String message, Throwable cause) {
>         super(message, cause);
>     }
>     public JAXRPCException(Throwable cause) {
>         super(cause);
>     }
>     public Throwable getLinkedCause() {
>         return getCause();
>     }
> }
>
> The above JAXRPCException passes JAX-RPC 1.1 TCK signature test and 
> displays
> chained causes as well on JDK 1.4 runtime. If you want to support JDK 
> 1.3 at
> the same time with this JAXRPCException, you need to put some code for
> detecting JDK version and branching classis (JDK 1.3 and earlier) 
> logic and
> modern (JDK 1.4 and later) logic.
>
> 2. Just for test, I added a private method to JAXRPCException and the
> signature test passed. It implies that Sun only checks out public 
> methods
> for fixed spec APIs.
>
> Regards,
>
> Ias
>
>> -----Original Message-----
>> From: Jarek Gawor [mailto:gawor@mcs.anl.gov]
>> Sent: Wednesday, May 12, 2004 3:26 PM
>> To: axis-dev@ws.apache.org
>> Subject: RE: About JAX-RPC 1.1 compliance of JAXRPCException
>> and ServiceException
>>
>>
>>> Yes, actually what you did is overriding inherited methods, not
>>> declaring new methods. However, for example,
>>> javax.xml.rpc.JAXRPCException in JAX-RPC
>>> 1.1 API has no its own printStackTrace methods, which means you are
>>> required to use the inherited printStackTrace methods from
>> Throwable
>>> and not to override them with your own implementations. If
>>> JAXRPCException can override them, its API documentation
>> states them
>>> explicitly.
>>>
>>> That's how Java standard APIs (java.* and javax.*) go.
>>> Implementing the APIs
>>> needs to follow all the declarations specified in the spec exactly.
>>
>> Is there a document somewhere explaining this policy? In this
>> particular case I find it hard to believe that I cannot
>> override functions like this.
>> Anyway, IMHO the way it is now (without the overrides) it's
>> not very useful as most programs will probably just log the
>> error or display the stack trace but not actually dig into
>> the chained exception and the cause information will be disregarded.
>>
>> Jarek
>>
>
>
-- 
Geir Magnusson Jr                                   203-247-1713(m)
geir@4quarters.com


Mime
View raw message