On 27/02/2013 10:34, Danny Coward wrote:
> On 2/27/13 9:57 AM, Mark Thomas wrote:
>> On 27/02/2013 09:27, Danny Coward wrote:
>>> On 2/27/13 9:16 AM, Mark Thomas wrote:
>>>> Therefore I'd like to add one more method to the above API:
>>>>
>>>> public abstract void setRoot(Object root);
>>>
>>> Let me think about this. If I understand it, this is essentially an SPI
>>> on the implementation, and there's no reason for application developers
>>> to call it ?
>>
>> Hmm. I wrote a long reply to this that got me thinking. This is an
>> arifact of how I opted to implement WebSocket in Tomcat. I *think* I
>> can do without this method but I have some fairly major refactoring to
>> do to determine if that is the case. The refactoring is also something
>> I'm going to have to do if I want to support registration of endpoints
>> at times other than servlet context start (as a container specific
>> feature).
That isn't going to work. There is a fundamental problem that if a
purely programmatic approach is used then something has to tell the web
socket ServerContainer what the ServletContext is. I don't see a way
around this. I think the setRoot() method (or soemthing equivalent) is
going to be required.
> OK. The other question I had was we're trying to figure out if there is
> a clean point in our websocket implementation to know that the
> application deployment phase is complete.
>
> i.e. if we want to restrict the use of deploy() to only the application
> deployment phase (specifically, only to calls from
> ServletContextListeners) how can the websocket implementation know that
> all the possible ServletContextListeners have been called ? Are
> websocket implementations going to have to rely on something proprietary
> in the web container to tell them that ?
This is relatively simple in Tomcat's implementation because each
registration adds a servlet mapping to the web socket servlet via the
Servlet API. If I try to do that once the servlet context has started it
will fail.
> Or could it be more easily marked by noting the first occurrence of the
> web container passing on the first opening handshake to an endpoint in
> the application ?
Yeah, that could be tricky for other implementations.
Mark