Configuration files must Die!!!

1. Configuration files must Die!!! - Dependency Injection made easy Yasuo Higa The Seasar Foundation/Chief Committer http://www.seasar.org/en

2. I have always wanted to askevery developer in the world this question: Do you really like writing configuration files?

3. I hate it too! That's because writing them is a real headache! I hope every developer in the world feels the same.

4. Still, despite our feelings, the Java world is full of configuration files. We can call this tragic situation "XML HELL".

5. Please try to remember the frameworks which represent Web and DI. They are full of configuration files. The issue that causes us such serious problems is the enlargement of configuration files.

6. One of the solutions againstthe enlargement of configuration files is annotation which appeared in Java5.

7. If we use annotation, we rarely need to write configuration files. That's because we can embed the configuration data into the source code.

8. Then, is this annotation really helping us?The only difference is that the place where we write the configuration data has moved from the configuration file to the source code.

9. The fact that we are to write the configuration data has not changed.

10. The thing we really hope for and must realize is to minimize the amount of the configuration data we have to write not only in the configuration file but also in the source code.

11. I call this concept Less Configuration. I think this is what the framework should be.

12. Agenda • Problem of DI • Less Configuration concept • Response to EJB3 in Seasar2

13. One of the important principles of DI is separating configuration from use.

14. When this principle is applied, someone is to set the implementation object to the function user. A DIContainer plays this role.

15. We need to give instructions to the DIContainer about the way to set the implementation object. According to these instructions, configuration files are the most popular.

16. "Greeting" is the interface which gives us the greeting function package examples.di; public interface Greeting { String greet(); }

17. "GreetingImpl" is the implementation class which gives us the greeting function package examples.di.impl; import examples.di.Greeting; public class GreetingImpl implements Greeting { public String greet() { return "Hello World!"; } }

18. "GreetingClient" is the interface which uses the greeing function package examples.di; public interface GreetingClient { void execute(); }

19. "GreetingClientImpl" is the implementation class which uses the greeting function package examples.di.impl; … public class GreetingClientImpl implements GreetingClient { privateGreeting greeting; public void setGreeting(Greeting greeting) { this.greeting = greeting; } public void execute() { System.out.println(greeting.greet()); } }

20. "beans.xml" is the configuration file by which we give instructions to the DIContainer about the way to set the implementation object <beans> <bean id="greeting" class="examples.di.impl.GreetingImpl"/> <bean id="greetingClient" class="examples.di.impl.GreetingClientImpl"> <property name="greeting"> <ref bean="greeting"/> </property> </bean> </beans>

21. The "GreetingMain" class takes the greeting client implementation object from the DIContainer, and executes it package examples.di.main; import …; public class GreetingMain { public static void main(String[] args) { ClassPathResource res = new ClassPathResource("beans.xml"); XmlBeanFactory factory = new XmlBeanFactory(res); GreetingClient greetingClient = (GreetingClient) factory.getBean("greetingClient"); greetingClient.execute(); } }

22. When we take a look at these samples, the DIContainer faithfully realizes the "separating configuration from use" principle.

23. When we check these samples, we don't find any problem. Where is the probrem?

24. When the developement scale is larger, the problem of the DIContainer as we know it today comes to the surface. The configuration file becomes enlarged proportionally to the development scale.

25. As the configuration file becomes enlarged, • it is difficult to find class configuration data in the file • it is also difficult to locate the cause when we make a mistake in the configuration file

26. One of the solutions againstthe enlargement of configuration files is a way to embed the configuration data into the source code using XDoclet or annotation.

27. Basically the written information is the same <bean id="greetingClient" class="examples.di.impl.GreetingClientImpl"> <property name="greeting"> <ref bean="greeting"/> </property> </bean> /** * @spring.bean id = "greetingClient" * @spring.property name = "greeting" ref = "greeting" */ public class GreetingClientImpl ...

28. When we use XDoclet, we can get the necessary information only looking at the source code, because the configuration data is written in the source code. This is a big advantage. Still there is one disadvantage as well.

29. The disadvantage of XDoclet is that in case we change the configuration data we'll have to rewrite the source code.

30. If we use the configuration files, even if we change the configuration data we don't need to rewrite the source code. This is a real headache.

31. XDoclet is not an all-powerful solution.

32. On the one hand, we have the advantage that we rarely need to write configuration files. On the other hand, we have the disadvantage that if we change the configuration data we have to rewrite the source code.

33. The advantages and disadvantages of annotation are the same as those of XDoclet. Annotation is also not an all-powerful solution. So, what are we supposed to do?

34. If we use configuration files or if we use XDoclet or annotation, in both cases, the problem occurs when we write the configuration data. So, if we decide from the beginning not to write the configuration data, the problem will not occur.

35. I call this concept of reducing the writing of configuration data as much as possible Less Configuration. So how can we realize it?

36. To realize the "Less Configuration" concept, it's important to take into consideration the following 2 ideas: • Convention over Configuration • Configuration by Exception

37. "Convention over Configuration" is the idea that If we apply the proper convention, even if we don't do any special configuration, the framework will do the proper configuration for us.

38. The first convention is that the type of property is defined as the interface. So what do we get if we apply this convention?

39. If the type of property is interaface, Seasar2 can automatically set the object implementing the interface to the property. This function corresponds to the autowiring byType in "Spring".

40. I'll explain later about the situation when Seasar2 can't specify one object because several objects implement the same interface.

41. Also if the property name and the object name are the same and the object is settable to the property, Seasar2 can automatically set the object to the property. That function corresponds to the autowiring byName in "Spring".

42. Seasar2 can perform the automatic binding of property in default.

43. When Seasar2 can't automatically set a proper object, we have the following choices: • give an exception • give a warning • ignore it The default gives a warning.

44. The next convention is that we name the implemention class according to the rule. For example, it seems that the implementation class name ends in "Impl". So, what do we get if we apply this convention?

45. Seasar2 can automatically register classes whose names obey specified rules into the container. If the target classes are included in the classpath, it doesn't matter if they are in the jar file or not.

46. Due to Seasar2 automation, we rarely need to write the configuration data, even if the development scale is larger.

47. beans.dicon <components> <component class="...FileSystemComponentAutoRegister"> <initMethodname="addClassPattern"> <arg>"examples.di.impl"</arg> <arg>".*Impl"</arg> </initMethod> </component> </components>

48. We only had two classes in this sample, but the more the number of classes increases, the more powerful Seasar2 automation becomes.

49. If we set the class name patterns from the beginning, it's not necessary to add any information to the configuration file, even if the number of classes increases.

50. Unlike the XDoclet and annotation, we can automatically adapt the configuration data changes, because the configuration data is not embedded in the source code.