RE: [Springframework-developer] BeanFactory changes

[<jue...@we...>]

Hi Rod, everyone,

> Instead of the "custom bean definition" support used so far,=20
> which I was never entirely happy with, I've implemented a=20
> simpler and more elegant approach to introducing an=20
> additional step of indirection if necessary in creating a bean.
>=20
> If a bean implements the new com.interface21.beans.factory.FactoryBean
> interface, it is automatically considered a factory and used=20
> to create beans.

As I've already stated previously, I consider this a welcome and =
appropriate change.

> It's also possible to "dereference" a factory bean, to=20
> programmatically configure the factory. For example,
>=20
> DummyFactory df =3D (DummyFactory)=20
> beanFactory.getBean("&prototypeFactory");

I'm not entirely sure if I endorse the syntax, but I don't really mind =
it either. Wouldn't a BeanFactory.getFactoryBean(String) method to the =
job too?

> The reason I'm writing this is so that everyone is aware of=20
> the new functionality, but also to see if everyone is happy=20
> if I delete support for the old "custom definitions "=20
> approach. (I haven't changed it so far.)

> Thus I would like to remove the old custom bean definition=20
> code before 0.8 (ie, next week), unless anyone has any objection.

I don't object, quite on the contrary. I'm not a fan of dragging along =
deprecated APIs at all.

> As I've been doing for the past few months, I've developed=20
> this test first, so test coverage should also be slightly=20
> improved. I've added a few other additional BeanFactory=20
> tests, as well.

BTW, I still owe Spring some more tests for LocaleResolver, validation =
support, and the like. Definitely forthcoming, although I'm not sure if =
I can make it for 0.8. There are still some minor API and functionality =
issues within validation and web support that I'd like to address. =
Repeat to myself: "test first", "test first", "test first"... ;-)

> I'm about to start updating the book's sample application to=20
> use Spring, so that it can be our first sample app. I'm=20
> looking forward to trying the new JDBC stuff in anger.
>
> Should we put samples apps and non-trivial examples in their=20
> own modules in CVS?

Thumbs up! I've already thought about the book's sample app and its =
current state.

Concerning CVS structure, it would definitely make sense to separate =
non-trivial examples. I'm just not sure about the most convenient way. =
How do we generate the libs for the sample apps, to allow for easy setup =
from CVS? The example apps will probably depend on the main module for =
building etc - this should be achievable with a separate module that =
references the main module's build script.

Finally, in terms of distribution: Should there be a separate examples =
download, or should they be included in the main download? Do we like to =
separate binary and source distribution (analogous to Tomcat), or offer =
a combined one (analogous to Log4J)? Do we include all the third-party =
libraries or just give respective download URLs? Or do we include all =
but specific larger ones that not everyone will need, like Velocity?

Personally, I tend to prefer a combined download for developers, =
including sources, third party libs, and Spring binaries (usable =
out-of-the-nox for both application and framework development) - =
provided that it is of reasonable size (currently just ~1500 KB, without =
Velocity). Of course, it would make sense to offer a binary-only =
download too, with just the libraries needed for application development =
(i.e. no Clover, no mock objects, etc - currently ~650 KB, again without =
Velocity). So even with generated JavaDocs, some additional docs, and an =
example app, the combined download will probably not exceed 2 MB, and =
the binary download clock in around 1 MB.

The only drawback is that users have to copy some framework and third =
party JARs to WEB-INF\lib if they want to run the example app, but this =
should be easy to document. Of course, we could go the Struts/WebWork =
way of providing preassembled WARs and EARs that duplicate all the =
libraries - but look at their distribution file sizes, ~20 MB/~17 MB for =
the zipped versions... I believe that Spring's distribution size should =
express Spring's general slimness and clearness, thus I vote for a =
"normalized" distribution.

Regards,
Juergen