2015-06-23 2 views
1

Поэтому я использую старую версию Mule (3.3.1) и Джерси (1,6) -очень новый обоим и не в состоянии upgrade- и имеет аналогичную проблему с "null in FormParam with “charset=UTF-8” in Jersey 2.0" в том, что данные формы HTML @POST ed всегда null, но с использованием (для принудительной кодировки без UTF-8) не имеет значения, мои @FormParam s по-прежнему null.Как подкрасться мое тело сообщения мимо Джерси, возможно, с помощью Mule

<flow name="repo" doc:name="Repository application"> 
    <inbound-endpoint ref="RepositoryInternalEndpoint"> 
     <not-filter> 
      <wildcard-filter pattern="/favicon.ico"/> 
     </not-filter> 
    </inbound-endpoint> 

    <!-- All seems fine at this point --> 
    <!--<custom-interceptor class="TestInterceptor"/>--> 

    <!-- Inside the RepositoryService class, @FormParam args are null --> 
    <jersey:resources doc:name="Repository Service Component"> 
     <component> 
      <spring-object bean="repositoryService"/> 
     </component> 
    </jersey:resources> 
</flow> 

Кажется, что Джерси просто ест мое тело запроса. Учитывая, что если я вставляю TestInterceptor (в комментариях выше), который просто выводит свойства сообщения, включая тело сообщения, и @FromParam s, все ожидаемые данные есть. Есть ли способ остановить Джерси это сделать или получить данные заранее?

Ожидаемые @FormParam аргументы все String как таковой ...

@POST 
@Path("/my/url") 
@Consumes(MediaType.APPLICATION_FORM_URLENCODED) 
@Produces(MediaType.TEXT_HTML) 
public Response myMethod(@FormParam("o_serviceId") String serviceId){} 

команда была использована

curl -X POST -H "content-type: application/x-www-form-urlencoded" -d "o_serviceId=12345y" localhost:8889/my/url 
+1

Что такое ожидаемый 'Content-Type' метода, аннотированный с помощью' @ FormParam'? Какую команду 'curl' вы использовали? –

+0

Оба добавили к вопросу. –

+1

Спасибо. Все выглядит прекрасно, поэтому кажется, что это ошибка. Можете ли вы потенциально развернуть приложение в более позднем Mule, чтобы проверить, исправлена ​​ли проблема? –

ответ

1

Я считаю, что вы получаете укусила этой давней проблемы: https://www.mulesoft.org/jira/browse/MULE-5687

Сравнивая полезную нагрузку сообщения Mule между соединителями HTTP и Jetty, я заметил, что t это фактически пустая строка для application/x-www-form-urlencoded запросов для последнего, в то время как она содержит фактическое тело для первого.

Действительно, если я добавлю это перед jersey:resources, все работает отлично:

<set-payload 
    value="#[org.mule.util.StringUtils.join(message.inboundProperties['request.parameters'].entrySet(),'&amp;')]" /> 

Это в основном перестраивает полезную нагрузку сообщения из параметров запроса. Это быстрое и грязное исправление: оно неправильно перекодирует параметры и предполагает, что Map.Entry.toString() всегда возвращает key=value. Но это легко улучшить с помощью правильного преобразования Map to URL-encoded string ...

+0

Это звучит правильно, я дам это попробовать позже на этой неделе. –

+0

Это работает. Отлично, спасибо. Не было бы, если бы переместить его в параметры. –