On 12/03/2013 12:33, Justin Lee wrote:
> Why not have the servlet container inject the container provider? let the
> servlet container worry about resolving the correct provider. then the
> developer just needs to use what's handed to him. isn't CDI required by
> the web profile anyway? might as well leverage it.
Not all Servlet containers implement the web profile.
Mark
> On Tue, Mar 12, 2013 at 5:07 AM, Mark Thomas <mark_at_homeinbox.net> wrote:
>
>> 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
>>
>
>
>