Replaying Events in An Axon Framework Based Application

This post, shows how to replay events from the event store, in an event sourced application built with Axon Framework.

Note: This post applies only to 2.x versions of the Axon Framework, as the implementation of the event processing aspects of the Axon changes significantly with the version 3 release.

If you are not familiar with CQRS and/or the Axon Framework, then consider starting off by reading Exploring CQRS Architecture with Axon Framework, which is a series of post that explores the CQRS architecture/pattern and how the Axon Framework can be used to build applications according to the stipulations of CQRS.

If you’ve read these series of posts, or you are already familiar with CQRS/Axon Framework, then feel free to continue with the rest of this post.

Exploring CQRS with Axon Framework: Closing thoughts

...and this post, is the final one, in the series of posts on Exploring CQRS with Axon Framework. It is a summary of my thoughts on CQRS as a pattern and the Axon framework as a tool used in achieving this pattern. If per chance you have not read the other posts in the series, I will recommend starting from the very first post: Exploring CQRS Architecture with Axon Framework: Introduction

That said, I proceed into the details of this post.

Exploring CQRS with Axon Framework: Overview of the Testing infrastructure

After a long break, I am finally getting around to picking up on the series: exploring CQRS with Axon Framwork. This post, which is on testing, is one of the two remaining posts left to wrap up the series. The aim is to follow it up, as quickly as possible, with the concluding post.

If you have not been following the series, I would advice to give the other posts a read before continuing with this post. You can start here: Exploring CQRS Architecture with Axon Framework: Introduction

As already mentioned, this post looks at the infrastructure the Axon Framework provides for testing. Just like the other posts in the series, it is accompanied by the exploringCQRSwithAxon project on Github. The Application is a trivial one, meant to further illustrates the content of the posts.

Exploring CQRS with Axon Framework: Applying Event Sourcing

This post is part of the series of post on exploring CQRS architecture using Axon Framework. It looks into combining event sourcing within CQRS using Axon Framework.

The previous posts in this series has explored the various components of a CQRS application and in Introducing Domain Events and Event Handling, we are able to put everything together. We did all that without bringing in event sourcing, showing that it is possible to have a CQRS architecture easily without introducing event sourcing. But in this post, we do just that: introduce event sourcing.

There is a project on Github (exploringCQRSwithAxon) that accompanies these series of posts. It is a trivial application where we can perform debiting, crediting and transferring of money between two dummy accounts. The code in the project is meant to help illustrate the application of the Axon framework to building CQRS application.

Exploring CQRS with Axon Framework: Introducing Domain Events and Event Handling

This is a post in a series of posts that explores the CQRS architecture with Axon Framework. It is recommended to read the previous posts in this series before going ahead with this one, as that would help in forming a thread of continuity around the topic being discussed. You can start from Exploring CQRS Architecture with Axon Framework: Introduction

There is a Github project (exploringCQRSwithAxon) that contains a simple application that accompanies the posts in this series. it is an illustrative application that allows debiting, crediting and transferring money between two fictitious accounts. It is obvious a trivial application, which is on purpose. It’s aim is not to capture any complex domain but to help illustrates the various components of a CQRS architecture and how the Axon Framework can be used to build these various components.

Krwkrw 0.1.3 Released

Just pushed the latest release (0.1.3) of Krwkrw to Maven central.

Krwkrw is a web scraper. You can read how it came into being here

A quick run down of the changes in 0.1.3.

1. Ability to express URL's to be included/excluded using Regex pattern. For example:
   

   Krwkrw crawler = new Krwkrw(action);
   crawler.match("(\\S+)(/projects/)(\\S+)")
   

   makes sure that only contents in the /projects/ path would be processed while
   

   Krwkrw crawler = new Krwkrw(action);
   crawler.skip("(\\S+)(/projects/)(\\S+)")
   

   will fetch and process all the contents except, the ones in the /projects/ path
   
2. Ability to have random delays in between requests.
   Before now it was only possible to set the seconds to wait between requests. For example:
   

   Krwkrw crawler = new Krwkrw(action);
   crawler.setDelay(5) // waits 5 seconds between requests
   

   With the 0.1.3 release, it is possible to have random delay; that is, the requests will be delayed by number of seconds picked randomly from a lower and upper bound, for example:
   

   Krwkrw crawler = new Krwkrw(action);
   // waiting seconds will be any number between 5 and 20
   crawler.setDelay(5, 20) 
   

3. Change in API. doKrawl method replaced with crawl
   
4. Fix issue where it was possible for the crawler to crawl pages outside the origin url
   
5. Some minor improvements here and there...
   

If using Maven as your build tool, you can add it to your project via:

<dependency>
<groupid>com.blogspot.geekabyte.krwkrw</groupid>
<artifactid>krwler</artifactid>
<version>0.1.3</version>
</dependency>

If using Gradle, then:

dependencies {
compile "com.blogspot.geekabyte.krwkrw:krwler:0.1.3}"
}

The Javadoc can be accessible online here.

You can also check out Krwkrw on Github

How Well Do You Know Your Collection API?

I recently spent some time going over the Java collection API and even though, it can be said it is one of the most used API in everyday programming with Java, I still had some "Oh I totally forgot about that" moments to "I did not even know that was so" realizations.

I will note down some of the interesting observations in this post, being as succinct as possible and backing with code examples when needed. It is intended to be a place I can always consult to get an overview of the API.

Embedding ElasticSearch In a Spring Application

This blog post will show how to have ElasticSearch embedded in a Spring Application.

Motivation

Why Embed ElasticSearch in an application? Simple. To reduce the infrastructure overhead an application needs in other to run, making it more portable.

It is also for the same reason you will want to embed, say a web server, within your application.

It is especially appropriate to have ElasticSearch embedded when the use case does not require the distributed features of ElasticSearch and all that is needed is just a single node.

Krwkrw 0.1.2 Released.

Just pushed the latest release (0.1.2) of Krwkrw to Maven central.

Krwkrw is a web crawler/scrapper...scrapper is more apt actually.

If using Maven as your build tool, you can add it to your project via:

<dependency>
<groupid>com.blogspot.geekabyte.krwkrw</groupid>
<artifactid>krwler</artifactid>
<version>0.1.2</version>
</dependency>

If using Gradle, then:

dependencies {
    compile "com.blogspot.geekabyte.krwkrw:krwler:0.1.2}"
}

A quick run down of stuffs worth mentioning that comes with this release:

• Addition of 3 utility classes that makes it easy to store the crawled webpages to a relational database, ElasticSearch or saved into a CSV file.
• It is now possible to register a callback that would be fired when the crawling operation terminates. Should be most useful when the crawling operation is done with the Async mode. 
• A bug where broken links are crawled multiple times.
• General improvements to API, tests, etc...

You can see the Readme for more information. And yeah, the 'a' was dropped from the name, from Krawkraw to Krwkrw, because, all consonants name sounds cooler.

For a background story on how Krwkrw came to be, please read A web scraper/crawler in Java: Krawkraw

Using Optional Effectively in Java 8

Optional<T> was added in Java 8, and according to its documentation it is defined as "a container object which may or may not contain a non-null value..."

I have recently been spending some time getting familiar with the Stream API, also introduced in Java 8, and a lot of the terminating methods of the Stream API returns an Optional<T>...

At first encounter with Optional<T>, my first thought was asking what real advantage does this offer? How is it different from checking if an object is null before calling its methods?

The Optional<T> has the isPresent() and get() methods which can be used to check if the enclosing object is null or not, and then retrieve it. Like so:

Optional<SomeType> someValue = someMethod();
if (someValue.isPresent()) { // check
    someValue.get().someOtherMethod(); // retrieve and call
}

But exactly the same thing can be done with plain null checks with the code looking almost the same:

SomeType someValue = someMethod();
if (someValue != null) {
    someValue.someOtherMethod();
}

What then is Optional<T> good for?

Using Krawkraw To Find Broken Links

I recently tweeted that I did just that: used Krawkraw to fish out broken links on the company's website.

I recently used Krawkraw to fish out dead links on company's website --> http://t.co/VIAJC19UdD
— dade! (@dadepo) December 29, 2014

From all the 187 pages, I was able to find the 8 broken links: the rogues!

A web scraper/crawler in Java: Krawkraw

UPDATE: Krawkraw is now referred to as just Webmuncher.

Nobody sets out to write a web scraper, but here I am posting about just that, a general purpose web scraper I wrote…

How did this happen? Well, it started with wanting to play around with ElasticSearch a couple of months back. And in search of some data to index, I looked to websites' contents (with hindsight a more structured data format should have been sought, but well, the lesson has been learnt)...

So the question then was, how do I easily retrieve all the html pages of a site and have it thrown into ElasticSearch. Any easy web scraper in Java, out there that I could just use? I can’t even remember actively searching for such a tool...which explains why I somehow decided it would be much fulfilling if I throw a web scraper together...and in a couple of weekends, Krawkraw came to be.

Krawkraw is a tool that can be used to easily retrieve all the contents of a website. More accurately contents under a single domain. This is its perfect use case which reflects the original need for which it was written. So you can’t start at one edge of the web with Krawkraw and expect to crawl to another edge...Nope.

Krawkraw is available via Maven central, and you can easily drop it into your project with this coordinates:

com.blogspot.geekabyte.krawkraw
krawler
${krawkraw.version}

Or you can download the jar files here, and have it included in your classpath.

For more information on the API and its usage, The README should be your friend! If you happen to use Krawkraw and found it missing some features, or you have some ideas on some features that it should have? Then drop them in the issue tracker.

How to Inject Objects Into Spring MVC Controller Using HandlerMethodArgumentResolver

This post shows how to implement HandlerMethodArgumentResolver in other to resolve and inject objects into Spring MVC controllers, but before we get to the actual implementation procedure, a little trivial overview of Spring MVC would be good.

Spring MVC is designed around the Front Controller Pattern which it uses to implement the Model View Controller pattern.

Since you are reading this post, I can rightly assume you already use Spring MVC and you know how it generally works: You register the DispatcherServlet -Spring MVC's Front Controller, write your controller class and map requests to controller methods using @RequestMapping, then put the necessary configuration in place which would enable Spring to pick the written controller class and have it as a spring managed bean.

A trivial controller class may look like this:

package com.springapp.mvc;

import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.RequestMapping;


@Controller
public class HelloController {


    @RequestMapping("/index")
    public String doGreeting(Model model) {
        model.addAttribute("greet", "Hello World");
        return "helloView";
    }
}

So when a request hits /index, doGreeting(...) method is invoked with an object of Model (the M in MVC) passed into it, which is populated with the greet property which can then be accessed in whatever view technology in used. The view is located using the "helloView" string returned by the controller.

Common Date-Time Operations In Java - Formatting and Parsing Date-Time

In Date and Time With Java, a general overview of date/time related API was given. This post walks through formatting and Parsing Date-Time in Java.

Parsing and Formatting Date and Time.

What is the difference between December, 04, 1984 and 12/04/1984, and 04/Dec/1984 and ... or difference between 13:00hr and 1PM and...

Formating. They all represent the same date and time but are formatted differently.

Formatting date/time values as string, and parsing date/time values expressed in string into objects, are one of the common tasks when dealing with date/time. 

Formatting allows you to take a Java object that represents date or time and convert it into a string represention using a predefined formatting.

Conversely, with parsing, you take date or time values expressed as strings and have it converted it into valid Java date or time objects.

We quickly go over how to accomplish these tasks:

Configuring Spring Data JPA

tl;dr Spring Data JPA enables a Repository style of accessing data where the data source is a JPA powered data source. Configuration is simple. Have a working Spring JPA configuration, then add the Spring-Data-JPA as dependency to your project and enable the functionality by wiring the appropriate bean in your Spring Context.

Configuring Spring Data JPA is part of the Configuring Spring Series.

This short post would show how to easily configure Spring Data JPA for use and some related concepts that should help explain the rational behind Spring Data.

Spring Data JPA itself is part of a larger umbrella project: Spring Data. Which seeks to provides an easier, less broiler plate way to accessing data. A lot of the projects under the Spring Data use the Repository pattern, while some don't. Spring Data JPA is one of the projects that implements the Repository Pattern.

Since the Repository Pattern is central to Spring Data JPA, it is recommended to, at least, have an overview of what is going on when it is being used. After this, we go ahead to look at the configuration procedure, which is very succinct.

Repositories can be viewed as abstraction over data. This explanation, although partly correct, does not do justice to the unique identity of the Repository pattern. The question might be, if it is an abstraction over data, how is it then different from DAO's?

There are quite a lot of varied opinion regarding the difference between Repositories and Data Access Objects; but I like this answer to the question on Stackoverflow a lot.

Most specifically the part where it says:

DAO is an abstraction of data persistence. Repository is an abstraction of a collection of objects.

DAO would be considered closer to the database...Repository would be considered closer to the Domain, dealing only in Aggregate Roots. A Repository could be implemented using DAO's, but you wouldn't do the opposite...

This explanation also touches on some key concepts out of Domain Driven Design: Domain and Aggregate Roots. Understanding these also would help groking the essence of Repository pattern itself. Here is a nice blog post that talks about Aggregates and Aggregate Roots in Domain Driven Design. It is a post in a series. The other posts should shed more light on other parts of DDD.

For the more adventurous regarding the subject of DDD; the bible itself is a recommended read. If its 506 pages look intimidating, then maybe a less voluminous guide would be more appropriate: InfoQ Free eBook : Domain Driven Design Quickly. It is just 104 pages.

In short, as can be seen from the explanation of the difference between DAO Pattern and Repository Pattern; the Repository is a collection.

The developer using the Repository is not concerned about the source of the objects. The source could be a Database, a Network, File system, or a Web service. It does not matter. DAO on the other hand, more often than not, deals essentially with the Database.

It is worth nothing here that DAO actually stands for Data Access Object and not Database Access Object. It seems the pattern evolved to mean Database Access Object. :|

So with Spring Data JPA, you work with Repositories which returns to you, objects or collection of objects that are sourced from a JPA based data store.

So with this fact established. The actual configuration is trivial.

Since it is Data JPA, configuring it requires that you have a working JPA configuration in place. You can read Configuring Hibernate JPA in Spring Framework if your JPA provider would be Hibernate. The configuration procedure applies if other JPA provider is being used.

To add Spring Data JPA, you need to do two things. Add it as a dependency in your project (pom.xml in this example as Maven is used) and enable it by wiring the necessary bean in your Spring context.

In pom.xml add:

            org.springframework.data
            spring-data-jpa
            1.4.3.RELEASE

and in your Spring Context add:

jpa:repositories is a Spring xml namespace that serves as a short cut for explicit bean definition needed to get Spring Data JPA running. You can read the section on Hiding Bean Definition via Namespaces for more about this.

The base-package tells Spring JPA Data where to find interfaces it should use in implementing Repository objects for your application. Yes, Spring JPA Data looks for interfaces you specify and provides the actual needed implementation for use at start up. Cool right? This is another way Spring Data JPA makes data access easier with less code. For a more detailed explanation on this, read Working With Spring Data Repositories.

More materials on Spring Data JPA in general can be found on the project page on Spring.io

Configuring Hibernate in Spring Framework.

tl;dr to configure Hibernate in Spring, you need to configure a bean that implements org.hibernate.SessionFactory. Configuring this bean involves specifying the data source, the Object-to-Database mapping (if you using xml for the mapping) and the hibernate properties.

Last post in the Configuring Spring series looked into how to configure data sources, a basic requirement, regardless of the actual method in which your application would communicate with the database server: either via plain JDBC or via an ORM tool.

This post would look into how to configure Spring to use Hibernate. Hibernate is an object-relational mapping library for the Java language, that provides a framework for mapping an object-oriented domain model to a traditional relational database.

In how to configure data sources in Spring, we saw how the data source is the entry point to having your application communicate with a database server; how it is configured and retrieved for use in your application by classes that are specifically created to handle interaction with the database (DAO classes)

In configuring hibernate to work with Spring Framework, the data source still remains the primary entry point, but it would not be what your application code (or DAO class if you go with this pattern) would have to use directly in other to communicate with the database. With Hibernate, your application code requires something called the SessionFactory

So the process of configuring Spring to work with Hibernate is basically then all about configuration the bean that would make the SessionFactory available for you.

Configuring Data Sources in Spring Framework

This is the second post in the configuring Spring series. It kickstarts the database centric configurations required when building an application that persist data with Spring framework. This post talks about configuring data sources.

There are various ways to enable the ability to persist data in your application. From using any of the available Implementation of Java Database Connectivity (commonly referred to as JDBC) to going the ORM route via any of the popular ORM frameworks (Hibernate, MyBatis, Eclipse Link etc )

But with any of the above mentioned method, a data source is always a requirement; because...well you need to have a source to the data if you want to persist and/or retrieve data. And in Spring the data source ends up as a Bean that you would configure.

Spring provides several options of configuring the data source. You can have:

1. Data sources that are provided via JNDI.
2. Data sources that work with JDBC drive.
3. Data sources that are from a connection pool.

But before we go ahead to look at configuration proper, it would be useful to quickly define some basic concepts you would encounter when dealing with persistency:

Configuring Beans in Spring Framework.

This is the first post in the Configuring Spring Series.

Beans in Spring framework are proxies implementation of your classes. And following the Inversion of Control way of doing things, they are managed by the Spring framework container and made available for you to use.

Meaning you basically write your classes like you would normally do when programming in Java. After which, you then need to go through a process of configuration that would guide Spring regarding how your classes would be transformed into managed beans which you can then use to form your business logic.

There are different ways to have this configuration set up. And this post, first in the series of many, that would cover some of the configuration tasks in Spring, covers how to configure Spring to take your classes and have it turned into beans. This process is normally referred to as Bean wiring.

We would look at

1. Configuration via XML
2. Configuration via Java Classes: JavaConfig
3. Configuration via @Component and @Autowired Annotation

Understanding Entity Relationship Mapping, Part 2: Annotating Entity Relationships

In Understanding Entity Relationship Mapping, Part 1: The basic concepts I glazed over some of the basic concepts that would be encountered when dealing with establishing relationships between Entities. This post would take a look at how to use Annotations to specify these relationships.

The relationships that would be annotated are the four types that you have in relational data model:

1. One-To-One annotated with @OneToOne
2. Many-To-One annotated with @ManyToOne
3. One-To-Many annotated with @OneToMany
4. Many-To-Many annotated with @ManyToMany

If concepts like Cardinality, Direction of Relationship, Cascades, Owning side and Inverse side of Entity relationship is new to you, then it is would be good to first read Understanding Entity Relationship Mapping, Part 1: The basic concepts

The relationship would be classified into two: Single Valued Mappings and Collection Valued Mappings. It is worth stating that the examples were written with Hibernate's implementation of JPA in mind, but would work with any other standard implementation of JPA 2, as no Hibernate specific annotation is included.

So let us begin.

Javascript is not Java. Deal with it

There are different paradigms when it comes to programming languages. With each paradigm, you have different and unique methods and concepts that are used in the task of computation and getting the computer to do what you want. Sometimes these concepts share similarities; sometimes they go about their task in totally different ways. The merit of a paradigm is thus judged against the backdrop of the problem it is being used to solve and whether it is the best fit.

It would then be totally silly and dense to put a language down solely on the fact that it incorporates a different paradigm when compared to a language you are familiar with. Most of the bashing I see targeted at Javascript is largely due to this: coming from a different programming paradigm and getting miffed when different ways of doing things are encountered in the Javascript land.

At the risk of being wrong and committing fallacy of hasty generalization, I would say Java developers are most guilty of this (maybe it has to do with the misleading "Java" in Javascript? :p)

I say this, because from personal experience, (which I know is limited) I do not get the same close mindedness from the Python, Ruby and C# devs that I know.(This explains the title of the post I guess :p)

Maybe it is that difficult to come to terms that Javascript is a prototype based object oriented language and not a class based language?

Consequences of this close mindedness towards Javascript, thus lead to hacks and practices that try to bend and mould Javascript into something which it is not. I most of the time find this to be quite uneducated.

Coming from a Javascript-first background, before Java, I guess made it quite hard for me to have this kind of narrow mindedness and priggish attitude? I guess this helps to easily appreciate the unique ways of doing things in both languages. I like to think that this makes a better developer, as it is quite interesting to see how different ideas are implemented across languages and borrow from them in situation, when it is germane.

So when (if) I want to learn Haskell, I won’t go about complaining over how it has so many concepts; tricky and odd concepts and how it does things different when compared to say Javascript. And I wont try to write Javascript in Haskell.

And by the way, Javascript is not the only language that has its good parts. Every language does, Java, C++ inclusive :)