Your idea of wrapping the interface returned by the registry was a stroke
of brilliance! And I'm pleased to say it was successful.
I'm now working to resolve another small hiccup. The IoC registry can be
configured to provide the service as either a singleton or a new instance
for each new threa
Hmm.
Looking at this some more I'm not sure this is going to work.
HarbourServerEndpoint needs to extend javax.websocket.Endpoint which it
can't do as an interface.
I think you are going to have to wrap the instance returned by the
registry. In which case you can probably go back to using POJO.
So I've converted the server endpoint from annotation-based to
programmatic, to get around the constraint of the @ServerEndpoint
annotation having to decorate a concrete class. The elements of this
annotation now occupy an implementation of ServerApplicationConfig:
public class HarbourServerAppl
Thanks Mark, you've made it clear that annotating the interface is not an
option.
Converting my server endpoint from annotation based to programmatic is not
a problem, nor is implementing ServerApplicationConfig to configure what
were previously @ServerEndpoint elements: value, encoders, decoders,
On 24/04/2019 07:16, Christopher Dodunski wrote:
> Hi Mark,
>
> Looking at the Tapestry-IoC Registry code I notice that although it
> constructs a (plastic) service proxy object, it does cast it to its
> associated interface before making it available from the registry's
> getService() method. So
Hi Mark,
Looking at the Tapestry-IoC Registry code I notice that although it
constructs a (plastic) service proxy object, it does cast it to its
associated interface before making it available from the registry's
getService() method. So if I move the WebSocket annotations to my
interface as previ
Based on what you wrote regarding WebSocket annotations not following Java
inheritance, I imagine the below wouldn't work either.
public class MyServerEndpointConfig extends ServerEndpointConfig {
@Override
public Class getEndpointClass() {
return MyServiceInterface.class;
}
> The custom Configurator looks fine. The problem is with trying to do
> this with a POJO endpoint. There is an underlying assumption that - for
> a POJO endpoint - the endpoints will will instances of the POJO class.
> This doesn't seem to hold in your case so hence it breaks.
>
> The WebSocket sp
On 17/04/2019 22:58, Christopher Dodunski wrote:
> Hello,
>
> Just a quick question with regard to extending
> ServerEndpointConfig.Configurator to override Tomcat's default action of
> instantiating the POJO class annotated with @ServerEndpoint on receiving a
> WebSocket request. My reason for d
