This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

AnnouncementAnnouncement Module

Collapse

No announcement yet.

Problems while autowiring to from child to parent contextPage Title Module

Problems while autowiring to from child to parent context

Aug 17th, 2010, 12:50 PM

Hello everyone,

we are creating a composite application framework on the top of Spring AS "building blocks" (we do not use Flex modules but our own modular architecture).

The top-level application defines an app context and loads "modules" defined locally (into the same SWF artifact) or remotely, each of them defining a child context. The issue we are facing is that we have not been able to autowire properties of objects created from the children contexts to object instances provided by the top-level one (seems that candidates are only searched into the objectDefinitions from the children). This forces to wire collaborators from parent context using refs.

I could be wrong, but I think that the Java implementation of Spring allows autowiring from child to parent. Is it a bug, are we doing something wrong or is there particular reasons to forbid such practices ? If so, could anyone suggest some sort of approach to avoid using refs ?

Comment

sorry for late answer. Here you may find three variants of the same project :
- in the first case, the collaborator is injected using autowiring, there is a single context : works properly ;
- in the second case, the collaborator is injected autowiring, but this time there are a child and a parent context : fails to find a candidate for autowiring ;
- in the third case, there are two contexts but the collaborator is not autowired but injected using a reference : works properly.

Hope this helps,
Jef.

Comment

I'll try and have a look at your examples asap, right now I'm a bit swamped at the office but I promise I'll have a look later this week. I suspect that the issue lies with autowiring by type which doesn't take a potential parent context in account, but I'm not sure, I'll have to investigate.
Thank you for taking the time to post the examples!

Comment

the intuition about this issue is right. I created a patch for the DefaultAutowireProcessor class.

I add to use the ugly

Code:

( factory is IApplicationContext )

expression in line 428 because the IObjectFactory interface does not expose the "parent" property (it seems that it was the case but for some reason the code has been commented out at some time, see there).

Comment

I've seen that if there is no candidate found you now delegate to the aw processor associated with the parent factory, much smarter.

I've been working for years with the Java implementation, so massive thanks to the development team/community for this great AS project (and for the upcoming release). I'd be glad to contribute if needed.

Jef.

Comment

thank you for the kind words, and we are ALWAYS on the look out for more contributors. If you're serious about joining the team then get in touch with me after the version 1.0 release and we can discuss further what you can bring to the table.