Monthly Archives: August 2011

mockito

mockito is a pretty cool mocking framework. It is simple and logic… actually i am using it with interfaces, which makes it really logic and simple, dont know, who it works against normal classes… will test that soon 🙂

but first, how does it work with a simple calculator class:

HelloWorld helloWorld = Mockito.mock(HelloWorld.class);
Mockito.when(helloWorld.hello(Mockito.anyString())).thenReturn(“Hello”);

  • So first line initializes the mock.
  • Second line defines the return value of the function hello(String) when called with any string. So it allways returns Hello.

timestamp with jpa

so i have my jpa project with some really nice DAOs and i was really happy… all unit tests are up and running and everything looked good… but it wasnt…

i store timestamp(6) in the oracle db and the mapping class looks good and correct:

@Column(name = “TIME_ADDED”)
@Temporal(TemporalType.DATE)
private Date timeAdded;

the @Temporal defines the mapping type… and actual DATE is really only the date… TIMESTAMP is the thing i wanted…

The @Temporal annotation denotes, whether annotated property should be mapped to java.sql.Date (holds only date part), java.sql.Time (holds only time part) or to java.sql.Timestamp (holds date and time also with fractions of second). It has nothing to do with generation of property value.
(http://stackoverflow.com/questions/2591570/hibernate-reverse-engineering-procedure-generated-temporaltemporaltype-timestam)

and btw. unit tests will not find these errors… due to jpa caching… 🙁

foreach in java

for(String item : list){
       // do things with the item
}

accessing imap

accessing imap mailboxes is super easy with javax.mail… 

final Properties props = new Properties();
props.setProperty(“mail.store.protocol”, IMAP_PROTOCOL);
final Session session = Session.getInstance(props);

final Store store = session.getStore(IMAP_PROTOCOL);
store.connect(server, user, password);

final IMAPFolder imapFolder = (IMAPFolder) store.getFolder(“Inbox”);
imapFolder.open(Folder.READ_ONLY);

final FlagTerm ft = this.getFlagTerm(new Flags(Flags.Flag.SEEN), false);
final Message[] messages = imapFolder.search(ft);

for (int i = 0; i < messages.length; i++) {
  final long imapUid = imapFolder.getUID(messages[i]);
  final MimeMessage message = new MimeMessage((MimeMessage) messages[i]);
}

easy… main problem is, that the MimeMessage is directly linked to the imap Folder… so if you return the MimeMessages and close the imapFolder… accessing the MimeMessage dont work… 🙁

Solution? CopyConstructor

MimeMessage copyedMessage = new MimeMessage(message);

nuff said!

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… 🙁

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…

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…

splunk

splunk… a tool, which gathers all the log entires of files, index them and present them in a really cool frontend…

really cool when using multiple servers, different application and actually the need, to read the logfiles… http://www.splunk.com/

weaving: spring and eclipselink

What is weaving?

Weaving: linking aspects with other application types or objects to create an advised object. This can be done at compile time (using the AspectJ compiler, for example), load time, or at runtime. Spring AOP, like other pure Java AOP frameworks, performs weaving at runtime. (http://static.springsource.org/spring/docs/2.5.x/reference/aop.html)

So weaving is used to load objects and manipulate them… so… why? and why did this concern me?

ok in my project we use spring with eclipselink and the idea was to create the entities in spring and just @Autowire them for usage…  but it needed a InstumentalLoadTimeWeaver to do so… and this Weaver needs to run in a special java-agent (spring-agent)… which is really crap on a server… so it really concerned me!

Solution? EclipseLink allows the configuration weaving=false (link)… which just simply disables the dynamic weaving, so no weaver is used and no java-agent is used… hurray…

but… what are the side-effects?

… to weave all applicable class files at build time so that you can deliver pre-woven class files. Consider this option to weave all applicable class files at build time so that you can deliver prewoven class files. By doing so, you can improve application performance by eliminating the runtime weaving step required by dynamic weaving… (http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_(ELUG)#Using_EclipseLink_JPA_Weaving)

so its this a solution? i think so 🙂