Hi Thiago, Indeed, if I want to provide endpoints as a Tapestry-IoC service, singleton may be the only option. Running as a 'per thread' service, connections are successfully established, but subsequent method calls on the connection by Tomcat - like to @OnError and/or @OnClose - results in the registry returning a new instance (not desirable). So seems I will have to do like you suggested, which means no longer being able to persist connection endpoints to a static map with a simple 'connections.put(this)'.
The good news is that Tomcat now successfully fetches endpoint instance(s) from the Tapestry-IoC registry, and in the end without even needing a custom Configurator. :-) Quoting from the Oracle documentation on WebSocket endpoints: "When deployed as a server endpoint, the implementation uses the ServerEndpointConfig.Configurator.getEndpointInstance(java.lang.Class<T>) method to obtain the endpoint instance it will use for each new client connection. If the developer uses the default ServerEndpointConfig.Configurator, there will be precisely one endpoint instance per active client connection. Consequently, in this typical case, when implementing/overriding the methods of Endpoint, the developer is guaranteed that there will be at most one thread calling each endpoint instance at a time. If the developer provides a custom ServerEndpointConfig.Configurator which overrides the default policy for endpoint instance creation, for example, using a single Endpoint instance for multiple client connections, the developer may need to write code that can execute concurrently." Regards, Chris. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
