Peter Hendry wrote:
> 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
The servlet code "com.sun.xml.ws.transport.http.servlet" sits on top of
the hosting API, which is an exposed part of the RI.
So if you are really thinking about changing these behaviors, one way is
to simply swap out the whole default servlet code and replace it with
your own. That's just 8 classes that we are talking about.
If the scope of your change is so small that it won't make sense to
start by copying 8 files, we can see if we could remove some finals,
with the understanding that those are not committed part of the API,
and so in theory future versions could break your code.
We are very interested in having people like you to take advantage of
the RI, so we'd like to figure out something that works for both of us.
> 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!
I think you are right that they are just the result of sloppy
programming. Some of them must have come from IDE auto-completion as
they are marked as protected in the base class.
We should have done the empty modifier, which indicates package access.
> 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).
I think there are different schools of thoughts around these things so
we were just defensive.
In any case, it sounds like the first step you wanted was to subclass
WSServletDelegate, which calls for making a few other adjustments. I'll
talk to Vivek and Jitu about that to see what we want to do.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com