So I think you basically have two options: 1) Move the annotations to the service interface. This way, the endpoint library would call your code with the service interface and you wouldn't have casting issues. 2) Not defining the service as an interface, but as a concrete class. Instead of binder.bind(HarbourServerEndpoint.class, HarbourServerEndpointImpl.class), just binder.bind(HarbourServerEndpointImpl.class).
I'd go with #1. On Fri, Apr 19, 2019 at 8:37 AM Christopher Dodunski < chrisfromtapes...@christopher.net.nz> wrote: > Hi Thiago, > > >> Why is it even referencing HarbourServerEndpointImpl? This, the service > >> implementation class, should only be referenced in AppModule (or other > >> Tapestry-IoC module) when declaring the service and maybe also when > making > >> unit tests. Everything else should use HarbourServerEndpoint instead. > > It seems that, when Tomcat invokes the "<T> T getEndpointInstance(Class<T> > endpointClass)" method, Class<T> type is the class decorated with the > @ServerEndpoint annotation - HarbourServerEndpointImpl.class in my case. > Consequently, this method must return an instance of this class. And a > service proxy object - even though it implements the same interface - > ultimately is another type. > > To date, my only option has been to define the endpoint service as a > concrete implementation class, without binding it to any interface. This > means that Tomcat gets an instance of the class annotated with > @ServerEndpoint, just as it expects. > > Tapestry still injects into this concrete implementation class its needed > dependencies (eg. VesselStateTracker), which is a saving grace. But doing > away with the interface comes at a cost. Quoting from Igor Drobiazko's > book on Tapestry 5: > > "It's highly discouraged to define services as concrete classes. Such > services will not have a proxy and so will lose some very important > characteristics. For example, you will not be able to define a scope for > the particular service. You also will lose the possibility to advise and > decorate your service." > > If anyone has a better solution, I'd love to hear it. :-) > > Regards, > > Chris. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Thiago
