axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <stev...@iseran.com>
Subject Re: jUDDI Gump build failing
Date Fri, 13 Feb 2004 10:41:00 GMT
Adam R. B. Jack wrote:
>>jUDDI's AdminServlet extends Axis' AxisServlet and overrides it's init()
>>method. A change to AxisServlet was checked in on January 16 which adds a
>>"throws ServletException" to init().
>>

init() is part of HttpServlet's public interface, and in that base 
interface the method is listed as throwing a ServletException.

http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/GenericServlet.html#init()

Adding that signature to the API was (a) requested by someone extending 
and (b) fixing something we should have done from the beginning.

I apologise for breaking jUddi, but we were at fault in the past.

 >>I'm unsure if AxisServlet is considered part of Axis' public interface.


http://ws.apache.org/axis/java/user-guide.html

It isnt on the list of either standard API (JAX-RPC), or bits of the 
implementation we like to keep stable because we know people build with 
it. Maybe it should be, but we have (and will continue to do) a fair bit 
of refactoring on those classes. That servlet is the primary entry point 
for incoming SOAP calls (all the ones over HTTP), so contains reporting, 
logging and security stuff that we need to keep on top of. At the same 
time it is currently structured to be subclassed in lots of interesting 
ways by people who feel the need, provided they recognise that there is 
no inter-version stability.

Maybe we need to consider what API we should formally offer for internal 
extension.

In this particular case, why does jUDDi subclass init()? Is it just to 
have something started at startup?



> 
> It's
> 
>>small thing to change on our side so I recommend simply adding the throws
>>clause for now.
> 
> 
> Let me take a little time to try to explain things from Gump's perspective,
> respond to Andy's concern, agreeing w/ Steve's suggestion (above), and end
> on some questions...
> 
> Gump is looking to the future, far far in the future, since the combination
> of projects in CVS today is not likely to hit the streets as a releases any
> time soon. [Some yes, but not all.] Anyway, so Gump is looking to find
> problems that haven't occurred in the field yet & give the projects involved
> chance to figure out what to do.
> 
> Basically here, AXIS made a change that affected to you. The may have done
> it because their up stream interface forced them to changed (quite likely in
> this case given this exception) or it may have been an intentional or
> unintentional unilateral change. That is one question, and will they/can
> they undo their change? If not, the question becomes, do you follow suit
> with the change, and can you without messing with your release dependencies
> and/or creating a discontinuity?

I dont think we should, in this particular case. In other cases, well, 
its a case by case thing, and letting us know we broke something is the 
first step to discovering who depends on it.

> 
> Interestingly adding a 'throws' change doesn't change signatures, so doesn't
> affect runtime dynamic linking (I believe). It might make an ugly mess at
> runtime (if thrown) but that is speculation. If your library gets deployed
> against a newer release/build of AXIS with this servlet, you are probably
> ok -- albeit somewhat dodgy.

Well this is the interesting bit. The base interface has a throws 
clause. We didnt in Axis, so you could not throw the exception from the 
init code. But an app server, built against the HttpServlet interface, 
should be set up to catch ServletExceptions from the class.

> 
> The question of if you add a 'throws' then what happens to developers
> compile/run against older AXIS (not wanting to move to CVS HEAD, say,
> perhaps sticking to the last release). Would the compiler try to get funny
> and complain, or simple warn?

We will be releasing a new beta build of Axis1.2 at some indeterminate 
but not overly distant point in the future.

> 
> I'm curious what more experienced Gumpers have to say on this. Any advice
> from prior experience? I assume the default reaction is to keep step with
> dependencies, if at all possible w/o causing too much developer grief, but
> maybe there is some clever compromise when runtime signature don't change.

Stay in sync or play reflection games.

Mime
View raw message