Minor enhancement to ListableBeanFactory?

Probably low on the priority list but useful anyway would be to allow the getBeansOfType to filter out lazy-init='true' beans.

The following works

Code:

---

Map lookups = getApplicationContext().getBeansOfType(MyInterface.class, false, false);

---

but when I loop through the Map, I get back the semi-configured, lazy-init='true' beans that act as templates for my real MyInterface.class implementations. I don't want these returned.

getBeansOfType already takes includePrototypes and includeFactoryBeans (both booleans) as params, so could probably take an additional includeLazyInit boolean param or otherwise do something like when retrieving lists of files from the filesystem, i.e. take some sort of Filter param that can choose what beans get returned to the map.

....or is there already some simple way to do this?

Sounds like you should use the new 1.1 "abstract" attribute instead of lazy-init to define templates. This use of lazy-init was really a workaround necessary in 1.0.x but not 1.1.

Rgds
Rod

Indeed, sounds like a case for "abstract". This is exactly the reason why we added that new attribute.

"lazy-init" should now just be used for fully working bean definitions which are supposed to be initialized on demand.

Juergen

Cool,

Now our unit tests automatically pick up any newly configured Spring beans simply because the unit test loops through all objects of a certain interface.

In addition we've been thinking it wouldn't be any more difficult to have a naming convention or something for other classes of objects so that by configuring a new Spring bean, your unit tests would prompt (error) you to create a matching test/mock object.

For example, if I configure a new Controller bean called "personFinder" object that can, say, perform database searches, then maybe my unit test also expects to find a Spring bean called "personFinderInputs" that contains a list of MockHttpServletRequests. My unit tests would fail until I'd configured "personFinderInputs"

Not sure if there are any other good ways to keep the unit tests up to date with the code.

Obviously you want to write the test first if you're building the first version of some object type, but if you're churning out a bunch of similar objects you sometimes just want them tested after they've been written using as little of your effort/time as possible.