A Java geek

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.

Java

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.

Java

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.

Java

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.

Development

The power of naming

Before diving right into the subject of naming, and at the risk of souding somewhat pedantic, an introduction is in order. History show us that naming is so important to the human race that it’s being regarded as sacred (or at least) magical in most human cultures. Some non-exhaustive examples include: Judaïc tradition go to great lengths to search for and compile the names of God.

JavaEE

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.

Java

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.

Miscellaneous

Short-term benefits in the Information Service business

It’s a fact that companies and their management have money in mind. However, they’re many ways to achieve this goal. In my short career as an employee, I’ve been faced with two strategies, the short-term one and the long-term one. Here are some examples I’ve been directly confronted with: A manager sends a developer on an uninteresting mission a long way from home.

Miscellaneous

The cost and value of knowledge

I was a student in France when I discovered the Internet and the World Wide Web. At that time, I didn’t realize the value of the thing, even though I taught myself HTML from what was available at the time (even if I don’t remember the sites - they probably have disappeared into Limbo). When I began my professional life, a project director of mine joked about the difference between the developer and the expert: 'The expert knows about the cabinet where the documentation is'.

Nicolas Fränkel's blog