Bean of type is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)

30. October, 2013

Haunted by this? Getting mysterious NullPointerExceptions in your BeanPostProcessors?

I have written a lengthy answer how to debug and solve these issues on

Nice Debt Collectors Make More Money

26. October, 2013

It’s a fact that the majority or the “obvious” is often wrong. During World War II, groups of engineers tried to figure out how to best reinforce airplanes to reduce losses of life and material. For this, a study was conducted about the kind of damage planes showed as they returned to base. The general consensus was that the spots with the holes were the places which needed reinforcement.

The mathematician Abraham Wald objected and argued to reinforce all the other places. If you wonder what’s wrong with this guy, consider this: These were the airplanes that had returned. So the holes must be in places where the plane could sustain some damage. Which means the other, the lost planes must have been hit elsewhere.

When Bill Bartmann founded CFS2, ” a debt-collection company based in Tulsa, OK,” he faced a similar issue. Most debt-collectors threaten their … err … victims? Bill found that a pretty stupid strategy. Why not help the indebted to make money? Like as in enabling them to pay the debt?

As the Wikipedia article states:

Counter-intuitively CFS2 offers a unique array of free services to those they are collecting from, including: employment assistance,[16] credit specialists who negotiate reductions of other personal debt, resume writing, medical discounts and help accessing government assistance.

One of the results: This enables “CFS2 to collect at rates twice the industry average.”

See? Being nice does pay off!

Jazoon 2013 Overview

25. October, 2013

Here is the list of blog posts about all the talks that I attended at Jazoon 2013:

Day 1

Day 2

Jazoon 2013 – Successful Collaboration in Agile Software Teams

25. October, 2013

Jazoon 2013 badgeIn his talk “Successful Collaboration in Agile Software Teams,” Martin Kropp lists the key factors for collaboration in agile software teams. (slides on slideshare)

For me the most important points were (slide 6):

“Agile collaboration is …

  • Face-to-face
  • Regular
  • Often
  • Informal
  • Openly
  • Under equals
  • Focused
  • Transparent
  • Respectful
  • Flexible

No is no “Agile by the Book.”

After that, he lists the usual pain points:

  • Hidden leaders
  • People sending assignments by email
  • Meetings without purpose and goals
  • Missing tools like chat, video conferencing
  • Physical vs. the digital whiteboard (slide 18)

Modern technologies like large touchscreens will make things better (slide 23).

A word about open-plan offices: They are the best tool to reduce productivity. See these articles to learn why:

Jazoon 2013 – The Economies of Scaling Software

25. October, 2013

Jazoon 2013 badgeIf you’re small, scalability is not an issue. If you’re big, you can plan for it. But what if you wake up one morning and you suddenly find you’ve become the next Google?

In his talk “The Economies of Scaling Software“, Abdelmonaim Remani talks about what scaling means, how you can plan for it (even if you don’t expect it to happen) and all the nasty details that stand between you and success (slides on slideshare).

Today, the ubiquity of the Internet has blurred the lines between consumers and enterprises. They start to ask the same questions which eventually all boil down to: “How can I find what I’m looking for in a universe of haystacks?”

One day, many of us will find themselves with the need to scale because the performance of the old solution has become unbearable and all low-hanging fruit (faster CPU, more RAM) have been picked.

To solve this, you can look at the CPU (slide 16-35) or you can start to build clusters (36-45).

Or your I/O might be the bottleneck (slides 46-60). You can solve this by looking at NoSQL databases and caching.

Is the network the problem? (slides 61-75) Start with asynchronous processing, batch jobs, content delivery networks (CDN), DNS sharding or use a different protocol to connect the various parts of your system.

But how do you know what part is the bottleneck? The answer here is monitoring. (slide 77)

Note that scaling often helps with disaster recovery, you still have to plan for it – if all nodes of your cluster are in the same room, it’s still a single point of failure (slide 79)

Software isn’t everything. Don’t forget your team (slide 82)

Jazoon 2013 – Join the Java Evolution; JCP & Adopt-a-JSR

25. October, 2013

Jazoon 2013 badgeHeather VanCura explained how the new JCP works in her talk “Join the Java Evolution; JCP & Adopt-a-JSR” (slides on slideshare)

Oracle spent the last years to make the JCP much more open and accessible. One example here are the JSRs which are much more lightweight than the complex JCPs. You can even adopt one.

Maybe you’re a long time joda-time user and want to make sure important features make it into JSR 310 – new Date and Time API for Java? Join them to discuss your need, share some code, help write, improve or translate documentation.

Some bug in the SDK nagging you? Contribute a fix to the OpenJDK. With Java 8, the OpenJDK build has been simplified tremendously. Sun ignored your bug report for years even though it contained a patch? Now is the time to change this.

I had the chance to chat with Heather after the talk which earned me a copy of “Java 7 Concurrency Cookbook”; thanks for that 🙂 We discusses a couple of ideas and she gave me points; maybe I’ll submit a few patches. If I do, I’ll blog about the experience here.

Jazoon 2013 – Real World Git Workflow

25. October, 2013

Jazoon 2013 badgeWhen using git, you really have to define a workflow that you want to use. In his talk “Real World Git Workflow” (slides on slideshare), Stefan Saasen explains some kinds of workflows and when they are appropriate.

The first step in any workflow design is asking questions. Some examples that will sound familiar:

  • “Can we fix a bug for a specific release?”
  • “Can we do a fast hotfix for the current release?”
  • “Can we build the current code?”
  • “Is the code for that feature complete?”
  • “Has everybody reviewed the code for this feature?”

Your questions will be different but make sure you ask them. There is no perfect workflow but there is your workflow. Omit this step at your own peril.

Collaboration Models

First, which collaboration model do you use?

“Anarchy” (anyone can push anywhere, slide 17), “Gatekeeper” (one person reviews all changes, often used by OSS projects, slide 18), “Dictator and Lieutenants” (Linux, slide 19) or “Centralised” (slide 20). See also “Git Workflows” on

In the enterprise, the centralized model is often used. This approach makes it most simple to integrate all the tools (CI servers, code quality tools, deployment, …). (slide 23)

Branching Models

The two most common branching models are “continuous delivery” and “product releases.” (slide 25)

From slide 28:

Significant branches map to a concept in the outside world. It may be a past release, an environment or a role. Those branches are long-running and stable whereas feature branches are short lived and volatile.”
– Stefan Saasen

Slide 27 shows the branches for “continuous delivery”. PR is a “pull request.”

As you can see, development is consolidated in the staging branch and pushed into production (master branch) from there. If you make a hotfix in the master branch, it is cherry-picked back into staging.

Slide 30 shows how to handle “product releases.” You have a single, central repository with a master branch which consolidates the development (no staging). Each feature and bugfix happens in a short-lived “feature branch.” When a release is made (slide 31), then a new long living release branch is created. Bug fixes still happen in short lived branches.

When the bug is fixed, the fix is first merged back into the oldest affected release. From there in the next release until you get to the latest release from which it is then merged back into master (slide 33).

But what about changes you don’t want to merge like the changes made by the Maven release plugin? Maybe you will want to replace it with a better release workflow.

Or we use the correct git merge strategy: ours. This creates a new changeset with the merge information without actually merging anything. For git, it will look as if everything has been done and it won’t bother us with merging those changes ever again (slide 39).

Merge Protocols

While the above sounds reasonable, the question is why? What are the rules and forces which make this better? Stefan introduces “the merge protocol” to answer this. See slide 42 for this.

In a nutshell, you always try to merge more stable branches into less stable ones: Bug fix branch into branches where the bug hasn’t been fixed, yet. Features into branches which don’t have the feature.

That’s why you never merge master back into a release branch: Releases are most stable. You merge them into master. If you have fixed in master that you really need in a release, you cherry-pick them (slide 43).

Pull Requests

A lot of people understand why code reviews would be a good thing, “but …” Sounds familiar? Then pull requests are for you.

Pull requests are an easy, low-overhead tool to have as much “code review” as you feel comfortable with. You can merge with by clicking a button or you can review the changes line-by-line. Your choice.


Most projects will use a single canonical repository but remote forks are useful, too. Imagine you have fixed an important (for you at least) bug in a OSS project. You send them a pull request but it’s rejected! What do you do?

You fork the project. git allows you to still track the changes made by the original project while isolating your life as much as you want (slide 52)

A fork is nice if you want to do an innovation spike – code that might never be included in the product. Fork instead of polluting the project history with dead experiments (53).

Some department needs big changes to some component? Fork it until the feature stabilizes. You can still merge them if you want, but you don’t have to (54).

Reduce the noise (55). A fork allows you to rewrite history.


You can use pre and post hooks to make everyone’s life easier. Use a local pre-commit or pre-push hooks to make sure some important tests have been run. For example, you could run FindBugs or checkstyle.

An interesting post-checkout hook would be to check whether the branch is green (66), i.e. code builds and all tests pass. Stop wasting time to search for bugs that were already there before you started your work. You can get this gem from (69).

Continuous Integration

The explosion of branches can quickly bog down your build server if you don’t come up with a strategy to handle this (71). Usually, it’s enough to build stable and master but developers will love it when they can manually trigger feature branch builds (72).