Как избежать генерации XOP в CXF - поведение изменилось между 3.3.2 и 3.3.4 - PullRequest
Новая
       36

Как избежать генерации XOP в CXF - поведение изменилось между 3.3.2 и 3.3.4

0 голосов
/ 02 февраля 2020

Эта проблема связана с недавним изменением CXF (3.3.2-> 3.3.4).

Мы отправляем запрос SOAP нашему партнеру с содержанием изображения на TomEE 8.0.0 (CXF 3.3.2) ), сгенерированный запрос SOAP не включает генерацию XOP: 

<ns3:Picture>
<ns6:Image>
<ns6:StorageFormat>JPG</ns6:StorageFormat>
<ns6:Length>13286</ns6:Length>
<ns6:Buffer>/9j/4AAQSkZJRgABAAEAlgCWAAD//gAfTE (...) VBRCB=</ns6:Buffer>
</ns6:Image>
</ns3:Picture>
<ns3:Signature>
<ns6:Image>
<ns6:StorageFormat>TIF</ns6:StorageFormat>
<ns6:Length>700</ns6:Length>
<ns6:Buffer>SUkqAAgAAAATAP4ABAABAAAAAgAAAAABBAABAA (...) AA+==</ns6:Buffer>
</ns6:Image>
</ns3:Signature>

При выполнении кода isMTOMEnabled () возвращает false 

SOAPBinding binding = (SOAPBinding) ((BindingProvider) port).getBinding();
boolean mtomEnabled = binding.isMTOMEnabled();

Та же война развернута на TomEE 8.0.1 (CXF 3.3.4). Теперь CXF генерирует (не запрашивается) XOP 

<ns3:Picture>
<ns6:Image>
<ns6:StorageFormat>JPG</ns6:StorageFormat>
<ns6:Length>12099</ns6:Length>
<ns6:Buffer>
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:61bc1e4b-5e7c-47ea-ae1e-fc0ce1edbdd5-1@www.astra.admin.ch"/>
</ns6:Buffer>
</ns6:Image>
</ns3:Picture>
<ns3:Signature>
<ns6:Image>
<ns6:StorageFormat>TIF</ns6:StorageFormat>
<ns6:Length>580</ns6:Length>
<ns6:Buffer>
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:61bc1e4b-5e7c-47ea-ae1e-fc0ce1edbdd5-2@www.astra.admin.ch"/>
</ns6:Buffer>
</ns6:Image>
</ns3:Signature>

Поскольку наш партнер не может анализировать xop, как можно избежать включения xop SOAP и получить тот же результат, что и ранее с CXF 3.3.2?

...