Nice and explanatory as all Spring’s Guides are. First “configure” method registers “/” and “home” as public and specifies that everything else should be authenticated. It also registers login URL. Second “configure” method specifies authentication method for role “USER”. Of course you don’t want to use it like this in production :).

Everything is public and private endpoints have to be listed. You can see that my amended code have the same behavior as original. In fact it saved one line of code.

But there is serious problem with this. What if my I need to introduce new private endpoint? Let’s say I am not aware of the fact that it needs to be registered in Spring Security configuration. My new endpoint would be public. Such misconfiguration is really hard to catch and can lead to unwanted exposure of URLs.

Method showRunners is using Java 8 forEach method that consumes method reference. This construct outputs loaded beans into console. You would find a lot of reading about these new Java 8 features these days.

I wrote blog post about testing field injection with Mockito (using @InjectMocks/@Mock/@Spy). It describes how to inject dependencies into testing object. But I didn’t pay attention to thinking about problems of field injection itself. Let me summarize few arguments against field injections that convinced me to treat it as bad practice:

Field injection hides class dependencies. Constructor injection on the other hand exposes them. So it’s enough to look at class API.

Constructor injection uses standard Java features to inject dependencies. It is definitely much cleaner than field injection which involves using reflection twice under the hood:

Spring must use reflection to inject private field

Mockito (during the test) must use reflection to inject mocks into testing object

Developer would need to create awful non-default constructor with a lot of parameters for tightly coupled class. Nobody likes huge amount of parameters. So constructor injection naturally forces him to think about decoupling and reducing dependencies for the class. This is biggest advantage of constructor injection for me.

So I am another member of Constructor injection camp now. This nice Petri Kainulainen’s blog post gathers more reading about pros and cons of both approaches.

Spring projects contain wide range of frameworks and abstraction APIs for Enterprise Integration. Best way to get an overview what Spring provides is to attend Enterprise Integration with Spring Training. It is unfortunately not affordable for everybody and I am not aware of any publication out there that explains Spring’s integration technologies altogether. Training includes:

Tasks and Scheduling support

Spring Remoting

Spring Web Services

Spring REST with Spring MVC

Spring JMS

Local and distributed transactions support

Spring Itegration

Spring Batch

I recently attended this course (thanks to my employer) and did certification exam afterwards. Now I would like to share my study notes and hints. These should provide you decent overview about Enterprise Integration with Spring. Study notes should cover everything needed for certification exam. But for passing the exam it isn’t enough just to memorize them. Unless you are familiar with these technologies already. They contain too many crucial information you can easily miss. You wouldn’t be successful until you get used each particular technology at least via examples or tutorials. I went through original SpringSource labs provided by training, few examples and tutorials. Also I was already familiar with Spring JMS, Spring MVC, Spring Integration and Spring transaction demarcation.

Study notes

Are based mainly on Spring reference documentations

Also contains some crucial principles and best practices Spring promotes that are usually not mentioned in reference documentations