axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ias" <iasan...@tmax.co.kr>
Subject RE: About JAX-RPC 1.1 compliance of JAXRPCException and ServiceException
Date Wed, 12 May 2004 07:29:23 GMT
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
> 


Mime
View raw message