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...
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?
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?
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...
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?
Thoughts? Ideas?
Jason
