Update: it seems that option #1 is off the table. >From the Java WebSockets specification:
4.1 @ServerEndpoint "This class level annotation signifies that the Java class it decorates must be deployed by the implementation as a websocket server endpoint and made available in the URI-space of the websocket implementation. The class must be public, CONCRETE, and have a public no-args constructor." :( Option #2 - opting for concrete service class alone - would mean losing the ability to set a scope of 'per thread', yes? I may have to discard the WebSocket annotations and create the server endpoint programmatically in that case. Regards, Chris. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
