Non-Spring-managed constructor arguments for final fields?

[larsrc]

Hi!

I am currently evaluating whether to replace our home-grown configuration system with Spring in the NetarchiveSuite system (see http://netarchive.dk/suite). My first attempt to convert a currently factory-managed object into being Spring-managed is stuck on the following:

The current object takes several arguments in the constructor that are created at run-time (i.e. not likely candidates for being Spring-managed), but also uses several settings that should be Spring-managed. Since the constructor arguments are put into final fields (and I'd really like to keep it that way), I'm looking for a way to have Spring supply *some* of my constructor arguments for injecting settings, but have the remaining arguments be given when the object is created, e.g., by getBean("myBean", arg1, arg2, ...). Some manual-reading, googling and forum searching has given me little clue on whether this is possible. Am I right to assume that Spring-managed objects must have all their constructor arguments managed by Spring, or have I missed something?

Thanks in advance,
-Lars

[Andreas Senft]

It does not exactly fit your needs, but you might have a look at this approach.

You cannot split constructor arguments here (runtime vs. configured). But at least you may specify runtime constructor arguments and you are able to do some wiring in the spring context as well.

If you find it useful, feel free to vote for it

Regards,
Andreas

[al0]

Yes, it is impossible. This topic is discussed here very regularly ;(
The problem is that getBean() method is applicable to any bean regardless of it scope. And what shall be behavior of getBean("myBean", arg1, arg2, ...) for singleton-scoped bean if you call this method twice with different arguments?

BTW, direct call to getBean() anyway is bad style, as it breaks DI principle.

Hi!

I am currently evaluating whether to replace our home-grown configuration system with Spring in the NetarchiveSuite system (see http://netarchive.dk/suite). My first attempt to convert a currently factory-managed object into being Spring-managed is stuck on the following:

The current object takes several arguments in the constructor that are created at run-time (i.e. not likely candidates for being Spring-managed), but also uses several settings that should be Spring-managed. Since the constructor arguments are put into final fields (and I'd really like to keep it that way), I'm looking for a way to have Spring supply *some* of my constructor arguments for injecting settings, but have the remaining arguments be given when the object is created, e.g., by getBean("myBean", arg1, arg2, ...). Some manual-reading, googling and forum searching has given me little clue on whether this is possible. Am I right to assume that Spring-managed objects must have all their constructor arguments managed by Spring, or have I missed something?

Thanks in advance,
-Lars

[larsrc]

Yes, it is impossible. This topic is discussed here very regularly ;(

I thought it might be, but I found nothing in the FAQ or on several different searches.

The problem is that getBean() method is applicable to any bean regardless of it scope. And what shall be behavior of getBean("myBean", arg1, arg2, ...) for singleton-scoped bean if you call this method twice with different arguments?

An error? I'd be fine with it being only applicable to some scopes. Ah, well. Thanks for the prompt answer.

-Lars

[al0]

Ok, the only scope for each it is safely applicable is "prototype".

For example, "session" scope you will hit the same issue as with "singleton" if call getBean() twice in the same session for the same bean with different constructor arguments.

And not that spring is not supposed to be used to wire domain objects and such kind of behavior is usually required for domain objects only.

Regards,
Oleksandr

I thought it might be, but I found nothing in the FAQ or on several different searches.



An error? I'd be fine with it being only applicable to some scopes. Ah, well. Thanks for the prompt answer.

-Lars

[larsrc]

And not that spring is not supposed to be used to wire domain objects and such kind of behavior is usually required for domain objects only.

Ah, I guess I was mistaken as to what Spring is intended for -- I thought we could replace our configuration files with Spring stuff and get a more organized and flexible configuration system that way. If Spring is not supposed to provide my domain objects with their configuration, then it's something else I'm looking for. Thanks for the clarification.

-Lars

[al0]

Spring is great ot gonfigurate persistense layer (e.g. DAO), services etc., but not the domain objects. But, typically, domain objects (excluding ActiveRecord type) need not to be configured this way, so it is not usually big problem.

May you elaborate slightly more (and less technically) on yours needs - probably, some solution would emerge.

Regards,
Oleksandr

Ah, I guess I was mistaken as to what Spring is intended for -- I thought we could replace our configuration files with Spring stuff and get a more organized and flexible configuration system that way. If Spring is not supposed to provide my domain objects with their configuration, then it's something else I'm looking for. Thanks for the clarification.

-Lars

[anuragpaliwal]

BTW, direct call to getBean() anyway is bad style, as it breaks DI principle.

Apology for jumping in between. I would like to know how getBean() call would break DI principle?

[al0]

Apology for jumping in between. I would like to know how getBean() call would break DI principle?

Because you pull bean from context, it is not pushed (injected) into your class.

[iwein]

Usually a getBean call is a sign that something is wrong with your configuration. Spring is there to help you take care of the plumbing and wiring, it is not meant to invade into your domain logic.

Spring is not the end of all factories. Some factories have important business to do and what you describe is a good example of that.

If you need a factory in your domain that can create parametrized domain objects this factory is probably part of your domain, and hence it is a good thing to know about it. Wire up the factory with Spring, inject it into some service and use it. This way you keep your domain logic decoupled from Spring and that is of course a good thing.

Coupling a your service to Spring by making it ACAware doesn't really save you a lot of code, it doesn't make your code more readable and it even hides the intent by replacing a explicitFactory.createParametrizedDomainObject(... ) with context.getBean(...);.