Having spoken with Don Brown, I can see the benefits now of the BeanWrapper and the [Xml]BeanFactory in Spring. Creating a graph of objects from an XML file is pretty handy for certain situations. I can see the light of the joke. Objects just "Spring" into life from literal paper.
I guess the decision here will be political. "Can we just take or borrow the org.springframework.beans.* of your framework?" Hmmm.
The thing that looks attractive to me in Spring is the ability to make a graph of objects more complicated than a tree. It would be possible to do this in Digester, without necessarily even writing custom rule classes.
As for PicoContainer, if someone could just show me how you write an external configuration file that wires together objects through their constructors, I might buy it, but it just doesn't seem to match up. As soon as you had one new collaborator that you hadn't planned for, you'd have to rewrite some java code somewhere, wouldn't you?
That's another facet of Spring that appeals to me -- it's orientation towards JavaBean conventions -- but we can achieve that with homegrown processes using (or at least inspired by) Digester if we're reluctant to pile on Spring.
If Spring uses an Apache license, then politics or not we can use the code just about anyway we like, but I don't know that we need to read the Spring code to achieve the few things that seem most useful to me. I still haven't found the time to really dig into the various microkernel/IoC type frameworks yet, so I hope I'm not just blowing smoke...
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
