Nicolas Fränkel

So you were tasked to prepare your next software project. Already, its overall architecture is designed, you already put some code-related parts in place such as the build file, the packages, perhaps a sample use-case. Then after a few months, the project is finished, and the final result has largely diverged from what you imagined:inconsistent packages naming and organization, completely different low-level implementations e.g. XML dependency injection, auto-wiring and Java configuration, etc.

This week, there won’t be any technical article. As you might have heard about, cowards armed with automatic weapons brutally murdered cartoonists, journalists, policemen…​ All all in all, 12 people died because of stupidity and obscurantism, just because their truth was contradictory to their murderers' - or just because they happened to be on site. Right now, I’m afraid I start to understand what American people felt after September 11th. I’m not a cartoonist,

Deploying on different environments requires configuration, e.g. database URL(s) must be set on each dedicated environment. In most - if not all Java applications, this is achieved through a .properties file, loaded through the appropriately-named Properties class. During development, there’s no reason not to use the same configuration system, e.g. to use an embedded h2 database instead of the production one. Unfortunately, Jave EE applications generally fall outside this usage, as the good

I’m a regular Spring framework user and I think I know the framework pretty well, but it seems I’m always stumbling upon something useful I didn’t know about. At Devoxx, I learned that you could express conditional dependencies using Java 8’s new Optional type. Note that before Java 8, optional dependencies could be auto-wired using @Autowired(required = false), but then you had to check for null. How good is that? Well, I can think about a million use-cases, but here are

Integration Testing Spring applications mandates to create small dedicated configuration fragments and to assemble them either during normal run of the application or during tests. Even in the latter case, different fragments can be assembled in different tests. However, this practice doesn’t handle the use-case where I want to use the application in two different environments. As an example, I might want to use a JNDI datasource in deployed environments and a direct connection when devel

I’m a huge Vaadin fan and I’ve created a Github workshop I can demo at conferences. A common issue with such kind of workshops is that attendees have to prepare their workstations in advance…​ and there’s always a significant part of them that comes with not everything ready. At this point, two options are available to the speaker: either wait for each of the attendee to finish the preparation - too bad for the people who took the time at home to do that, or start an