Re: [Springframework-developer] BeanFactory changes

[Tony F. <ton...@ya...>]

I like the changes you've made.  Removal of support for the old way is also fine with me.
BTW - I expect to have the ErrorCoded changes ready for Thurs.  The changes will not include anything for Exceptions, and msg resolution only occurs from the Context's MessageSource (as you and Juergen proposed).
 Rod Johnson <rod...@in...> wrote:Guys,

I've just checked in the following changes to the BeanFactory:

Instead of the "custom bean definition" support used so far, which I was
never entirely happy with, I've implemented a simpler and more elegant
approach to introducing an additional step of indirection if necessary in
creating a bean.

If a bean implements the new com.interface21.beans.factory.FactoryBean
interface, it is automatically considered a factory and used to create
beans.

This can be used to replace the current way of returning EJB references, and
also for the forthcoming AOP support. (The present mechanism could not
easily support the kind of thing I wanted for AOP.)

It's used as follows--there are no longer any special XML tags, and support
is no longer limited to XML bean definitions:

class="com.interface21.beans.factory.DummyFactory">

false



It's possible to specify "pass-through" properties, which will be applied to
the new instance after it has been returned by the factory. In general, the
factory can configure the managed instances any way it likes, but pass
through support is useful for some things, and is included in the "custom
definition" mechanism.

class="com.interface21.beans.factory.DummyFactory">

true



name=passThrough




The propertyValues are converted from a string using a new property editor.

It's also possible to "dereference" a factory bean, to programmatically
configure the factory. For example,

DummyFactory df = (DummyFactory) beanFactory.getBean("&prototypeFactory");

This is also something that I want for the AOP stuff, but I think it's
useful in general. An exception is thrown if the named bean isn't a factory
bean. I think I must have chosen the syntax because I was feeling nostalgic
about programming in C after chatting with some friends yesterday!

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

This will have the disadvantage of making some of the text in the book out
of date (which I don't much like in general), but I think it's worthwhile. I
don't like having more than one way of doing something: it makes source code
hard to maintain and confuses users.

As Juergen and others have said, I think we should be ready to deprecate and
prune, especially in the early stages. Otherwise it's just too easy to end
up with a bloated mess that's unpleasant to work on and doesn't give users
clear direction.

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

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

I'm about to start updating the book's sample application to use Spring, so
that it can be our first sample app. I'm looking forward to trying the new
JDBC stuff in anger.

Should we put samples apps and non-trivial examples in their own modules in
CVS?

Regards,
Rod



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer