Mate, Great email - thoughts below: > Several people have been asking about replacing the clazz.newInstance() calls > in XWork with object factories which can be replaced, to allow integration > with Spring/Pico/etc... While I'm all for this, I think there are some issues > that need to be thought through so we can get a design that really works and > meets everyone's needs... > > 1) Lifecycle / Scope : Some object instances, like Actions, are request > scoped, and can depend on request scoped components. Some, like Interceptors, > can only depend on application scoped components. I can't think of any that > are session scoped right now...
So? :) Perhaps I'm missing something, but how does the scope really affect the use of a factory to create the object? I'd assume the default factories would just use clazz.newInstance() anyway - so the overhead is a single method call no? > 2) The internals of XWork are filled with static singletons which can be > replaced at system initialization... Should we tackle replacing these with > making all of the internal components of XWork be wired together by the object > factory at runtime? I'm not sure that's really needed - if it works it works. I would like to reduce the number of statics over time though. > 3) XWork IoC... How much do we want to put into this? Should we deprecate this > in favor of an integration with a dedicated IoC container? It's simple, it works, it's tested. Leave it IMHO? > 4) IoC container support: Do we want to create a generic Interface for these > integrations, and provide different implementations, or do we want to choose > one and make it the heart of the framework, such that it weaves together all > of the other pieces, which become components (which Actions, Interceptors, > Results, etc could depend on)? Or, do we want to do this 2+ times, defining > the dependencies and letting either Spring or Pico, etc. pull it together at > runtime? This is dependent on #2, obviously... It's very tricky to do this, because Spring and Pico operate so differently (in their optimal, recommended modes). I think there will need to be a number of 'plugin' points to make it work as people want - for example the object factories, the external reference resolver that's already there etc. > One question I had about these frameworks... Is it possible for me to define a > default configuration, and allow the users of the framework to just > selectively replace individual components, or would they have to reconfigure > the whole thing? Uhm, not sure what you mean here - could you extrapolate? Cheers, Mike PS We're a good test case for frameworks - currently JIRA 2.6 is using more and more Pico, and Confluence 1.0 is completely built with Spring IOC :) -- ATLASSIAN - http://www.atlassian.com/ Confluence - the professional J2EE wiki - tried it yet? http://www.atlassian.com/confluence/ ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
