2015-07-07 11 views
6

Mam metodę Java, który będzie przeczytać kilka zmiennych przepływów, zrobić kilka agregację i dołączyć wynik do listy, która już istnieje w innej zmiennej przepływu.Przechodząc MuleMessage metody Java z Mule powołać

Z tego powodu metoda spodziewa się MuleMessage. Myślałem, że to oczywiście możliwe, aby przejść MuleMessage sposobu java, używając zmiennej message MEL jak:

<invoke object-ref="Aggregator" method="aggregateSingle" methodArguments="#[message]" doc:name="Invoke"/> 

Ale okazało się, że to przechodzi MessageContext obiekt zamiast. Ale muszę ustawić InvocationVariable, więc ta klasa nie jest przydatna. Wiem, że zestaw zmiennych w Groovy, więc być może to będzie działać (myślałem):

<invoke object-ref="Aggregator" method="aggregateSingle" methodArguments="#[groovy:message]" doc:name="Invoke"/> 

Ale nie, to jakoś przechodzi payload zamiast MuleMessage.

Więc jedynym sposobem znalazłem na to jest rzeczywiście nazwać w Groovy komponentu jak poniżej. Co oznacza, że ​​za każdym razem muszę utworzyć nowy obiekt Aggregator, zamiast używać planowanego spring:bean.

   <scripting:transformer doc:name="aggregateSingle"> 
        <scripting:script engine="Groovy"><![CDATA[ 
         new com.example.Aggregator().aggregateSingle(message); 
         message 
        ]]></scripting:script> 
       </scripting:transformer> 

Czy nie ma sposobu, aby przekazać MuleMessage obiektu do metody Java z wykorzystaniem invoke?

+0

Dlaczego chcesz użyć wywołania komponentu, a następnie połączyć to z API Mule? ... pomysł na 2 sposoby tworzenia komponentów polega na tym, że jeden sposób wiąże Cię z interfejsem Mule API, a drugi nie. – Sudarshan

+0

@Sudarshan Chcę zachować kod muła w czystości. W moim strumieniu są dwie gałęzie, jedna używająca "zbierania rozproszonego" i drugiej, która jest sekwencyjna. Ta ostatnia prowadzi do podobnego obiektu, który jest generowany przez AggregationStrategy of the first. Chciałbym zatem ponownie wykorzystać funkcjonalność ze strony AggregationStrategy. Pozwala również na bardziej precyzyjne testowanie. Pytasz, dlaczego chcę przekazać "MuleMessage" (czyli klasę Mule API) do mojej klasy? Dzieje się tak, ponieważ jest to łatwiejsze niż przekazywanie 5 indywidualnych zmiennych przepływu. – rewolf

+1

daje +1 pytanie, jednak chciałbym rozważyć utworzenie POJO z 5 flowVariables i przepuszczenie POJO do składnika, zwłaszcza jeśli rozważa możliwość testowania i czysty kod. Czekamy na odpowiedź :) – Sudarshan

Odpowiedz

1

Domyślnie mel używa kontekstu wiadomości do odnoszenia się do zmiennej message, w rzeczywistości służy to jedynie pomocą w wyrażeniach pospolitych, takich jak message.payload! = Null (w poprzednich wersjach muła musiałbyś sprawdzić wartość pustą). Mam debugowany elementu invoke i niestety nie ma wyrażenia będzie go wyciąć, ale ten jest równoważny sposób, że można użyć

<expression-transformer expression="#[groovy: Aggregator.aggregateSingle(message)]" /> 

to działa zgodnie z oczekiwaniami, ponieważ Groovy ma bezpośredni dostęp do rejestru fasoli, dzięki czemu można odwoływać się do fasoli nazwać i zachować go jako fasoli wiosny (jak i wyobraź sobie, że chcą mieć)

+0

To działało, trochę. To zdecydowanie powinno zadziałać. Ale z jakiegoś powodu wywołuje on metodę dwukrotnie. – rewolf

+0

To był błąd MUnit. Dokonałem aktualizacji z wersji 3.6.0-SNAPSHOT do wersji 3.6.0-RC1-SNAPSHOT i ten błąd zniknął. Jednak pojawiły się inne błędy MUnit z zniknięciem FlowVariables. Ale twoja odpowiedź była dobra, dzięki! :RE – rewolf