> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
