On 15/03/2013 18:35, Danny Coward wrote:
> Hi Mark,
>>>> 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 ?
>> It is but it relies on SCI processing not being disabled. I was hoping
>> for a solution that didn't depend on SCI processing or class scanning.
> And you are assuming that developers who call the programmatic call API
> are calling from ServletContextListeners that are explicitly configured
> in the web.xml of the WAR file (rather than being scanned for ), right ?
Correct.
> I know you want an API solution that allows websocket implementations to
> be portable across web container AND not require any kind of scanning at
> all, but I had thought (buried in previous email somewhere...) that your
> main concern about scanning was scanning application WAR files, which I
> think is valid as they may be very large and contain any number of
> random library JARs.
Correct, that is my main concern.
> It does seem to be an order of magnitude less of a problem for the
> solution to rely on a scan of the (single) websocket implementation JAR.
And an SCI scan at that which is a lot cheaper.
> I'm just having a bit of trouble trading implementation desire off with
> needing API (ServerContainerProvider.getServerContainer(ServletContext
> sc)) for one bootstrap call that needs the ServletContext to be passed
> in, when (purely looked at from the developers POV) picking it off the
> ServletContext is simpler. This is not, after all, an API we expect many
> developers to need as we already have other mechanisms for the more
> bread and butter cases.
I understand that PoV. My preference remains for a fully programmatic
solution.
Mark