Daily Archives: August 5, 2011

make or buy

Posted on August 5, 2011 | Comments Off on make or buy

in software developmenr the make or buy decision is a hard one… making stuff is sometimes really expensive… the implementation might be hard and needs a lot of time… buying stuff has its big downside… you cant change it… or changes are expensive… taking and changing open-source stuff is in my opinion not really a buy solution… it is actually easier to change stuff, but if a new release is created you are fucked by rechanging the stuff again and normaly you dont have time for it…

and actually i am a big fan of make… why? simple… i am a software developer… so making things is my daily work and buying means, i am unused…

but currently something changed… an other team in my company created a really cool framework and it contains a part i was really looking forward to make… so should i make or buy? normally: make… in this case: buy… so whats different… first its kinda open-source for me and every change i would make will be available in further versions… and on the other hand i know the creaters and requirements for my project might be implemented…

Comments Off on make or buy

Posted in philosophy

mule collection-splitter

Posted on August 5, 2011 | Comments Off on 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…

Comments Off on mule collection-splitter

Posted in developing

Tagged , ,

mule flow

Posted on August 5, 2011 | Comments Off on 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…

Comments Off on mule flow

Posted in Uncategorized

Tagged , , ,