All, After reading the incredibly long thread here and the mind-numbingly long thread in pico-dev, I've come to the following conclusion:
The difference between contructors and bean properties is so small that it's impossible to argue one way or the other. Smart people will argue for one side or the other till they turn blue, and no solid facts will ever be made.
With that said, I'm making an executive decision (Matt and Jason, back me up here ;): just as we provided a simple validation framework and a simple type conversion framework in XWork, we should provide a simple IoC framework as well. For those that want to live on the wild side, they can use FormProc, commons-beanutils, and Spring (or Pico) via their own interceptors. Maybe we can even (in the future) start an xwork-components module that is separate. However, introducing a dependency on Spring OR Pico does not follow our original plan of having small dependencies, especially when providing simple support is easily doable (or IoC impl is 200 lines of code).
So what's the plan: we remove pico from xwork and put back the original,
simple, homegrown ioc stuff. That's the way we've been operating, that's the way we agreed to operate at the start, and that's the easiest way to keep flamebaits and drama out of WebWork.
+1 to bringing it back inhouse. At the same time, we can incorporate some of Spring's ideas.
M
------------------------------------------------------- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
