Tag Archives: mule

mule with spring-beans and autowire…

… doesnt work 🙁

i really think (now partly thought) spring is cool… i used a spring-bean configfile, initialised all the entities and @Autowired them.. pretty cool… reflection on the entities to find and load them… and i think its really readable in java code… whenever you see an @Autowired… it will be created someware completely different and reflected to the position…

but autowiring with mule dont work… or i couldnt figure out how… mule runs its own context and the springcontext is somewhere in there… and the springcontext behaves different… crap… so new solution:

beans.xml

<bean id=”A” class=”ch.michio.spring.A”/>

<bean id=”B” class=”ch.michio.spring.B”>
     <property name=”a” ref=”A”/>
</bean>

so in class B there was an:

@Autowired
private A a;

 now there is a setter:

private A a;
public setA(A a){
     this.a = a;
}

So during initialisation

  1. an A object is created
  2. a B object is created
  3. a in spring bean container found A is set to B

my main problem with this solution is the readability… you need to read the java files AND the beans.xml… bah… 🙁

mule collection-splitter

in our project a simple flow should read mails from an imap mailserver and process those… sounds simple, but isnt… the mails need to be left on the server for further use… and it is not guaranteed, that no other user might access the mailbox with an other client and do stuff… so no save SEEN, UNSEEN states… the imapUid is used to identify the mail…

ok simple task with mule… just take the imap:connector… wrong! the imap:connector is a cool connector to read unseen mails of an mailbox and returns a MimeMessage object, which does not contain the imapUid… so bla… unusable in our case… but the checkFrequency is a really important feature, because we dont know how many mails are in the inbox and a frontend-triggered start command is unusable, because of the delay… so we need an other solution: build it…

simple as well… wrong again!… ok not really wrong, but complicated… we use a quartz:inbound_endpoint to trigger the flow… a MailFetcher class is called, which gets all the needed information and… ehm… ok here is the problem… the quartz:inbound_endpoint sends one start command into the flow… the MailFetcher gets all the mails and sends them to the next workflow… but i really want single mails in the next flow and not a list of mails… so… how the hell can this be done?   FilteringListMessageSplitter is the solution… or lets say looked like…

  FilteringListMessageSplitter accepts a List as a message payload then routes list elements as messages over an endpoint where the endpoint’s filter accepts the payload. (link)

 actually it is the solution… but this class only has for services… and not for flows… for flows: <collection-splitter>

  The Collection Splitter acts on messages whose payload is a Collection type. It sends each member of the collection to the next message processor as separate messages. (link)

which really works…

And with an correct test environment it would be a peace of cake to figure it out… but returning null instead of a java.util.List might be a problem to split…

mule flow

needed to reconfigure our mule-config and i was really confused about the whole mule documentation… i really think its crap, but i figured it out 🙂

first a side note to the documentation: we use flows… and a co-worker told me, that flows are kinda new, so not everything might work… its kinda documented, but without any example… so hard to figure it out…

so what did i need? just a simple flow, which sends the result to the next flow… so simple outbound to inbound…

mule-config.xml
<flow name="fooWorklow">
<vm:inbound-endpoint ... />
  <component class="Foo" />
  <vm:outbound-endpoint path="myFooBar" exchange-pattern="one-way">
    <payload-type-filter expectedType="FoobarMessage" />
  </vm:outbound-endpoint>
</flow>

<flow name="barWorkflow">
  <vm:inbound-endpoint path="myFooBar" exchange-pattern="one-way" />
  <component class="Bar" />
</flow>

and some more… so the connection between these two workwlows is made by the path=”myFooBar”… in config… additionally the outbound payload-type-filter is a rooter, which defines, that only the class foobarMessage is allowed on this connection and only this class will be sent… other result will be burned (at the koax terminator)… so how do the classes look like?

Foo
public class Foo{
  public FoobarMessage inboundMethod(){
    ...
    return foobarMessage;
  }
}

Bar
public class Bar{
  public void process(FoobarMessage msg){
    ...
  }
}

and how does the message finds it method? Reflection… so just create one method with the message argument and voila… it finds it 🙂 pretty cool…

eclipselink with spring

we decided to use jpa with eclipselink… i actually think this was a good decition, but there are a few problems, when using it with spring… eclipselink needs a LoadTimeWeaver… which can only be loaded by spring, when run with an spring agent… add following argumentline to the VM arguments when run…

-javaagent:${where.ever.it.is}/spring-agent-2.5.6.jar

so unit test need this command… the question, how it will work with maven is completely different… and with mule its an other story…

mule with spring and testing without mule…

mule is able to import spring beans… as expected 🙂 but to test those… its kinda hard… 🙁

first create an own bean config file separated from the mule-config.xml and include it in mule-config.xml with following tags:

<spring:beans>
<spring:import resource=”beans.xml”/>
</spring:beans>

simple 🙂 now the beans.xml is a simple springbeans config file… with <beans> as root tag and <bean>’s inside. easy too…

and now use following annotation in the unittest:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={“classpath:beans.xml”})

this should now load the bean correctly during test…

mule imap:connector

ok tryed some things with the mule imap:connector and its kinda cool… and its kinda crap… a few functions are really cool, but dont work as expected…

imap:connector

  • checkFrequency: milliseconds to try getting new mails on the imap-server
  • deleteReadMessage: deletes the message, after read
  • backupEnabled / bachupFolder: backups the read mail to the folder… the folder is localy, not on the imap-server (partly crap)
  • moveToFolder: moves the mail to the given folder after processing. if deleteReadMessage is true, the moved message is flagged deleted too (crap), if deleteReadMessage is false, the move is a copy (crap)

imap:inbound-endpoint

  • user (is containing a @, use %40 instead)
  • password
  • host
  • port

all in all it is a really powerful connector, which reads the mailbox frequently and can be used as perfect flow starter…  additionally it returns an MimeMessage, with all the Headers and so on… but on the other hand, it cant handle the mails on the imap server… it looks like the handling on the server needs to be implemented with a POJO… if this is the way to go is a complete new question…

imap

in my project at work we need to read a mail box… sounds not so easy, but actually is… mule imap:connector for the win 🙂

but testing this is a pain… first of all i needed a mail account with imap access… my company is really big an the processes to get such an email adress is huge… and yeah… we are an isp 😛 so just try to get a simple free email adress with imap… kinda hard… fastmail.fm is the solution…

could connect, but couldnt read or find directories… so had to connect with telnet, to find out everything…

in commandline:

  • telnet [host [port]] to connect
  • 1 LOGIN username password to log in (the 1 is important… imap needs numbers)
  • 1 LIST “*” “*” to list all mail boxes… no clue what the “*” are, but it has listed 🙂

this helped…

mule elements and flows

mule is a simple message router, which is configured in an .xml (mostly mule-config.xml)… following main elements can be found in it:

  • connectors: defining the class, which will be used for the connection (can be used by endpoint with connector_ref)
  • transformers: definig the class, which transforms the message to usable stuff (can be used by endpoints this transformer_ref)
  • inbound-endpoint: inbound-event for a flow
  • outbound-endpoint: outbound event for a flow, or message forwardpoint
  • component: class in a flow which will be called after inbound, before outbound

there are 2 types of flows… flows with an outgoing-endpoint and flows without… in a flow it is possible to define multiple entrypoints and it should be possible to define multiple endpoints… i think, only 1 component can be defined… a PoC will show…

so a normal flow will be as followed:

  • defined inbound-endpoint with a connector (to connect and wait for the incomming message) and a transformer(to handle the message and transform it into a format which the component expects)
  • defined component which will do something with the message
  • defined outgoing-endpoint to sent the message to other systems

additionally there is a model and services in the config file… couldn’t figure out, what the heck they are for…

mule esb

my project at work will use mule as central framework and so i need to come up to speed with this technology as well…

mainly it should be an esb… but actually is my understanding of a bus completely different… mule is a centralized server, where messages are forwarded… ok its a little bit bigger… incoming messages are handled in a flow… transformed if needed and sent out, as outgoing messages to other applications, components…

but where is the bus? my bus understanding is a (lets say) cable, where all applications/components can attach themselfs and lock into the dataflow in the cable, and take the message, if it concerns them… like Observer-Pattern… but in mule, the message flow is defined on the server, with inbound- and outbound-endpoints… so where is the bus?

esb – enterprise service bus

new job, new technology and of course new concepts… esb…

i knew this architectional concept might be part of my new job… so i tried to read/learn it in advance… but as you might know, i failed… so now i am on the job and really need to understand it… an with these blog entries(1, 2), of a Mule ESB founder its really simple and clear 🙂