Использование собственного Конфигуратора с WebSockets

Question

Просто быстрый вопрос о расширении ServerEndpointConfig.Configurator для переопределения действия Tomcat по умолчанию - создания экземпляра класса POJO, аннотированного @ServerEndpoint, при получении запроса WebSocket.Моя причина для этого заключается в том, что мой класс конечных точек зависит от внедрения зависимостей IoC, и поэтому его необходимо получить из реестра, чтобы иметь свои зависимости.

Метод My Configurator:

@Override 
public <T> T getEndpointInstance(Class<T> endpointClass) throws InstantiationException { 
    return endpointClass.cast(RegistryProxy.getService(HarbourServerEndpoint.class)); 
} 

Аннотация @ServerEndpoint размещена на моем классе POJO HarbourServerEndpointImpl, а не на интерфейсе, который он реализует.Основываясь на приведенном ниже сообщении об ошибке catalina.out, проблема заключается в том, что реестр возвращает HarbourServerEndpoint, а Tomcat ожидает экземпляр HarbourServerEndpointImpl?

Я надеюсь, что кто-нибудь может объяснить, что не так с моим пользовательским Конфигуратором.

15-Apr-2019 12: 45: 28.488 SEVERE [http-nio-8080-exec-915] org.apache.coyote.AbstractProtocol $ ConnectionHandler.process Ошибка чтения запроса, игнорируется java.langИсключение) в org.apache.tomcat.websocket.pojo.PojoEndpointServer.onOpen (PojoEndpointServer.java:44)

    at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:133)

    at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:846)

    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1471)

    at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)

    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

    at java.lang.Thread.run(Thread.java:748) 

Наконец, без приведения вообще, компилятор выдает ошибку:

Error:(17, 40) java: incompatible types: inference variable T has incompatible bounds 
    equality constraints: com.optomus.harbour.services.HarbourServerEndpoint 
    upper bounds: T,java.lang.Object

Answer 1

С момента публикации этого вопроса я исследовал Tapestry-IoC и как он работает.Оказывается, есть причина для того, что возвращается немного странно ($ HarbourServerEndpoint_39c9cc24eb8b2a).Это объект прокси сервиса, а не экземпляр реализации сервиса, как я ожидал.Я не уверен, насколько это типично для контейнеров IoC.Цитата с сайта Tapestry:

"Сервисы состоят из двух основных частей: интерфейс сервиса и реализация сервиса.

Интерфейс сервиса - это способ представления сервиса в остальной части реестра.Так как то, что передается, обычно является прокси, вы не можете ожидать, что объект службы будет приведен к классу реализации (вместо этого вы увидите ClassCastException). Другими словами, вы должны быть осторожны, чтобы убедиться, что ваш интерфейс службызавершен, так как Tapestry IoC эффективно защищает вас от задних дверей, таких как приведение. "

Это делает довольно сложным получение из реестра IoC экземпляров класса, аннотированного @ServerEndpoint, и сейчас я изучаюдругие варианты.

С уважением,

Крис.