ClassCastException при отправке запроса на мыло

Question

Я работаю над проектом, в котором уже реализован клиент веб-сервиса. Теперь мне нужно было добавить другого клиента для разных сервисов. Я реализовал новый клиент, но теперь он выдает исключение, когда есть заголовки (требуются заголовки). Если я удалю все банки метро, ​​этот новый клиент будет работать отлично, но, очевидно, мой клиент-клиент не работает. Мне нужно руководство по возможным вариантам, обходным решениям или решениям.

Caused by: javax.xml.ws.WebServiceException: java.lang.ClassCastException: com.sun.xml.ws.message.saaj.SAAJHeader cannot be cast to com.sun.xml.ws.security.opt.impl.outgoing.SecurityHeader 
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processRequest(SecurityClientTube.java:250) 
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:961) 
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:910) 
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:873) 
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:775) 
at com.sun.xml.ws.client.Stub.process(Stub.java:429) 
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:168) 
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119) 
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:102) 
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:151) 
at com.sun.proxy.$Proxy70.methodName(Unknown Source) 
... 15 more 

Caused by: java.lang.ClassCastException: com.sun.xml.ws.message.saaj.SAAJHeader cannot be cast to com.sun.xml.ws.security.opt.impl.outgoing.SecurityHeader 
    at com.sun.xml.ws.security.opt.impl.JAXBFilterProcessingContext.setJAXWSMessage(JAXBFilterProcessingContext.java:166) 
    at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.secureOutboundMessage(SecurityTubeBase.java:381) 
    at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientRequestPacket(SecurityClientTube.java:323) 
    at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processRequest(SecurityClientTube.java:247) 

Я нашел несколько вопросов, с подобной проблемой, как here, но все они в конечном итоге предлагая удалить заголовки, которые не вариант для меня.

PS: Для существующего клиента webservice, который использует метрические банки, мы используем коннектор как клиент (его банку, которая фактически включает в себя все связанные с метро классы), предоставляемые сторонними серверами для подключения к их серверу (что я думаю очень странно). Если я перемещаю что-либо из соединителя, он отменяет соглашение о поддержке. Поэтому я предпочитаю не удалять банки метро, ​​но найти альтернативный способ разместить с ним.

Answer 1

Кажется довольно ясным, что происходит то, что в третьей библиотеке существуют противоречивые версии библиотеки метро, ​​а также новые библиотеки метро, ​​которые вы пытаетесь использовать.

Моя первая мысль заключается в том, что у вас есть контроль над порядком пути к классам? Не могли бы вы поместить свои собственные метровые банки в любой конец пути к классу, чтобы убедиться, что это имеет значение?

Возможно, было бы лучше попытаться реализовать собственный интерфейс с точки зрения библиотек метро, ​​включенных в стороннюю библиотеку? Я не уверен, что эта версия информации доступна вам, но большинство современных IDE должны иметь возможность декомпилировать классы в стороннем банке для вас. Если бы я был в вашей ситуации, это было бы первым, что я попробовал бы, так как у него есть «наименее движущиеся части» и использует уже доступные вам зависимости.

Другим вариантом является запуск одного или другого клиента в отдельной виртуальной машине и доступ через базовый интерфейс RMI. Не знаю, что знаю.

Возможно, вы также попробуете исследовать Maven shade plugin, который поддерживает переупаковку библиотек, чтобы они не сталкивались с другими версиями, хотя я не уверен, насколько хорошо это работает с предварительно скомпилированными двоичными файлами - в частности, с той сложностью, которая задействована в пакетах JAX-WS ...