axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: Creating new Provider implementations
Date Fri, 30 Apr 2004 12:16:36 GMT
Darren Marvin wrote:
> Hi,
> I would like to write my own Provider implementation in order to provide 
> extra information to a Java service beyond just arguments or the SOAP 
> body. Is this a wise thing to do? My concern is that BasicProvider is 
> not an interface but an abstract class which implies subtle dependencies 
> that may cause operating problems for my implementation in the future if 
> the BasicProvider class is changed. I acknowledge that all the 
> interesting Provider implementations extend the BasicProvider and 
> therefore suggest that BasicProvider (and JavaProvider) are stable but 
> is it wise to conclude this? I would normally expect to implement an 
> interface so that there is less coupling. I could be making a big deal 
> out of nothing of course or even worse missing something important :O)

I dont think it is officially part of any API, so it is not guaranteed 
to be stable. But it is not an area of continual change, so unless 
anyone is planning changes, it should stay reasonably stable. You can 
track that by watching the mail list/commit changes, or regularly 
building your provider against CVS_HEAD and complaining when it breaks. 
The latter is very good, not just because it is automated but because 
you should be able to test more.

If your code lives in a CVS or SVN repository with public read access, 
you can offload that check to the gump project,; 
otherwise you can run your own copy of Gump. I'm planning to do that 
with some work code; it does not apparently take too long.

Finally, if you think there should be an interface, write it, add some 
tests, etc, and contribute it back to the project. I'm sure other people 
would appreciate it.


View raw message