Apache CXF/MTOM развращает файл при запуске через Weblogic 12c

Question

Я запускаю клиентский веб-сервис на основе CXF (использует веб-службу со стороны .net). Все работает отлично, кроме передачи файла PDF.

Если я запускаю ту же конфигурацию через junit (подпружиненный контекст и cxf), либо я использую один и тот же веб-сервис с помощью soap-ui, файл pdf переносится правильно.

Как только я запустил его через Weblogic 12c (12.1.3), двоичное содержимое pdf будет повреждено. Вот пример:

* Good File (transferred via CXF standalone/junit) * 
%PDF-1.3 
1 0 obj 
[/PDF /Text /ImageB /ImageC /ImageI] 
endobj 
9 0 obj 
<< /Length 1659 /Filter /FlateDecode >> stream 
xœXÛnÛ8}_ 

* Bad File (transferred via WLS/CXF) * 
%PDF-1.3 
1 0 obj 
[/PDF /Text /ImageB /ImageC /ImageI] 
endobj 
9 0 obj 
<< /Length 1659 /Filter /FlateDecode >> stream 
xœ�XÛnÛ8}_ 

Вы можете увидеть в разделе потока, получая дополнительные байты там (это только начало файла ... дополнительный байт показывает много раз после этого). Запуск этого окна или Linux закончится поврежденной передачей. Java 8. CXF 2.7 и 3.1.

Я все еще изучаю проблему, но любые идеи с верхней части головы будут оценены.

• Это кодировка, которая должна быть установлена ​​/ снята где-нибудь?
• Являются ли некоторые предпочтительные библиотеки в веб-модуле, которые следует использовать?
• Возможно, пропал только патч для сервера приложений? -

...

Answer 1

Как я уже объяснил в комментариях, виновником коррупции был обработчик регистрации, впрыскивается в качестве входящего перехватчик сообщений. Он кодировал все сообщение в UTF-8, включая двоичный контент.

Client client = ClientProxy.getClient(port); 
client.getInInteceptors().add(inLogger); 

Однако я не нашел, почему этот регистратор не вызывал проблем за пределами контейнера weblogic. Говорить о поддержке Oracle не помогло, так как они хотели, чтобы я представил исполняемый тестовый пример, который реплицирует проблему ... которая граничит с невозможным (т. Е. Веб-сервис размещается другой компанией).

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

Endpoint endpoint = client.getEndpoint(); 
HTTPConduit conduit = (HTTPConduit) client.getConduit(); 
conduit.setMessageObserver(new MyMessageObserver(client)); 

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

@Override public void onMessage(Message message) { 
    InputStream is = message.getContent(InputStream.class); 
    InputStream mis = save(is); 
    is.reset(); 
    client.onMessage(message); 
    message.setContent(InputStream.class, mis); 
} 

Другие инъекции обработчика очевидно сообщение совершающихся через In/OutInterceptors(), и если вы посмотрите на трубопроводе вы можете инъекционные их в любом месте, на определенных этапах обработки сообщений .. ON-RECEIVE, занесенным в STREAM и т. Д. Согласно http://cxf.apache.org/docs/interceptors.html. Они будут частью конвейера, но после того, как клиент начнет работать. MyMessageObserver находится перед конвейером.

Надеется, что это помогает при отладке Apache CXF ...