Off the top of my head I can think of
- using a different URL matching scheme (currently this is done in
WSServletDelegate but can't be changed)
- providing a servlet that extends WSServlet and decides what to do
based on the headers or something else in the servlet context. The
result may be to reject the message or reroute it elsewhere without
passing it into the RI. No parsing of the message would be done in this
case.
- may want to provide more/different information on the status page
(hard-coded in WSServletDelegate)
- may want to programatically add extra custom adapters in the servlet
context listener that are to be present in all deployed services
...
There are other things but I haven't looked into where these would fit
in so may be able to do them with the SPIs. Some of the above may be
done using the SPIs too of course, but I haven't got that far yet.
Some, or all, of the above may be achievable (well, not the last one I
don't think) by replacing the RI class and delegating to it in the
replacement. This is not the case for classes that are not referenced by
interface or base class (such as WSServletDelegate).
When so much care has been taken to make classes final I also wonder why
so many methods in these classes are "protected"? Nothing can inherit them!
Although I see where you are coming from with trying to restrict people
to the SPIs to allow you to change internals, I would suggest that
anything that can be replaced through configuration be a candidate for
not being final (and anything that these replacements can control the
creation of). Since WSServlet can be switched out in web.xml and
WSServletContextListener similarly, and WSServletDelegate is created by
WSServletContextListener then these seem like candidates for allowing
subclassing.
It is always fair to say in the javadoc of a class that it is an
internal component and subject to change and allow developers to decide
if this is the only approach they have and so to go ahead and do it in
full knowledge it may break in future (although I'm not sure how
WSServlet could break since it only implements the HttpServlet API and
nothing more).
Pete
Kohsuke Kawaguchi wrote:
> 2007/4/14, Peter Hendry <peter.hendry_at_capeclear.com>:
>> I was wondering why so many classes in the RI are "final"? Obviously
>> this prevents them being extended. Classes like WSServlet and
>> WSServletDelegate where both of these seem like ideal places to add
>> functionality. WSServlet is defined in web.xml so is easily changed
>> through configuration, and because WSServlet relies on getting an
>> instance of WSServletDelegate which is set by the listener, it means a
>> new listener cannot set a different class for WSServletDelegate and so
>> it could not use WSServlet if it did wish to change WSServletDelegate
>> through extension.
>
> I think the primary thinking behind this is that it helps our team
> members understand what are supposed to be extensible and what are
> not. The other thinking behind this is that we want to retain the
> freedom to change those as we find necessary.
>
> Finding the right balance is difficult, and we need constant
> adjustments. I haven't looked at the particular places you cited, so I
> can't speak for whether marking them final was adequate or not.
>
> Could you elaborate a bit more on what you were trying to do and why
> you are interested in WSServletDelegate?
>
>> Is this to prevent extension of the RI other than through the SPI
>> points? If so then I would suggest that it presupposes that there are
>> adequate SPI points and that they are well enough defined to expose any
>> new functionality.
>
> Generally speaking, we'd like people to only use the SPI (the stuff
> defined in com.sun.xml.ws.api.) What we expose through that package is
> driven by inputs like this, so an additional input would be very
> helpful.
>