jsr356-experts@websocket-spec.java.net

[jsr356-experts] Re: [jsr356-users] Re: More more programmatic deployment

From: Mark Thomas <mark_at_homeinbox.net>
Date: Wed, 27 Feb 2013 09:57:09 -0800

On 27/02/2013 09:27, Danny Coward wrote:
> On 2/27/13 9:16 AM, Mark Thomas wrote:

>> >>> ... we are currently trying to restrict there to be one
>>>>> ServerContainer instance per websocket application. Do you have enough
>>>>> context under the ServerContainerProvider*.getServerContainer();
>>>>> call to
>>>>> do that ?
>>>>
>>>> Yes. Currently I use the current context classloader (which is the web
>>>> application class loader in a servlet container) to ID the right
>>>> ServerContainer / determine I need to create a new one.
>>> OK thanks Mark. Then I think this works too.
>>
>> The second point is related to the above.
>>
>> There is enough information if I make use of container internal API
>> but I'd like to avoid that if at all possible.
>>
>> 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).

Let's assume I can avoid this problem and that the setRoot() method is
unnecessary.

Mark