Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Message-Id: <200405121121.i4CBL7B15607@kiku.7777.net>
From: "Ias" <iasandcb@tmax.co.kr>
To: <axis-dev@ws.apache.org>
Subject: RE: About JAX-RPC 1.1 compliance of JAXRPCException and
 ServiceException
Date: Wed, 12 May 2004 20:21:05 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <694BB9D2-A403-11D8-BF20-000A95A01192@optonline.net>
Thread-Index: AcQ4D20kkV43S6u3T8yRI7x56szFNAAAfxIg

> 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.

I see. Thanks for your guidance.

> 
> Lets continue to talk about this off-list.

Of course. :-)

> 
> 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...
> 

I fully understand your concern on the issue. As a matter of fact, Sun's
JWSDP 1.3 requires JDK 1.4 and doesn't support JDK 1.3 any longer (So does
J2EE 1.4). Moreover, JAX-RPC 2.0 is supposed to require JDK 1.5 equipped
with metadata facility. What I'm thinking about Axis' roadmap in regard to
JDK is

Axis 1.2 (JAX-RPC 1.1) this summer - JDK 1.3
Axis 1.3 (JAX-RPC 1.1) by 2004 - JDK 1.4
Axis 2.0 (JAX-RPC 2.0) sometime in 2005 - JDK 1.5 

If we goes like this, it will be possible to lead Axis to make use of
various features supported by JDK 1.4 in the future.

Ias

> 
> 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
>