My initial opinion is still "mixed bag", but I am definitely willing to
hear more about how you would want to integrate Spring. I still haven't
really done much with Spring, but I do see some ways in which it could
be useful to Roller.
On Sun, 2006-03-05 at 09:09, Anil Gangolli wrote:
> I've been using basic Spring dependency injection and initialization
> (BeanFactory/ApplicationContext) functionality in some projects at work
> and have really been happy with how it encourages clean modularization
> and helps me to get more pluggable reusable components while keeping
> almost all of the code completely unaware of Spring itself.
>
> I think using the dependency injection pattern would really help us
> clean up interdependencies and make Roller more pluggable and
> modifiable. Before spending time on a real proposal, I wanted to gauge
> interest in this. Note that this is separable from any inclination to
> use Spring MVC (as Sean G is trying) or other Spring features (like the
> declarative transaction management that Matt R suggested).
My personal opinion is that we can do this without Spring using a little
bit more of our own code. Of course it's nice to have the work already
done for us by Spring instead.
One question I have is are there any controls on what beans someone can
access via Spring? i.e. if I use appfuse as an example I noticed that
there is a bean defined for the Hibernate sessionFactory. is there
anything that prevents someone in the presentation layer from trying
ctx.getBean("sessionFactory")? that is one thing that I wasn't sure
about.
The nice thing about using a normal Java based hierarchy for accessing
objects is that nobody can access objects that they aren't supposed to
know about. Another example from appfuse would be the way that the app
separates out a "service" and "dao" layer, what prevents someone from
directly accessing a dao bean even though they aren't supposed to?
>
> Taking this path would suggest that we use Spring's xml-based
> configuration mechanisms instead of roller.properties. It's possible
> (as Matt has done for some of the Acegi-related properties) to support
> configuration via roller.properties rather than requiring users to edit
> the xml, but I think that the approach taken by Matt for the security
> props (having code in RollerContext initialization read the roller props
> and call appropriate bean setters) would be onerous to extend to a
> large number of properties. What would probably work nicely (and be
> easy) is to have most of the Spring configuration refer where necessary
> (by property paths) to one bean representing the equivalent of
> roller.properties and configured in one xml file (or even a properties
> file if we initialize that one bean specially).
This is the other big thing that I am concerned about with Spring in
Roller. I really don't want go back to making the config more
complicated and spread out.
I'd like to see more details about the implementation before making any
final decisions though. It's probably not a big deal if the only use of
the Spring appliction context is to inject special overrides for classes
like RollerImpl, ManagerImpls, etc. Since these classes really don't
need to be modified by normal users we can just leave it up to advanced
users to know how to open up the webapp and modify the Spring
Application context to make these customizations.
The roller.properties would still serve its primary purpose, which is to
make it easy for Roller admins to easily apply settings for the things
we expect people to want to change.
>
> I think it could be entered gradually, but eventually would mean a lot
> of minor-to-moderate restructuring to really utilize the pattern,
> feeling kind-of Roller 3.0-ish.
>
> Would there be sufficient support for seeing a proposal along these
> lines? I probably won't embark on such a proposal unless there's some
> predisposition to move in this direction.
I would definitely like to see it.
-- Allen
>
> --a.
>
>
>
>
>
>
>
