Setting public fields

[eoliphant]

I need to set some public fields on a 3rd party class that does not quite meet the bean spec (no setX/getX). Is it possible to do this in Spring? More specifically, can it be done via declarative BeanFactory setup?

[irbouho]

AFAIK Spring Framework does not support this type of injection. Did you try to extend your base class and provided getters/setters then use the new class in your application?

[eoliphant]

That was next Was checking to see if there was a 'built-in' way to handle this.

Thanks

[Martin Kersten]

Also you may provide your own bean factory to adress this problem. Specify the property of your factory and simply inject it directly. This is also very easy to do. So you don't need to extend the class/modify it.

[Rod Johnson]

We could actually support "Field Injection" pretty easily in the core container. However, we don't think it's a good idea to encourage it. One of the aims of DI is to facilitate unit testing: populating an object through Setter or Constructor Injection in a JUnit test, for example. Field Injection is incompatible with that. Suddenly the container is doing magic that can't be done in plain Java (without reflection). IMO that's undesirable. DI is about the container parameterizing classes that aren't themselves reliant on magic.

I agree that there may be a case for it to handle legacy code. But if we add this feature, people will use it in other cases...

[eoliphant]

Totally concur that it's undesirable from a best practices POV, just the reality of wiring up code that's not 'yours'. Guess we need to think of ways to support but discourage it

[gpoirier]

One of the aims of DI is to facilitate unit testing: populating an object through Setter or Constructor Injection in a JUnit test, for example. Field Injection is incompatible with that. Suddenly the container is doing magic that can't be done in plain Java (without reflection). IMO that's undesirable. DI is about the container parameterizing classes that aren't themselves reliant on magic.

I think you're misreading the original post, he is asking about public field injection, such behavior can easily be reproduced in test cases without reflection. Still not currently a very good pratice though, just for different reasons, such as encapsulation. I guess the popularity of AOP could make public fields come back though, but we're not there yet.

[jominor]

I need to set some public fields on a 3rd party class that does not quite meet the bean spec (no setX/getX). Is it possible to do this in Spring? More specifically, can it be done via declarative BeanFactory setup?

Couldn't you wrap the class? Or wrap it and have the wrapper class implement the same interface?

[Rod Johnson]

Yes--I did misread the original post, which specified public fields. I like the suggestion about enabling but discouraging it. Perhaps through a config parameter that needs to be set specially to permit Field Injection.

It would be nice to have Spring support all possible kinds of injection--we already have Constructor, Setter and Method Injection. However, I would hate to see this practice become considered to be normal Spring usage.