On 12/03/2013 17:06, Justin Lee wrote:
> Isn't that required for certification, though?
Only if you want to certify against the web profile and Tomcat doesn't.
> Although, the bigger
> "problem" is that it creates an implicit dependency on CDI either way.
> Which I'm mostly OK with as I'm an injection nut but it does increase the
> scope kinda late in the game.
Actually, the bigger problem is that it ties the WebSocket
implementation to the container as I explained below.
I'd really like to see WebSocket be something you could drop into any
Servlet 3.1 container with no other dependencies.
Mark
>
>
> On Tue, Mar 12, 2013 at 8:38 AM, Mark Thomas <mark_at_homeinbox.net> wrote:
>
>> 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
>>>>
>>>
>>>
>>>
>>
>>
>
>