Hide
I fully understand that DWR is not attempting to create an IOC container, but for me, the choice for DWR is that it works nicely with Spring. There are probably more people like me that would like it that DWR is more heavily integrated with Spring. I also understand that it shouldn't interfere with other containers.
That said...
Currently DWR makes limited usage of Spring's BeanFactory functionalities. The DWR's SpringContainer is rather dumb compared to Spring's fullblown IOC functionalities. It would be fairly trivial to allow for easy configuration of multiple ScriptSessionListeners by using methods of Spring's ListableBeanFactory. It's probably possible to keep the extra functionalities contained within the SpringContainer class.
Additionally I believe it's somewhat of a hack/workaround to use the FQCN of the interface as the bean ID. For me it seemed counterintuitive.
Show
I fully understand that DWR is not attempting to create an IOC container, but for me, the choice for DWR is that it works nicely with Spring. There are probably more people like me that would like it that DWR is more heavily integrated with Spring. I also understand that it shouldn't interfere with other containers.
That said...
Currently DWR makes limited usage of Spring's BeanFactory functionalities. The DWR's SpringContainer is rather dumb compared to Spring's fullblown IOC functionalities. It would be fairly trivial to allow for easy configuration of multiple ScriptSessionListeners by using methods of Spring's ListableBeanFactory. It's probably possible to keep the extra functionalities contained within the SpringContainer class.
Additionally I believe it's somewhat of a hack/workaround to use the FQCN of the interface as the bean ID. For me it seemed counterintuitive.
Improvement
Open
Normal