Doug Kohlert wrote:
> I have to disagree, if you leave it as an interface and we have current
> implementations of it, what happens
> if we add some new methods in a future release? All implementations
> would have to be updated to reflect
> the new APIs, however, if you use an abstract class with default
> implementations, then existing extensionhandlers
> would not need to be modified. Granted, if you change existing methods
> then subtle bugs will appear.
+1
I was the "potential implementor" that Doug originally mentioned. As an
implementor, I may not like to handle all the extensiblity points in
WSDL generation. But if we keep this class as interface, then I must
handle all the extensiblity points which seems like an unnecessary pain
to me.
-Arun
>
> Does anyone else have any thoughts on the subject?
>
> Vivek Pandey wrote:
>
>> This is not a good idea. It can be problematic as future changes in
>> the apis wont be easiliy detectable by the superclasses resulting in
>> to bugs thats hard to fix.
>>
>> Moreover it doesn't provide much to the implementor of this class,
>> current IDEs can automatically generate the default implementations of
>> these methods - I guess thats pretty much the NOOP implementation do.
>>
>> IMO, we should have this class as interface if not then we should not
>> keep the default implementations in it.
>>
>> -vivek.
>>
>> Doug Kohlert wrote:
>>
>>> At the request of a potential implementor of this extension, I made
>>> it an abstract class rather than an interface.
>>>
>>> Doug Kohlert wrote:
>>>
>>>> I removed all uses of CheckedException from from the
>>>> WSDLGeneratorExtension api as it appears that
>>>> no component from the wsinterop project needs access to it.
>>>>
>>>
>>
>
--
got Web Services ?
Download Java Web Services Developer Pack from
http://java.sun.com/webservices