1. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 1 Configuration files must Die!!! Yasuo Higa The Seasar Foundation/Chief Committer http://www.seasar.org/en - Dependency Injection made easy

2. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 2 Do you really like writing configuration files? I have always wanted to ask every developer in the world this question:

3. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 3 That's because writing them is a real headache! I hate it too! I hope every developer in the world feels the same.

4. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 4 the Java world is full of configuration files. Still, despite our feelings, We can call this tragic situation "XML HELL".

5. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 5 They are full of configuration files. Please try to remember the frameworks which represent Web and DI. The issue that causes us such serious problems is the enlargement of configuration files.

6. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 6 One of the solutions against the enlargement of configuration files is annotation which appeared in Java5.

7. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 9 The fact that we are to write the configuration data has not changed.

10. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 11 I call this concept Less Configuration. I think this is what the framework should be.

12. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 12 Agenda ● Problem of DI ● Less Configuration concept ● Response to EJB3 in Seasar2

13. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 13 One of the important principles of DI is separating configuration from use.

14. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 14 When this principle is applied, someone is to set the implementation object to the function user. A DIContainer plays this role.

15. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 16 package examples.di; public interface Greeting { String greet(); } "Greeting" is the interface which gives us the greeting function

17. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 17 package examples.di.impl; import examples.di.Greeting; public class GreetingImpl implements Greeting { public String greet() { return "Hello World!"; } "GreetingImpl" is the implementation class which gives us the greeting function

18. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 18 package examples.di; public interface GreetingClient { void execute(); } "GreetingClient" is the interface which uses the greeing function

19. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 19 package examples.di.impl; … public class GreetingClientImpl implements GreetingClient { private Greeting greeting; public void setGreeting(Greeting greeting) { this.greeting = greeting; } public void execute() { System.out.println(greeting.greet()); } "GreetingClientImpl" is the implementation class which uses the greeting function

20. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 20 <bean id="greeting" class="examples.di.impl.GreetingImpl"/> <bean id="greetingClient" class="examples.di.impl.GreetingClientImpl"> "beans.xml" is the configuration file by which we give instructions to the DIContainer about the way to set the implementation object

21. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 21 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(); } The "GreetingMain" class takes the greeting client implementation object from the DIContainer, and executes it

22. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 22 When we take a look at these samples, the DIContainer faithfully realizes the "separating configuration from use" principle.

23. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 23 When we check these samples, we don't find any problem. Where is the probrem?

24. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 26 One of the solutions against the enlargement of configuration files is a way to embed the configuration data into the source code using XDoclet or annotation.

27. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 27 <bean id="greetingClient" class="examples.di.impl.GreetingClientImpl"> /** * @spring.bean id = "greetingClient" * @spring.property name = "greeting" ref = "greeting" */ public class GreetingClientImpl... Basically the written information is the same

28. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 29 The disadvantage of XDoclet is that in case we change the configuration data we'll have to rewrite the source code.

30. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 31 XDoclet is not an all-powerful solution.

32. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 40 I'll explain later about the situation when Seasar2 can't specify one object because several objects implement the same interface.

41. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 42 Seasar2 can perform the automatic binding of property in default.

43. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 45 classes whose names obey specified rules into the container. Seasar2 can automatically register If the target classes are included in the classpath, it doesn't matter if they are in the jar file or not.

46. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 46 Due to Seasar2 automation, we rarely need to write the configuration data, even if the development scale is larger.

47. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 47 <component class="...FileSystemComponentAutoRegister"> "examples.di.impl" ".*Impl" beans.dicon

48. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 48 We only had two classes in this sample, but the more the number of classes increases, the more powerful Seasar2 automation becomes.

49. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 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.

51. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 51 If you hear the word convention, you might get the troublesome impression that you have to obey it. But all conventions in Seasar2 are desirable. And if we obey the conventions, Seasar2 automation will make our work much easier.

52. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 52 If the conventions make our work easier, I hope everybody would want to obey them. These are the conventions in Seasar2.

53. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 53 In most cases, Seasar2 automation is more and more powerful, but if several objects implement one interface, Seasar2 automation doesn't work well. Then, the necessary solution is "Configuration by Exception".

54. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 54 "Configuration by Exception" is the idea that we explicitly configure the objects only in exceptional situations. When the defaults of "Convention over Configuration" don't work well, we have an exceptional situation.

55. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 55 We can explicitly configure them using either the configuration file or annotation. I would like to explain later in detail about which one we should use.

56. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 56 @Binding("hoge2") public void setHoge(Hoge hoge) { this.hoge = hoge; } @Binding(bindingType=BindingType.NONE) public void setHoge(Hoge hoge) { …; } a sample of annotation in Seasar2

57. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 57 We rarely need to use the "Binding" annotation, because the automatic binding of property works in most cases. Please use the "Binding" annotation only in exceptional cases.

58. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 58 Annotation is a technology which appeared in Java5. In case we have to use Java1.4, you would think we have to give up annotation. However we don't.

59. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 59 There is a project called backport175. backport175 implements the Java 5 annotation specifications, and it makes annotation available for Java 1.3 or 1.4 platforms. Seasar2 makes annotation available for Java 1.3 or 1.4 platforms using this backport175.

60. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 60 If we use the eclipse backport175 plugin, we can check the syntax.

61. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 61 Also if we use the plugin, unlike the XDoclet, we don't need to do anything after the compilation. That's because the annotation information is automatically embedded in the class file after the compilation.

62. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 62 /** * @…Binding("hoge2") */ public void setHoge(Hoge hoge) { this.hoge = hoge; } Except for using the Javadoc comment, it is similar to the annotation of Java5. In this way, users of Java1.4 can accept the advantage of annotation.

63. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 63 When we use "Convention over Configuration", we rarely need to write configuration data. Isn't that wonderful? However you might feel a little worried, because you don't know how to configure it.

64. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 64 In the future, the function which writes the information to be set automatically in the configuration file is considered

65. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 65 When we can't use automatic binding by "Convention over Configuration", which do you think it's better to use - the configuration files or annotation?

66. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 66 If you think that the possibility to change the configuration data is high, please use the configuration file! If this is not the case, please use annotation.

67. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 67 It's very difficult to predict the possibility of changes to the configration data. In case of information depending on the environment you should use the configuration file, and in other cases you should use annotation.

68. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 68 An example of information depending on the environment is information to connect to a database. Since the probability of changing this information later is rather high, it's a wise choice to write it in the configuration file.

69. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 69 Since we cannot predict the probability of changing other information later, we assume it should not be changed, and we use annotation.

70. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 70 If you need to change the configuration data frequently, it's reason enough to change from annotation to the configuration file.

71. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 71 The technology often used together with DI is AOP. In Seasar2, we also can adapt the "Convention over Configuration" for AOP.

72. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 72 The convention in AOP is that we use the business interface. So, what do we get if we apply this convention?

73. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 73 In AOP, we call a module which realizes the crosscutting- concern "Advice".

74. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 74 In Seasar2, if we don't specify any method, all the methods of the interfaces which a class implements automatically become the targets of "Advice"

75. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 75 In most cases, this solution works well. Of cource we can also specify the method name in a regular expression.

76. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 76... aop.traceInterceptor "examples.di.impl" ".*Impl"

77. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 77... j2ee.required "examples.di.impl" ".*Impl"

78. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 78 interceptor1 interceptor2 interceptor3

79. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 79 AOP in Seasar2 is based on the AOP alliance.

80. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 80 According to "Less Configuration", DI has progressed even more. Still, EJB3 is important, too.

81. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 81 In my opinion, the three important characteristics of EJB3 are as follows: ● POJO(plain old java object) ● The reduction of configuration files due to annotation ● Standard specification

82. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 82 You can't ignore the standardized EJB3 which includes the advantages of DI.

83. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 83 If we compare EJB3 with Seasar2 from the viewpoint of EoD, Seasar2 certainly overshadows EJB3. That's because we rarely even need annotations in Seasar2.

84. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 84 Still, the charm of EJB3 is that it's a standard specification.

85. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 85 It's my principle that it's better to obey the standard specifications as much as possible. That's because it protects the user's assets. Regarding this idea, I have the following thoughts.

86. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 86 In Java5 which has a standard specification called EJB3, it's better to obey the EJB3 specification. Seasar2 also implements the EJB3 specification.

87. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 87 In Java1.4 which doesn't have the standard specification, it's better to use DI which has progressed due to "Less Configuration".

88. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 88 AOP in EJB3 doesn't supply the automatic registration of aspect, so we can combine EJB3 and AOP in Seasar2.

89. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 89 We don't need to use the weak functions just because they are standard. I don't think there are too many opportunities to use the application we developed using Seasar2 outside the Seasar2 environment. Let's focus on the real advantages.

90. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 90 EJB3 in Seasar2 can work even without the application server. JTA and connection pool implementation are supplied. There are some merits for the fact that EJB3 can stand alone.

91. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 91 If we use EJB3 in Seasar2, we can use EJB3 even in application servers that don't have EJB3 implementation, such as Tomcat

92. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 92 I think there are a lot of developers who want to use EJB3 in Tomcat. Seasar2 fulfils that dream.

93. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 93 In case we use application servers which supply JTA and connection pool implementation, such as Weblogic, we can use the supplied implementation in Seasar2.

94. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 94 In order to develop a very reliable application, it's important to enlarge the range in which we can perform the automatic tests as much as possible. In EJB3, the automatic tests have become much easier using mock objects.

95. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 95 If possible, we would like to perform the automatic tests using the real object. If we try to do this in EJB3, we need to perform the automatic tests in the application server. Even if we use the tools like "Cactus", it is quite troublesome work.

96. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 96 EJB3 in Seasar2 can work even without the application server, so we can easily perform the automatic tests using the real object.

97. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 97 In most EJB3 implementations, we need to package the developed module and then deploy it in the application server. This too is troublesome work.

98. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 98 Especially, while developing, we need to deploy many times. This is also quite troublesome work.

99. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 99 If we use EJB3 in Seasar2, we don't need to deploy, so the productivity is higher.

100. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 100 WITHOUT EJB

101. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 101 WITH EJB3

102. Copyright© 2004-2006, The Seasar Foundation and the others. All rights reserved. 102 ● www.seasar.org/en ● higa@isid.co.jp Thank you very much for attending this session! You may find the Seasar Foundation URL and my e-mail address here.