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 ?
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.
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.
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.
- Danny
> Mark
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation