On 3/12/13 10:35 AM, Mark Thomas 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.
Yes, me too, although I will point out it was not an explicit goal of
the JSR.
Back to the design issue...I did think that it was portable to pick up
an ServerContainerInitializer from the implementation JAR that can make
the correct association between the ServerContainer instance and the
ServletContext instance corresponding to the application. And in that
way, the association can be made without having to scan any of the
application WARs at all.
Is that not the case ?
- Danny
>
> 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
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation