Denis Balazuc wrote:
Hi all
Allen Gilliland wrote:
>Using Spring DI has been discussed on
> this list numerous times in the past and it has always ended the same
> way, without any actual code, so I'm sorry to say it but unless one of
> the Spring fans steps up to the plate and offers some real code then
> there is really only one option to vote for.
This sounds like I a challenge I'm ready to take up since I've just
started something like this :-)
cool.
I am working on a Spring demo of 3.1 with I hope not too much XML
headaches. I'm pretty happy with the results at the moment with the few
changes I've made and can forsee a few nice things that can now be done
easily (such as using interceptors on strategic places, transaction
management or EJB-fication). I'm also in the hope that it'll allow to
fill some of the requirements about the "easy installation" proposal
regarding property management and JNDI based resources.
I'll try to knock up something that is runnable based on the 3.1 branch.
It may take a little while to finish off (a few days probably), but
here's the overall idea:
-- Regroup the RollerImpl / HibernateRollerImpl managers in RollerImpl
for injection of the managers. Only the strategy in the
HibernateRollerImpl remains, which also allows for injecting the
hibernate session later.
-- RollerFactory is as usual the main entry point in Roller and is the
one responsible for getting the RollerImpl Spring bean (which replaces
instanciating RollerImpl in the getInstance() method).
-- Roller property files are loaded from Spring property loaders and
populate the datasource, hibernate config and other things with the
loaded values. Those properties can be overriden in various ways.
-- XXXManager(s) are declared as Spring beans. This makes the managers
implementations swappable at will. This is particularly nice when
experimenting with various Hibernate implementations and introduce
another DAO layer. It also allows to add a transaction manager around
some specific areas, and easily set interceptors in places.
-- Inject the Mail Session and Data source in a way that it can
decoupled from the web container and allow other configurable options
such as JNDI lookup, plain JDBC datasource, built-in mail session, etc.
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.
that part sounds scary to me, I don't know why you would need to worry
about replacing the way the RollerConfig class works.
Any comment or suggestions are much welcomed.
ideally you would do this work against the trunk since that is the
working base of the code. technically the 3.1 branch and trunk should
be relatively in sync, but that's not guaranteed and so it's possible
that the work you do wouldn't necessarily be easy to adapt into the
current trunk :/
you should also keep tuned to what Dave has planned for his installation
simplifications since some of the things you may propose won't
necessarily need to be done.
looking forward to seeing this.
-- Allen
Cheers
Denis Balazuc
Allen Gilliland wrote:
It doesn't surprise me that there are more voices advocating Spring
simply because it's a more prevalent technology and more people are
familiar with it. I don't have any really strong opinions in the
Spring vs. Guice debate, I think that both can fit the need just
fine. I have tried to be a fan of Spring but like Dave I just haven't
felt any real appeal from the times I've worked with it. I don't
think it's particularly hard, it's just never really felt 'right' to
me, and I'm sorry but those xml config files really suck. I
understand that they are powerful, but IMO they are a PITA to read and
deal with.
I also want to echo the subtle comment which Dave made about seeing a
prototype of a Roller backend wired via Spring. The fact is that it's
easy to prefer Spring over Guice in a discussion, but until someone
puts up some code to actually provide a functional Spring backend then
this discussion is somewhat academic. Using Spring DI has been
discussed on this list numerous times in the past and it has always
ended the same way, without any actual code, so I'm sorry to say it
but unless one of the Spring fans steps up to the plate and offers
some real code then there is really only one option to vote for.
-- Allen
