Почему компонент REST не получает вызов, сделанный внутренним для приложения, когда настроено несколько глобальных HTTP-коннекторов?

Question

Я изо всех сил пытаюсь настроить и развернуть CloudHub приложение с несколькими глобальными HTTP-коннекторами и компонентом REST.

Мое приложение имеет два потока: один опрос RSS-канала для новостей и отправляет json-представление этого фида на входящую конечную точку http в том же приложении (конечная точка находится во втором потоке). Второй поток получает этот пост, выполняет некоторую магию, в том числе сохраняя элемент для хранения, а затем уведомляет через конечную точку http внешнее веб-приложение node.js, чтобы направить элемент через веб-сокеты активным клиентам.

Я пробовал то, что чувствует себя как десятки различных конфигураций, связанных с множеством глобальных соединителей HTTP и http и исходящих конечных точек, но я не могу заставить все работать. Я в настоящее время:

1. социологического HTTP Connector
   • HTTP-конечная точка ссылки выше соединителя HTTP опроса, чтобы получить RSS Feed
2. One Global Connector (мы будем называть HTTP_ONE), чтобы получать сообщения на localhost:${http.port}
   • НТТР oubound конечная точка сконфигурированы ссылки HTTP_ONE и выполненный с возможностью отправлять активностью/API/v1/Activity
   • Входящая конечная точка http настроена для приема сообщений для /api/v1 и контроллера Джерси, сидящего за этой конечной точкой, которая принимает /activity.
3. Другой глобальный соединитель (HTTP_TWO) с внешним хостом, установленным как имя хоста прокси (например, somehost.somewhere.com).
   • НТТР исходящая конечная точка настроена для отправки сообщений в somehost.somewhere.com

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

В CloudHub я использую localhost и $ {http.port} везде, кроме оконечной точки Oubound, которая вызывает внешнюю веб-службу.

Я могу получить один поток или другой рабочий, но не оба .... Моя проблема связана с отправкой данного новостного материала из RSS-канала на входящую HTTP-конечную точку. Он отправляет сообщение в http://localhost:80/api/v1/activity, но соединитель говорит, что такого пути нет (он только перечисляет/api/v1 в качестве опции), что заставляет меня думать, что вызов не доходит до контроллера Jersey, который сидит за Глобальный соединитель и конечная точка http для /api/v1/activity. Является ли это поведение неотъемлемым недостатком использования компонента REST и нескольких глобальных HTTP-коннекторов? Кроме того, почему мы должны ссылаться на глобальный HTTP-коннектор при выполнении исходящего вызова? Почему мы не можем использовать HTTP-коннектор по умолчанию? (Может быть, последние два вопроса должны идти в следующем посте ...)

Вот наиболее соответствующей конфигурации для двух потоков:

Глобальные разъемы

<http:polling-connector name="PollingHttpConnector" pollingFrequency="60000" doc:name="HTTP Polling" clientSoTimeout="10000" cookieSpec="netscape" receiveBacklog="0" receiveBufferSize="0" sendBufferSize="0" serverSoTimeout="10000" socketSoLinger="0" validateConnections="true"/> 
<http:connector name="EduStream_HTTP" cookieSpec="netscape" validateConnections="true" sendBufferSize="0" receiveBufferSize="0" receiveBacklog="0" clientSoTimeout="10000" serverSoTimeout="10000" socketSoLinger="0" proxyHostname="${edustream.host}" doc:name="HTTP\HTTPS" proxyPort="80"/> 
<http:connector name="EduStreamESB_HTTP" cookieSpec="netscape" validateConnections="true" sendBufferSize="0" receiveBufferSize="0" receiveBacklog="0" clientSoTimeout="10000" serverSoTimeout="10000" socketSoLinger="0" proxyHostname="localhost" proxyPort="${http.port}" doc:name="HTTP\HTTPS"/> 

Новости RSS поток Поток

<flow name="ucdNewsConsumer" doc:name="ucdNewsConsumer"> 
    <http:inbound-endpoint address="http://news.ucdavis.edu/xml/getnews.php/rss/category/General%20Interest" 
     connector-ref="PollingHttpConnector" doc:name="HTTP" exchange-pattern="one-way"/> 
    <rss:feed-splitter/> 
    <rss:entry-last-updated-filter/> 
    <component class="edu.ucdavis.edustream.esb.news.rss.EntryReceiver" doc:name="Java"/> 
    <logger message="#[payload]" level="INFO" doc:name="Logger"/> 
    <http:outbound-endpoint exchange-pattern="request-response" host="localhost" port="${http.port}" path="api/v1/activity" doc:name="HTTP" mimeType="application/json" connector-ref="EduStreamESB_HTTP" /> 
    <logger message="Payload is: #[payload] Inbound Headers: #[headers:INBOUND:*] Outbound Headers: #[headers:OUTBOUND:*] Exception is: #[exception]" level="INFO" doc:name="Logger"/> 
</flow> 

активность публик п Service - Core Flow

<flow name="edustreamesbFlow1" doc:name="edustreamesbFlow1"> 
    <http:inbound-endpoint exchange-pattern="request-response" host="localhost" port="${http.port}" doc:name="HTTP" contentType="application/json" mimeType="application/json" path="api/v1" connector-ref="EduStreamESB_HTTP"/> 
    <jersey:resources doc:name="REST"> 
     <component class="edu.ucdavis.edustream.esb.activity.restapi.ActivityController"/> 
    </jersey:resources> 
    <component class="edu.ucdavis.edustream.esb.activity.restapi.JerseyResponseTransformer" doc:name="JerseyRespTrans"/> 

    <flow-ref name="PublishActivity" doc:name="Publish Activity"/>   
</flow> 
<sub-flow name="PublishActivity" doc:name="PublishActivity"> 
    <component doc:name="ActivityService"> 
     <spring-object bean="activityService"/> 
    </component> 
    <logger message="#[payload] #[message]" level="INFO" doc:name="Logger"/> 
    <http:outbound-endpoint exchange-pattern="request-response" host="${edustream.host}" port="80" path="api/v1/activity" mimeType="application/json" contentType="application/json" doc:name="HTTP" connector-ref="EduStream_HTTP"/> 
</sub-flow> 

Answer 1

Я не понимаю, почему proxyHostname и proxyPort настроены на обоих EduStream_HTTP и EduStreamESB_HTTP разъемов в то время как HTTP конечные точки из этих разъемов нацелены на тот же хост/порт в качестве своего адреса назначения. Это не имеет никакого смысла для меня.

Действительно ли вы действительно вам нужны прокси?

Для EduStreamESB_HTTP ответ явно нет: вы вызываете CloudHub из CloudHub, поэтому нет необходимости в прокси-сервере.

Для EduStreamESB_HTTP, может быть ... но это все еще кажется очень странным.