Hey Jason - I've used Spring IoC with Webwork 1.3 on two projects so far. On one of the projects, I wrote an ActionFactory that used Spring IoC to load actions instead of using the regular ActionFactory that just uses the class loader. That worked very well, although I was a little disappointed with having to configure my actions in two places - once in views.properties (or actions.xml), and then again in the Spring config file where I provides resources to the actions. Still, I loved the JavaBean-style of doing IoC. It requires a little extra code, but it's just a setX method, and most IDE's can quickly generate that for you. You also get self-documentation within the javadoc's because you can see what resources can be provided to the object. You get that with the constructor approach too, but I think Rod's list at www.springframework.org that compares Pico and Spring points out some of the questions regarding the constructor approach.
Regarding your first requirement - off the top of my head, I think that's possible. I've only used the Spring code from the book, I haven't tried the official framework yet. The book code uses a BeanFactory object as the main interface for loading objects. I had a need to have parent-child relationships between some BeanFactory's, and it was a simple matter of tossing in a little code to introduce this concept, I think I added a "ParentFactoryAware" interface or something like that. The idea was that if a BeanFactory couldn't resolve an object reference, it would ask its parent to do it, but only if the BeanFactory implemented ParentFactoryAware. A note on the second rqmt - I don't know if the other IoC approaches do this, but a nice point of Spring is that when your configuration is loaded at startup time, it tries to resolve all of the component dependencies, and if anything fails, you get a very informative error, and you know immediately that something is broken. No need to worry about whether the system is configured correctly or not. I haven't gotten to look at IoC in WW2 yet, so I can't compare it to Spring, but so far, I'm buying Rod's concept that the JavaBean approach to IoC is the most flexible approach. Rob ---- On Fri, 11 Jul 2003, Jason Carreira ([EMAIL PROTECTED]) wrote: > I'm starting a list of requirements for an IoC container in Xwork. > Here's what I've got so far: > > 1) Ability to have nested component scopes (Application -> HTTP Session > -> HTTP Request -> Action Invocation) > 2) Ability to resolve component dependencies and create components with > dependencies fulfilled > 3) Ability to re-wire component dependencies separate from construction > -> needed to re-wire components after serialization / deserialization > > Picocontainer can not and will not (as far as I can discern from the > mailing list) support requirement 3, so I suggest we remove > Picocontainer and restore the previous IoC code for now, while we > examine other alternatives, such as Spring. > > Jason > -- > Jason Carreira > Technical Architect, Notiva Corp. > phone: 585.240.2793 > fax: 585.272.8118 > email: [EMAIL PROTECTED] > --- > Notiva - optimizing trade relationships (tm) > > > > ------------------------------------------------------- > 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 ------------------------------------------------------- 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
