On 11/03/2013 23:48, Danny Coward wrote:
> A) Implementation Issue with ServerContainerProvider
<snip/>
>
> Fortunately, this instance of the ServletContext is readily available in
> any ServletContexListener the developer may need to make the bootstrap
> call from. There are various options for reworking the API,
>
> ServerContainerProvider.getServerContainer(String contextRoot)
Won't work in a virtual hosting environment where there may be multiple
web applications with the same context path.
> ServerContainerProvider.getServerContainer(ServletContext servletContext)
That needs to be an object to prevent a dependency
> or ServerContainer.setContext(Object context)
Either of these would be find by me.
> though after some thought, I think the simplest approach is to remove
> the ServerContainerProvider class altogether and require that, for
> websocket implementations in the web container, the ServletContext
> instance have a named attribute that is the websocket ServerContainer.
> Its one less API class, in exchange for a named attribute.
While I like the simplicity that won't work for a WebSocket
implementation that is independent of the container because:
- the container has no way of knowing it needs to add the
ServerContainer (because of the 100% programmatic requirement there is
no SCI to do this for us)
- the implementation has no way of identifying the ServletContext
Another option would be to have a standard ServletContextListener but
that adds a hard dependency on the Servlet API.
I think we are back to
ServerContainerProvider.getServerContainer(Object servletContext)
or ServerContainer.setContext(Object context)
At this point, I'd be happy with either.
Mark