Re: jUDDI Gump build failing

["Adam R. B. Jack" <aj...@trysybase.com>]

> 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().
>
> I'm unsure if AxisServlet is considered part of Axis' public interface.
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?

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.

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?

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.

regards

Adam

Re: jUDDI Gump build failing

[Steve Loughran <st...@iseran.com>]

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.

Re: jUDDI Gump build failing

[Steve Loughran <st...@iseran.com>]

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.