Today, I would like to compare Seasar2 with Spring seriously.
Implemented OGNL, Seasar2 does not bother you in writing the Spring value tags, refference tags, and registering the PropertyEditor.
AutoBinding by types in Seasar2 focuses on the type of interfaces, and it takes glitches off. On the other hand, autorite="byType" in Spring seems to simply use matching of the type of Classes, and it can cause glitches. Therefore, byType is unrecommended. The usability of auto-binding by types can reduce not only amounts of configuration file but also mistakes.
Seasar2 has some flexibilities of file include functions, that allows you to divide and cut down configuration files on purpose. (You can see them in the dicon package of the S2JSF sample). In Spring, you can define only simple parent-child relationship, and it might cause the enlargement of the configuration file. Spring is not useful for a large-size project, but oclet solve this problem.
Seasar2 brings you to ease of implying Aspects, but Spring does not. In Spring, beans imply Aspects, but a container does not imply Aspects directly. Aspects is one of the most important key when we think of DIContainers. The inconvenience of the Aspects directly reduces the productivity.
Seasar2 have various instance management methods such as singleton, prototype, outer, request, and session. Spring offers only singleton and protptype only. Still, I heard that ThreadLocal will be supported, then the newest version might have it. Even so, it might be hard to be supported well because singleton is a name of attribute value in Spring.
You can apply DI to every Java Classes by using Seasar2's method injection (it is different from lookup-method in Spring). Spring does not have such functions, then force you to use FactoryBean depending on Spring.
In Seasar2, you can multi-define initMethod and destroyMethod. You cannot in Spring. Even thought it cannot be a problem when you make a new class, it can be when you use existing classes.
Seasar2 can apply the Aspect to the method which is called from the another method in the same instance configured different Aspect. However, Spring can apply the Aspect to only the first method.
Spring cannot use Aspects without a default constructor. Seasar2 does not have such a prerequisite.
Spring has lookup-method, but Seasar2 does not. A little ago it was planned to be supported as getter injection, but it was canceled for two reason. One is that the lookup-method makes the testing difficult, and the other is that it is thought that instances can be managed using request.
The Spring's DIContainer has the message resource management function, but Seasar2's does not have. I think that it is no need for DIContainer to have such a function.
Spring has the event management function, but Seasar2 does not. It occurs dependency on the container.
Spring can inherit the bean configuration, which Seasar2 cannot.
Spring can defines the default value of the bean configuration for each configuration file, but Seasar2 cannot.
The differences between Seasar2 and Spring are not well-known, then I just organize them this time.
![[PukiWiki]](image/seasar.png "[PukiWiki]")
oclet solve this problem.
