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
