javaconfig spring

Consider replacing Spring XML configuration with JavaConfig

Spring articles are becoming a trend on this blog, I should probably apply for a SpringSource position :-) Colleagues of mine sometimes curse me for my stubbornness in using XML configuration for Spring. Yes, it seems so 2000’s but XML has definite advantages: Configuration is centralized, it’s not scattered among all different components so you can have a nice overview of beans and their wirings in a single placeIf you need to split your files, no problem, Spring let you do that.

search solr

Solr overview from a beginner's point of view

I’ve recently begun diving into Search Engines in general and Solr in particular. This is my understanding of it so far. Why Solr? It isn’t really feasible to execute blazing fast search queries on very big SQL databases for 2 different reasons. The first reason comes SQL databases favoring lack of radiancy over performance. Basically, you’d need to use JOIN in your SELECT. The second reason is about the nature of data in documents: it’s essentially unstructured plain

spring

Spring beans overwriting strategy

I find myself working more and more with Spring these days, and what I find raises questions. This week, my thoughts are turned toward beans overwriting, that is registering more than one bean with the samee name. In the case of a simple project, there’s no need for this; but when building a a plugin architecture around a core, it may be a solution. Here are some facts I uncovered and verified regarding beans overwriting. Single bean id per file The id attribute in the Spring bean fil

spring

The case for Spring inner beans

When code reviewing or pair programming, I’m always amazed by the following discrepancy. On one hand, 99% of developers conscientiously apply encapsulation and limit accessibility and variable scope to the minimum possible. On the other hand, nobody cares one bit about Spring beans and such beans are always set at top-level, which makes them accessible from every place where you can get a handle on the Spring context. For example, this a typical Spring beans configuration file: <bea

spring

Changing default Spring bean scope

By default, Spring beans are scoped singleton, meaning there’s only one instance for the whole application context. For most applications, this is a sensible default; then sometimes, not so much. This may be the case when using a custom scope, which is the case, on the product I’m currently working on. I’m not at liberty to discuss the details further: suffice to say that it is very painful to configure each and every needed bean with this custom scope. Since being lazy in a s

dry spring

DRY your Spring Beans configuration file

It’s always when you discuss with people that some things that you (or the people) hold for an evidence seems to be a closely-held secret. That’s what happened this week when I tentatively showed a trick during a training session that started a debate. Let’s take an example, but the idea behind this can of course be applied to many more use-cases: imagine you developed many DAO classes inheriting from the same abstract DAO Spring provides you with (JPA, Hibernate, plain JDBC,

arqullian java EE tomEE

Pet catalog for JavaEE 6 reengineered

Some time ago, I published the famed Pet Catalog application on Github. It doesn’t seem like much, but there are some hours of work (if not days) behind the scenes. I wanted to write down the objectives of this pet project (noticed the joke here?) and the walls I hit trying to achieve them to prevent others to hit them. Objectives were very simple at first: get the Pet Catalog to work under TomEE, the Web Profile compliant application server based on Tomcat. I also wanted to prove that by

dao

Do we really need the DAO?

This may seem like a stupid question, especially after years of carefully creating them. Yet these thoughts about DAO arose in my mind when I watched Adam Bien’s Real World JavaEE rerun on Parley’s. In his talk, Adam says he doesn’t use DAOs anymore - even though he has one ready so as to please architects (them again). My first reaction was utter rejection: layered architecture is at the root of decoupling and decoupling is a requirement for an evolutive design. Then, I diges