--
Joakim Erdfelt <joakim_at_intalio.com>
webtide.com <http://www.webtide.com/>
Developer advice, services and support
from the Jetty & CometD experts
eclipse.org/jetty - cometd.org
On Tue, Mar 12, 2013 at 10:35 AM, Mark Thomas <mark_at_homeinbox.net> wrote:
> 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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>