1. You may attach a debugger by editing the wrapper.conf file;
wrapper.java.additional.3=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
Additionally, I added to the invocation of mule a -debug flag, e.g. in the hello example;
exec "$MULE_BASE/bin/mule" -debug -config hello-http-config.xml
2. Let’s look at the hello example; The config.xml file consists of a set of definitional items, e.g.
<custom-transformer name="StringToNameString"/>
and then continues with a model which consists of a set of services;
<model name="helloSample">
<service name="GreeterUMO">
</service>
<service name="ChitChatUMO">
</service>
<service name="UserErrorHandler">
</service>
<service name="SystemErrorHandler">
</service>
</model>
Each service seems to feature an <inbound>, a <component> and an <outbound> section;
<inbound>
<inbound-endpoint address="http://localhost:8888" transformer-refs="HttpRequestToNameString" synchronous="true">
</inbound-endpoint>
<inbound-endpoint address="servlet://name" transformer-refs="HttpRequestToNameString" synchronous="true">
</inbound-endpoint>
<inbound-endpoint address="servlet://rest" transformer-refs="HttpRequestToParameter StringToNameString" responseTransformer-refs="PlainTextResponseTransformer" synchronous="true"/>
<vm:inbound-endpoint path="greeter" transformer-refs="StringToNameString" synchronous="true"/>
</inbound>
<component/>
<outbound>
<filtering-router>
<vm:outbound-endpoint path="chitchatter" synchronous="true"/>
<payload-type-filter expectedType="org.mule.example.hello.NameString"/>
</filtering-router>
<filtering-router>
<vm:outbound-endpoint path="userErrorHandler" synchronous="true"/>
<payload-type-filter expectedType="java.lang.Exception"/>
</filtering-router>
</outbound>
<!-- Route unexpected errors to separate error handler -->
<default-service-exception-strategy>
<vm:outbound-endpoint path="systemErrorHandler"/>
</default-service-exception-strategy>
You may, it seems define multiple inbound-endpoints. It seems there is a vm:inbound-endpoint for every service and which precedes the component part.
2.1. outbound and inbound endpoints seem to match on path, e.g.
<vm:outbound-endpoint path="chitchatter" synchronous="true"/>
matches
<vm:inbound-endpoint path="chitchatter" ../>
2.2. Which method on components are called? Seems there is a fair amount of reflection going on. With the
<service name="ChitChatUMO">
<inbound>
<vm:inbound-endpoint path="chitchatter" transformer-refs="NameStringToChatString" responseTransformer-refs="ChatStringToString" synchronous="true"/>
</inbound>
<component/>
</service>
mule will pick a unique public method from ChitChatter that doesn’t match
“ignoredMethods=[getClass, clone, equals, hashCode, getInvocationHandler, get*, wait, is*, notify, toString, notifyAll]”
If there are more than one match, you add a method parameter, url style;
<vm:inbound-endpoint path="chitchatter?method=chat1"../>
2.3. How does Mule know which types to use when calling and filtering?
a. In <inbound-endpoint address=”http://localhost:8888″ transformer-refs=”HttpRequestToNameString” synchronous=”true”>
HttpRequestToNameString is an AbstractTranformer and returns a NameString.
b. Greeter.greet(NameString) receives this data.
c. In the filtering-router, the router selects according to type; <payload-type-filter expectedType=”org.mule.example.hello.NameString”/>
d. in <vm:inbound-endpoint path=”chitchatter” transformer-refs=”NameStringToChatString” responseTransformer-refs=”ChatStringToString” synchronous=”true”/> the component class is called after the transformer NameStringToChatString is called. Input is then ok.
Recent comments