2015-11-25 2 views
0

Создание прокси-сервера HTTP в Spring Integration 4.2.1.RELEASE. В среде используется последняя спецификация платформы 2.0.0.RELEASE, включая слой spring-webmvc - работает на Tomcat7.Проблема с приложением/json-ответом, выполняемым в Spring Integration 4.2

Звонки - это «приложение/json», прошедшее через веб-уровень на другую конечную точку сервера REST (метод setupUrl переписывает URL-адрес). Код успешно вызывает внешний сервер, получает хороший ответ, затем обрабатывает ответ, прежде чем он вернется к вызывающему.

@Bean 
    public IntegrationFlow httpProxyFlow() { 
     return IntegrationFlows 
      .from((MessagingGateways g) -> 
        g.httpGateway("/my-service/**") 
          .messageConverters(new MappingJackson2HttpMessageConverter()) 
         .payloadFunction(httpEntity -> 
           ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()) 
             .getRequest() 
             .getQueryString()) 
         .requestPayloadType(String.class)) 
         .handleWithAdapter(a -> 
           a.httpGateway(this::setupUrl) 
             .httpMethodFunction(this::getMethodFunction) 
             .errorHandler(new PassThroughErrorHandler()) 
             .encodeUri(false) 
             .expectedResponseType(String.class) 
         ).get(); 
    } 

вызов непосредственно к конечной точке REST возвращает

{ "филиал": "Тест", "производитель": "ТСТ", "продукты" ...

В то время как вызов через Spring Integration возвращает

"{\" филиал \ ": \" тест \ "\ "производитель \": \ "TST \", \ "продукции \": [{\"

Пробовал много комбинаций добавления StringHttpMessageConverter к исходящему адаптеру. Мессинг с кодировками (UTF-8, а не ISO-8859-1). Что-то возится со строкой ответа, и, похоже, ПОСЛЕ того, что она уходит из Spring Integration, насколько я могу судить. Последний раз, когда Интеграция затрагивает это, это HttpRequestHandlingMessagingGateway.handleRequest() строка 117. Она по-прежнему выглядит правильно в объекте ответа там.

Возможно, проблема связана с spring-mvc, это первое место, где я вижу искаженную строку при отладке.

ответ

1

Наилучшая догадка - это некоторая проблема с accept (входящий) или content-type (исходящий).

Я просто изменил образец HTTP, как так ...

<int-http:inbound-gateway request-channel="proxyChannel" 
          reply-channel="reply" 
          path="/receiveGateway" 
          supported-methods="POST"/> 

<int:channel id="reply" /> 

<int-http:outbound-gateway request-channel="proxyChannel" 
       reply-channel="reply" 
       expected-response-type="java.lang.String" 
       url="http://localhost:8080/http/receiveGateway2"/> 

<int-http:inbound-gateway request-channel="receiveChannel" 
          path="/receiveGateway2" 
          supported-methods="POST"/> 

<int:channel id="receiveChannel"/> 

<int:chain input-channel="receiveChannel"> 
    <int:header-filter header-names="content-type" /> 
    <int:service-activator expression='{"foo" : "bar"}'/> 
</int:chain> 

Полезная нагрузка возвращается в первый шлюз имеет тип String; он работает для меня с входящим accept от text/plain или application/json.

С StringHttpMessageConverter впереди преобразователя сообщений JSON в списке, а полезная нагрузка является String, он выбран потому, что тип String и что преобразователь может обрабатывать */*accept, так что нет никакого двойного кодирования в формате JSON.

{"foo":"bar"} получен моим клиентом.

Если вы не можете понять это с помощью протокола DEBUG и/или отладчика, вы можете попробовать переконфигурировать входящий шлюз только с StringHttpMessageConverter.

Установите точку останова в строке 151 (текущий выпуск) в HttpRequestHandlingMessagingGateway, чтобы увидеть, какой исходящий конвертер сообщений выбран.

+0

Я переключился на StringHttpMessageConverter только для входящих и исходящих и вызвал setSupportedMediaTypes() со всеми вариациями MediaType, которые я хотел. Теперь я запускаю проблему contentType https://jira.spring.io/browse/INT-3508 и работаю над этим. Я задам еще один вопрос, не могу ли я понять это ... – javatestcase

Смежные вопросы