Spring configuration beans context Kotlin

Multiple ways to configure Spring

Two weeks ago, I wrote how you could write a Spring application with no annotations. Many alternatives are available to configure your Spring app. I’d like to list them in this post, leaving Spring Boot out of the picture on purpose. Core concepts Property file XML Groovy DSL Self-annotated classes Configuration classes Kotlin DSL Bean definitions Beans Conclusion Core concepts A couple of concepts are central in Spring. The related documentation doesn’t describe most of them

xml json yaml configuration data exchange

In defense of XML

When I started my career, XML was ubiquitous. The meta-information in a Java JAR file - the manifest - follows a proprietary format. But Java EE designers built it from the ground up on XML: meta-information of all artifacts is in XML format e.g. web.xml, ejb-jar.xml, application.xml, etc. Java EE is one example I experienced personally. But XML was everywhere in the enterprise world at the time. Its prevalence manifested itself in two areas: configuration and data transfer. Ever since then,

Kubernetes container initialization configuration

The versatility of Kubernetes' initContainer

There are a lot of different ways to configure containers running on Kubernetes: Environment variablesConfig mapsVolumes shared across multiple podsArguments passed to scheduled podsetc. Those alternatives fit a specific context, with specific requirements. For example, none of them allow you to clone a Git repository before the container starts. It would be possible to design that feature into the image itself. Yet, that would introduce coupling, and defeat the Single Responsibility principl

Spring configuration Groovy Kotlin XML annotations

Flavors of Spring application context configuration

Every now and then, there’s an angry post or comment bitching about how the Spring framework is full of XML, how terrible and verbose it is, and how the author would never use it because of that. Of course, that is completely crap. First, when Spring was created, XML was pretty hot. J2EE deployment descriptors (yes, that was the name at the time) was XML-based. Anyway, it’s 2017 folks, and there are multiple ways to skin a cat. This article aims at listing the different ways a Sprin

configuration maven spring

Spring profiles or Maven profiles?

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

configuration spring

Avoid conditional logic in @Configuration

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

configuration convention installation

Seamless installation: convention over configuration

Today, I will not take the role of the architect that knows how to deliver applications but instead I will play the end-user part. In a previous post, I was tasked to put a whole development infrastructure in place. A continuous integration server was indeed in order. I took a look at some, but I was really dumbfounded when I tried Hudson. Features are not what stroke me at that time (although Hudson’s features did serve me well) but only the ease of installation. Let’s look at a