Thanks all for your comments.
I was mentionning the RollerConfig as part of the modifications for
Spring but yes, it's difficult and scary, and as Anil said, it should be
part of a larger redesign. I've run into troubles running Roller with
the current RollerConfig so it'll need at least a few tweaks to remove
the static initializer and populate properties from the ones read in
Spring. I'll find a solution that involves as few changes as possible.
Regarding the version to tackle, I'll move my things to the 4.0 trunk,
so it'll take me a little while since I haven't looked into 4.0 yet.
I'll try to keep up with Dave's easy install work once I've got a
clearer picture and have the fundamentals running (getting there).
Thanks again for the feedback,
Denis
Anil Gangolli wrote:
Denis Balazuc wrote:
The hard part in this is to actually de-wire the RollerConfig property
values used in the various manager implementations with something that
comes from the Spring configured..configuration. The rest should be
quite a breeze as the interfaces around layers are well defined.
Allen Gilliland wrote:
that part sounds scary to me, I don't know why you would need to worry
about replacing the way the RollerConfig class works.
It is because dependency injection inverts model where a component gets
its configuration values by calling RollerConfig.getProperty(). Instead
the components expect to have their configuration properties set via
constructors or via setters.
This isn't so much a consequence of Spring or Guice as how deeply we
adopt the dependency injection model.
My feeling is that doing this properly really will involve some
fundamental rearchitecture. The reason I'd not just go off and do this
on a branch is that I'm likely to be working at cross-purposes with Dave
on the fundamental choices there, which are not necessarily specific to
Guice or Spring.
I'll be happy if we adopt a clean component model and dependency
injection; happier if it is Spring-based.
--a
