Soul Power

DDD Specifications with Hades

2010-07-15T23:03:46Z

Two weeks ago, I attended Java Forum Stuttgart, a really nice one-day conference to hear interesting talks, meet fellow developers and colleagues. The first talk I attended was held by Adrian Hummel and Mischa Kölliker entitled Rich domain model with JPA 2.0. As I am currently working on the final features for Hades 2.0 which will be based on JPA 2.0, I was eager to see what they were about to present.

One part of their talk was dealing with the specifications concept of the Domain Driven Design book by Eric Evans. Specifications are an abstraction over a statement or requirement you can formulate for an entity. Each of the specifications you can define evaluates to a boolean, so it can be regarded as predicate over the entity. The example Adrian gave in his talk (and also in a blogpost he dropped a few days later) is a soccer player, who can be characterized as “fair player” or as “bonus eligible”.

JPA 2.0 introduces a criteria API, that effectively allows to define queries via a more or less typesafe API. So the typical code you write using this API looks as follows (code originally coined by Adrian):

CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Player> q = cb.createQuery(Player.class);
Root<Player> player = q.from(Player.class);

q.where(/** Build your where clause here **/);

return em.createQuery(q).getResultList();

As you see there’s a few lines of boilerplate code that works with the domain class. The part that actually varies from query to query is the where clause you hand to the q.where(…) method. What Adrian and Mischa now proposed is introducing a Specification<T> interface that simply provides a callback method that gets the CriteriaBuilder, CriteriaQuery<T> and Root<T> and reduces that to a JPA Predicate which can be handed to the q.where(…) method then (code originally coined by Adrian):

public interface Specification<T> {

 Predicate toPredicate(CriteriaBuilder cb,
   CriteryQuery<T> q, Root<T> root);
}

Specifications in Hades

To make this available in Hades we simpy add a method readAll(Specification<T> spec) to GenericDao interface and GenericJpaDao implementation and implement it as follows:

public List<T> readAll(Specification<T> spec) {
  CriteriaBuilder cb = em.getCriteriaBuilder();
  CriteriaQuery<T> q = cb.createQuery(getDomainClass());
  Root<T> player = q.from(getDomainClass());

  q.where(spec.toPredicate(cb, q, root);

  return em.createQuery(q).getResultList();
}

So what this gains you is a possibility to simply add new Specification implementations and thus “extend” the DAO without the need to add finders e.g.

One more thing

The really cool part about the Specifications is, that – as you can concatenate JPA Predicates with and and or – you can do this with some minor effort on the Specifications, too. I added a small class that provides some syntactical sugar to make something like this possible:

playerDao.readBySpecification(
  where(isFair()).and(isEligibleForBonus()));

This probably needs some explaination. First, isFair() and isEligibleForBonus() are static methods on a (for example) PlayerSpecifications class that return a Specification instance creating the JPA Predicate instance. The where(…) method is also a static one on a helper class that pretty much returns itself, implements Specification in turn and and provides the concatenation methods to chain Specifications and build new Specifications on the fly. Thus you can easily implement atomic predicates for the entity and build more complex expression from it – a really cool complement to the finder methods already available in Hades. The feature will be available in upcoming RC3 of Hades 2.0 and can already be used with the current snapshots.

A big thank you to Adrian and Mischa for a huge part of this new feature =).

Hades – standing on the shoulders of giants

2010-07-01T18:56:02Z

In the last few days I have been working on a feature request of Hades that has been after me for quite a long time. Hades has always had built in support for auditing entities, which means it captured the current user of the application and set it as the creator or modifier on the entity whenever you called save on a Hades DAO. This is based on AOP, has always been a nice showcase of AOP applied, hopefully served a few users quite well. So far so good. Unfortunately the way it was implemented had two serious drawbacks:

It only works if you call MyDao.save(…) explicitly
It only works for the root entity you persist, not transitive ones.

These drawbacks have caused Will Jaynes to open up a ticket over a year ago already and I have been thinking about that issue from time to time, sometimes more deeply, sometimes just remembered it was still open. Finally I came up with a solution that not only fixes the two points mentioned above but also acts as a quite nice example of how powerful Spring as a toolbox can be, especially for framework or library developers. Here’s the story…

The right tool for the job

Actually, implementing auditing with AOP was not the right choice in the first place. Well, it’s not that AOP in general is the wrong hammer for this nail but rather how we applied it. Auditing based on a pointcut targeting a repository method is plain wrong if we deal with OR mappers, period. So I do not consider myself extraordinarily stupid so you and I might wonder what took me down that road.

Entity listeners

The core abstraction for reacting on lifecycle events for entities in JPA are so called entity listeners. You can either annotate the entity itself with annotations like @PrePersist or @PreUpdate or use a dedicated class with annotated methods in case you want to implement common hooks you might want to apply to a common set of classes. You activate those entity listeners by either annotating the entity with @EntityListeners or configure them in your orm.xml. The reason they never seemed suitable for me is that they get instantiated by the JPA provider and thus – by default – lack any means of injecting dependencies into them (the AuditorAware instance knowing who is the current user in our case).

@Configurable

Fortunately Spring offers injecting dependencies into classes created with new by adding an @Configurable to the class to be instantiated. You simply have to get a Spring aspect woven into that class then and activate in your apps XML config and Spring will intercept the instantiation of that class and either autowire dependencies or use a blueprint prototype bean to determine what has to be wired how. (For details see a former blogpost or the reference documentation.)

So let’s recap what we have here: I let the aspect be compiled into my AuditingEntityListener and activate as well as a prototype bean of the listener getting a StubAuditorAware injected in my integration tests config file. Hm, doesn’t work… What’s wrong? Here’s the critical part of the reference doc.

Instances of @Configurable objects created before the aspect has been configured will result in a warning being issued to the log and no configuration of the object taking place. An example might be a bean in the Spring configuration that creates domain objects when it is initialized by Spring. In this case you can use the depends-on bean attribute to manually specify that the bean depends on the configuration aspect.

Okay, it seems the aspect is not yet active when my LocalContainerEntityManagerFactoryBean gets instantiated which in turn instantiates my entity listener. The docs recommend (no pun intended) to emphasize the order of the beans by adding a depends-on attribute to the bean that manually instantiates objects (the EntityManagerFactoryBean in our case). First: what bean to depend on since spring-configured has no id. Ah, it turns out Spring registers the aspect under org.springframework.context.config.internalBeanConfigurerAspect. So I’d essentially need something like this to make sure the EntityManagerFactory already sees the DI aspect:

Well, wait… of course I could document that this was necessary but that would bloat Hades user’s infrastructure configuration, expose Spring internal bean names and make things unnecessary complex.

Spring container hooks – BeanFactoryPostProcessor

Okay, so what we essentially need to do is transparently add a depends-on="org.springframework.context.config.internalBeanConfigurerAspect" to the chosen EntityManagerFactoryBean bean definition. Fortunately we can do this programatically by using one of the Spring container hooks, the BeanFactoryPostProcessor. So I simply implemented a AuditingBeanFactoryPostProcessor that transparently adds the (additional) depends-on to bean definitions that create an EntityManagerFactory. So the benefit here is that we can leave other user defined beans untouched. Let’s take a look on what we have to configure on the Spring side to get things up and running:

As you can see, there’s a lot of boilerplate XML config here. The only thing really custom is the delaration of the MyAuditorAwareImpl. Now guess what? There’s some Spring for that…

Spring namespaces

As you probably already know (as you might have used Hades already) Spring supports the implementation of custom XML namespaces since 2.5. We already implemented the dao-config element in the Hades namespace so why not add one to activate auditing? So here’s what we end up with:

Quite neat, isn’t it? So let’s summarize what we have gained from the plain auditing feature view:

We get transparent auditing on all JPA managed entities, whether they are the root entity or a transitive one.
No need to call MyDao.save(…) to trigger auditing.

Nice, feature completed ;). Now let’s take another step back an reflect what brought us there:

Spring’s ability to inject dependencies into objects instantiated with new through @Configurable and AOP.
Prevented custom configuration spread around into other beans thorugh Spring’s BeanFactoryPostProcessor container hook.
Reduced the amount of configuration required through a custom namespace to hand an expressive concise configuration language (in our case in form of a single XML element ;) to the user instead of a generic verbose one.

Enough praising here, enjoy auditing with Hades! =)

P.S.: In case you want to take a glance at the sources checkout the commits I’ve done for the feature request.

Hades 2.0.0.RC2 introduces transactional DAOs

2010-06-22T19:11:24Z

Our latest Hades release of the 2.0 branch is introducing transactionality of DAO instances as main new feature. Of course you can read up the reference documentation for some general guidelines but I want to use the chance to give a more detailed look into why we introduce this and how some details work.

These days, some kind of back-to-the-basics approach regarding architecture layering is widely accepted as best practices. Thus you don’t want to introduce a layer just because of some merely technical needs. A typical candidate layer for being obsolete is the service layer. Especially in web applications where you pretty much store entities that are equipped with rich behavior themselves the service layer is quite an artificial one that only demarcates transactions but then delegates to the underlying data access layer. Using Hades in such an application you had needed the additional transaction demarcation somewhere as it didn’t deal with transactions itself out of the box. So the only option to get rid of a service layer was to use e.g. @Transactional at a Spring MVC controller e.g. which is rather a sub-optimal solution.

So actually we were quite reluctant to the idea of applying transactions to Hades DAO instances as there were some crucial points to consider:

Actually a DAO layer might not be at the right level of abstraction. Usually you define transactions on a more business related method than a plain save(…) or findByUsername(…). So if we enable transactions at DAO methods we have to make sure that they seamlessly can be expanded to more coarse grained methods and the DAOs take part in those transactions.
If we apply transactions we don’t want to imply our transaction model to the user’s application. As Spring provides various means to define transactions, we don’t want to take that decision from the developer. So in case she wants to decide for a particular model, she has to be able to do so, no matter what we chose.
Although the transactional behavior that we define for CRUD methods might be okay for 90% of the use cases there has to be a way to override the defaults and replace them by some custom one.
As Spring 3.0 supports multiple transaction managers via @Transactional we have to make sure we participate in the right transaction depending on in which context the DAO is used.
It has to be easy to define transaction configuration for DAO interfaces containing the finder methods.

We decided to use @Transactional annotations at the GenericJpaDao implementation class and activate annotation based transactions for the proxies explicitly through the GenericDaoFactoryBean. This means that the CRUD operations of the DAO instances will be transactional if called standalone or participate in a transaction in case there’s already one running for the current transaction manager (read up details on multiple transaction managers here). So it doesn’t matter if you declare your transactional boundaries via @Transactional, too, or use e.g. XML configuration or even TransactionTemplate. This gets us solutions for issues 1 and 2.

Issue 5 is quite easy to solve as you can simply annotate the finder methods of your DAO interface (or the interface itself) with @Transactional and transactions get applied as you are used to with Spring.

The actual tricky part is issue 3. The main idea here is to simply redeclare the CRUD method originally declared in GenericDao inside your concrete DAO interface and reconfigure transactions as you like. So supposed you want to get rid of the readOnly flag at readByPrimaryKey(…) set to true (as we chose to default the transaction configuration to, as this applies some performance optimizations on the persistence provider as well as the JDBC driver), you can do this as follows:

public interface UserDao extends GenericDao<User, Long> {

  @Override
  @Transactional
  User readByPrimaryKey(Long key);
}

Getting this to work needs some reflection magic as we of course still have to delegate the call to that method to the GenericJpaDao instance but according to the Java Reflection API it of course does only implement GenericDao.readByPrimaryKey(…) and not UserDao.readByPrimaryKey(…). Long story short, we can find out the method that has to be invoked so we can hand this reconfiguration model to the user and gain much flexibility on this side.

Issue 4 is not that interesting as we simply have to configure our internal TransactionInterceptor to lookup the appropriate PlatformTransactionManager instance in a lazy-loading-like fashion but that all happens under the covers and you don’t need to take care of this.

So let me quickly summarize what 2.0.0.RC2 brings you in regard of transactions:

Transactional CRUD methods (everything declared in GenericDao) with appropriate defaults (readOnly flag set to true on read-only methods) that automatically take part in more coarse grained transactions if necessary
The ability to use @Transactional for your concrete DAO interfaces
The ability to reconfigure the transactional behavior of the CRUD methods by simply redeclaring a method inside the concrete DAO interface

Changing a project’s artifact id in Sonar

2010-06-02T15:57:07Z

Sonar is a great tool to take care of code quality in your software projects. I use it heavily to monitor the open source projects I am involved with. When working on getting Hades published into Maven central I had to polish it’s pom.xml and felt the need to align the parent project’s artifact to our chosen OSGi compatible package notation for artifacts. So prior to releasing it to Maven central I changed the artifact id from hades-parent to org.synyx.hades.parent. Everything fine until I pushed the metrics of the 1.5.1 release into Sonar.

Sonar created a new project, as it cannot know about my refactoring. So what to do? I spoke to Simon Brandhof and apparently there’s no feature in Sonar to change the artifact id via the user interface. So I opened a JIRA issue for it, feel free to vote for it if you like. Meanwhile we could achieve this by manually altering the kee column inside the PROJECTS table. It contains entries of the form ${groupId}:${artifactId}(:${branchName}) for entries of type PRJ (i guess that stands for project. Altering these entries solved the problem.

Thanks to Simon and Verschdl for help!

Upgrade you Roo addons to 1.1.0

2010-06-02T15:58:21Z

Spring Roo 1.1.0 will be based on OSGi and Apache Felix in particular as runtime platform. This of course will affect the already existing addons developed for Roo. The core ones are of course updated by the Spring Roo team but in case you have developed a custom one the steps needed to be taken are not really obvious. However, I took some time studying the core addons and here’s a step by step guide that takes you from a 1.0.x addon to a 1.1.0 one:

Make sure, your project version is a valid OSGi vesionDefault Maven version scheme is invalid for SNAPSHOT versions as the 3rd part of the version has to be purely numeric in OSGi. In case you ignore this, you won’t get the bundle deployed into the Roo OSGi runtime. So you have to stick to something like 0.1.0.BUILD-SNAPSHOT
Change packaging of your project to bundleAs your plugin will result in an OSGi bundle you need to change the packaging from simple jar to bundle. This will cause the Maven bundle plugin creating the necessary metadata for you out of the box.
Change the type of the dependencies to bundleSimilar to the point above you need to reference dependencies as bundles. Again, to let the Maven bundle plugin do its job.
Sync build section of your pom with the one provided in the addon templateWe had to do some changes to them pom.xml created for artifacts so you will need to catch up with them. This is mostly related to the Maven bundle plugin as well as the Maven SCR plugin (see next point for details).
```
project --topLevelPackage com.mycompany.myproject.roo.addon \
  --template ROO_ADDON_SIMPLE
```
The easiest way to do so is simply creating a dummy addon project using the template and copy the plugin configuration into your pom.
Replace @ScopeDevelopment annotations with @Component and @ServiceRoo uses Apache Felix as OSGi runtime and thus uses @Component and @Service annotations in combination with the Maven SCR plugin (for details see Maven SCR plugin documentation) to create descriptors for the OSGi declarative services infrastructure.
```
@Service
@Component
public class MyCommands implements CommandMarker {

  @Reference MyOperations operations;

  // Your code goes here
}
```
So every @ScopeDevelopment annotation you used at your command and operations classes has to be replaced by @Service and @Component. If you had injected other services into your command or operations class you can use @Reference to wire that into your component instance. Note, that your class will have to implement at least one interface Felix can publish the component instance under. As there might be further tweaks necessary, have a closer look at the output the Maven SCR plugin generates. It will log errors in case you still need to change something.

The unknown 2nd Spring triangle

2010-05-09T16:45:54Z

When skimming through Spring presentations explaining the building blocks of the framework you’ll often find a so called Spring triangle consisting of the following 3 parts:

Dependency Injection
Aspect Oriented Programming
Portable Service Abstraction

These 3 principles surround a plain POJO programming model and enable Spring to achieve what it is famous for. Portable and maintainable Java software. Having that said, there is another triangle in my opinion that is touches developers even more when working with Spring. This triangle captures the way Spring can be configured, thus used and – to a larger extend – introduced into a project. But first things first, here’s what I am talking about.

XML configuration
Annotation configuration
Programmatic usage

Especially choosing between the first two approaches to configuration are an often discussed topic. To be honest, I don’t think a Spring project will fail because of this issue. There a few guidelines one can use to decide on that topic but I don’t want to go into that in detail in this post. Let’s take a look at the three styles of usage from a more general perspective and how they enable usage of Spring itself.

XML configuration

This way of using Spring is probably a well known way to users that have worked with Spring for a long period of time already. Admittedly, this approach has several downsides (e.g. verbosity of configuration) but also results in some kind of application blueprint you can gain information about how a module is structured at a quick glance.

Annotation configuration

This style of configuration is gaining more and more of traction these days. Spring’s support for annotations is set up broadly since 2.5. 3.0 extends that support furthermore by supporting standardized annotations for dependency injection like @Inject. Besides that Spring comes up with an annotation configuration style called JavaConfig, where you write dedicated configuration classes and annotate them to define configuration metadata. This solves the problem of configuration of 3rd party classes that you cannot annotate directly anymore (e.g. DataSources etc.) that plain annotation config does not offer a solution for.

Both styles of configuration (XML and annotations) leverage the usage of Spring as framework, defining application and infrastructure components that are managed by Spring at runtime. Besides that there is a 3rd option that is often neglected but a helpful one in certain scenarios.

Programmatic usage of Spring

As all Spring abstractions (transactions, persistence etc.) are programmatically usable, which means you can simply drop the appropriate JAR into your classpath and use the classes as is using Spring as library instead of as framework then. As they are written to support dependency injection the usage of the huge simplyfication of JDBC e.g. can be used by instantiating JdbcTemplate, handing it a DataSource and off you go.

Why do I mention that

First thing is, that contrary to popular believe using Spring does not mean huge XML config files or even starting with the introduction of Dependency Injection into your application. You can use declarative transactions by simply using the AOP and transaction API programatically in your already existing factory classes e.g. You can simplify your existing JDBC code hugely by using JdbcTemplate without bothering with AOP or Dependency Injection at all. Thus there are many possible ways to adopt Spring with your application, it is no “one size has to fit all” approach but rather enables you as developer to make a decision that suits your problem at hand.

There is no silver bullet, more power to the developer!

Second, the 2nd triangle is the actual means to allow exactly what I just described above. It enables developers to use each part of the first triangle and makes Spring the Swiss knife of application frameworks. So why choosing an axe instead? ;)

Hades 1.5 released

2010-04-11T09:52:59Z

As you probably already might have noticed, yesterday we released Hades 1.5. Alongside with that the firs 2.0 release candiate sees the light of the day, too. Let me just take some lines to elaborate on the specialty of this release.

Why 1.5?

The first question that might arise is why this release is 1.5 whereas it’s predecessor was 1.1.2. Originally the release was planned as 1.2 but as it introduces some long-ranging features and changes we thought it might be worth indicating that in a larger step of version numbers. As 2.0 is already taken for our JPA 2 upgrade, 1.5 was the choice to go. So what do I mean with “long-ranging”?

Since it’s beginning Hades relied on two major interfaces: GenericDao and Persistable where as especially the latter raised some discussions here and there. Although it is not that of a big deal to implement a 3rd party interface with an entity class it was indeed a hurdle for adoption. So why was it introduced in the first place. GenericDao had the aim to abstract between creation and updates of objects. Although there slight semantic differences this maps to the difference between using EntityManager methods persist(…) and merge(…). To know what to call when save(…) is being called on GenericDao we have to be able to differentiate between a new and an existing entity. As this algorithm might vary from entity to entity, we chose to leave the burdon to decide that to the entity developer by implementing the interface.

Although implementing this interface should not be a big deal actually, we (and the developer community) were not really satisfied with that solutions as the technical infrastructure slightly leaks into the domain abstraction which is somewhat suboptimal kindly speaking. The good news is: as of Hades 1.5 there is no need to implement Persistable anymore. The DAO implementation now uses a reflective approach to lookup the id property of the entity and inspects its value. If it is null, the entity is regarded as new or as already existing otherwise. So that’s the default. If you need to tweak the semantics of new, simply implement Persistable as the algorithm will be simply calling isNew() on you instance then. So in effect, the interface comes into play if explicitly needed and not in any other case.

That’s the big news. Behind that we have a few new features regarding the XML namespace to be used in Spring applications. In case you have multiple EntityManagerFactory beans declared (e.g. in case you work with more than one JPA persistence unit), you can now point the dao-config and dao elements to a specific EMF bean by using entity-manager-factory-ref attribute. Furthermore using exclude-filter and include-filter (probably known from Spring’s context namespace) can be used to tune DAO auto configuration in a more fine grained way. Besides that we have done a general overhaul to the query creation subsystem and now also allow keywords like Between, LessThan and GreaterThan in method names. To round things up we’ve fixed a few minor bugs here and there. For more details read the changelog or the updated reference documentation.

Hades 2.0

Alongside this important step we make another one. JPA 2.0 specification was released a while ago and most existing JPA 1 application wil definately benefit from an upgrade as the new spec version really fills gaps the old one left to workaround for the developers. So what is our approach to the new spec. From a Hades point of view the most intresting part of the new spec is the criteria API as user’s probably will base their custom DAO implementations on it. Furthermore upgrading (Spring) applications demands applications to upgrade to Spring 3.0 and a new major version of the persistence provider of choice we choose to dedicate a 2.0 version of Hades to it.

So the first release candidate builds on top of Spring 3.0.2 as well as Hibernate 3.5, EclipseLink 2.0 as well as OpenJPA 2.0 Beta 3. We will probably wait for our final release until OpenJPA is final, too, but as the majority of users are split between Hibernate and EclipseLink we think that rolling out a release candidate is a good way to get feedback and battle proof the new version. The major change inside Hades 2.0 is that we dropped support of the read-by-example way to access entities. This had to be implemented in a provider specific way so that we could even simplify the codebase in that regard. Furthermore the DAO abstraction is now clearly centered around GenericDao and not blurred with additional interfaces.

So if you can upgrade to Spring 3.0.x and the JPA 2 ready persistence provider already, give Hades 2.0 a try. It should be a drop in replacement in this case. Having that said, it’s probably worth mentioning that even Hades 1.5 can be used with JPA 2.0 but requires more extensive pom configuration on the developer side (as Spring 2.5.6 does not support JPA 2). As you’d end up with a dependency setup similar to the one decalred in 2.0 you’re probably better of just upgrading to Hades 2.0.

Neglected classes in Spring – Part III

2010-07-01T19:10:27Z

Java web application developers often face the need to inject a regular Spring bean into a non-Spring-managed artifact like a Servlet or a JSP tag.. If you browse the web for you find various quite outdated solutions to it. No offense, by the time being these were quite appropriate solutions. One of them you’ll probably will find is the following:

public class MyServlet extends HttpServlet {

  private MyService service;

  @Override
  public void init(ServletConfig config) {

    ServletContext context =
      config.getServletContext();

    ApplicationContext ctx =
      WebApplicationContextUtils.
        getRequiredWebApplicationContext(context);

    service = ctx.getBean(MyService.class);
  }
}

Let’s recap what we just have done. First we need to get access to the ServletContext of the web application. A Spring WebApplicationContext that was registered by a ContextLoaderListener will be registered in the ServletContext under a special name the framework knows, so that WebApplicationContextUtils can then look it up and hand it out to you to manually retrieve Spring beans from it.

Okay, that get’s the job done. But we can reduce the effort and go a much nicer way, that reduces the amount of boilerplate even more. Spring 2.5.1 introduced a tiny helperclass SpringBeanAutowiringSupport which is residing in org.springframework.web.context.support spending a rather unregarded life. It offers a method processInjectionBasedOnCurrentContext(Object target) that automatically injects Spring beans to properties of the given target using the usual annotation driven suspects (@Autowired, @Inject). So our sample code turns into something like this:

public class MyServlet extends HttpServlet {

  @Inject
  private MyService service;

  @Override
  public void init() {
    SpringBeanAutowiringSupport.
      processInjectionBasedOnCurrentContext(this);
  }
}

Done. Note, that we override the init method without the ServletConfig parameter as the called method looks up the actual ApplicationContext from a static map held in ContextLoader which inherits from. If you need to lookup beans from an ApplicationContext tied to a particular ServletContext you can use processInjectionBasedOnServletContext(Object target, ServletContext servletContext) and hand it the appropriate instances.

P.S.: Thanks to Eberhard Wolff for pointing me at this.

REST based web applications with Spring 3

2010-04-01T08:28:28Z

Yesterday I gave a talk on REST based web applications with Spring 3. You can download the slides or just watch ‘em below. You can also grab the sample code at github.

REST based web applications with Spring 3

View more presentations from Oliver Gierke.

New challenges

2010-02-10T08:53:54Z

It’s been official for a few days now, so I thought I could drop a public note about me joining SpringSource Germany (division of VMware) as Senior Consultant beginning March 1st this year. Time to look back on three exciting years at Synyx and an outlook of what’s about to come.

I joined Synyx almost exactly 3 years ago. Since then I had an exciting time with awesome folks, a wide variety of customers, projects and conferences. As I dealt with enterprise Java software a ton, of course Spring has been a crucial part of my daily job, no matter if it was the core framework, the software eco system and people around it or the open source project Hades that I lead, which is based on Spring and carries Spring principles and values to the domain of easing data access with JPA.

Besides that, the crucial part to me is that Spring and SpringSource as a company have always provided pragmatic solutions to real world problems that are of quality far beyond average. As I already became more and more involved with the Spring codebase, too, I am thrilled to join the team to even more close to the heart of the – to me – core principle of software engineering: pragmatic, high quality solutions to real world problems.

To wrap things up, I’d like to say thank you to all the fellow developers, customers and people in general I met during my time at Synyx. If you need custom first class Java based business software, like to work with people that don’t hesitate to think out of the box – Synyx is the shop you’re looking for.

It’s been a pleasure! And it will be…