Circular reference between a singleton and a factory bean

[immanuel]

I have a bean A which tries to perform an operation, and upon failure schedules a Job on a scheduler B in order to re-perform it later. I use the SchedulerFactoryBean and tried to put the bean A in the schedulerContextMap in order for it to be passed to the job, but spring refuses to do it, saying that there is a circular dependency between A and B.

I wondered if there's any way I can follow in order to solve this problem without recurring to some uglyness such as using a locator pattern in the job through the application context at runtime.

Thanks,
Davide Baroncelli.

[Juergen Hoeller]

You shouldn't need to pass the Scheduler in via SchedulerFactoryBean's "schedulerContextMap": Simply access it in your Job via the passed-in JobExecutionContext's "getScheduler()" method.

Juergen

[immanuel]

You shouldn't need to pass the Scheduler in via SchedulerFactoryBean's "schedulerContextMap": Simply access it in your Job via the passed-in JobExecutionContext's "getScheduler()" method.

Juergen

Uh, no, I didn't explain well. The scenario is:

1) A tries to execute foo
2) foo fails, so A itself schedules a job which will re-execute foo some time later
3) the job must access A in order to re-execute foo, so A has to be put in the map

So, A has a reference to the scheduler, and the scheduler must have a reference to A in order for it to be put in the map.

I have now solved the problem putting the bean name into the map instead than the bean itself, and the job locating at runtime the bean A instead of receiving it. I was just wondering if there was a "spring supported" way to do it (such as a proxy which does not resolve the bean at context creation time, but does it when a method is accessed, and can then be put into the schedulerContextMap without creating a circular reference - such as some kind of "lazy" property tag in the bean definition).

[Andreas Senft]

I was just wondering if there was a "spring supported" way to do it (such as a proxy which does not resolve the bean at context creation time, but does it when a method is accessed, and can then be put into the schedulerContextMap without creating a circular reference - such as some kind of "lazy" property tag in the bean definition).

Did you try using a TargetSource?

Regards,
Andreas

[immanuel]

I was just wondering if there was a "spring supported" way to do it (such as a proxy which does not resolve the bean at context creation time, but does it when a method is accessed, and can then be put into the schedulerContextMap without creating a circular reference - such as some kind of "lazy" property tag in the bean definition).

Did you try using a TargetSource?

Regards,
Andreas

I'm not sure this could be useful... it seems to me that a thing like the one I need is something that has some kind of support by the ApplicationContext configuration subsystem: I need a way to specify a property definition which depends on a bean which will only be resolved at runtime: target sources seem to be a core part of the AOP framework used as object resolvers, but I still need a way to express a dependency on a bean which will not be resolved when the "property" tag is read from the config.

[immanuel]

I was just wondering if there was a "spring supported" way to do it (such as a proxy which does not resolve the bean at context creation time, but does it when a method is accessed, and can then be put into the schedulerContextMap without creating a circular reference - such as some kind of "lazy" property tag in the bean definition).

Did you try using a TargetSource?

Regards,
Andreas

I'm not sure this could be useful... it seems to me that a thing like the one I need is something that has some kind of support by the ApplicationContext configuration subsystem: I need a way to specify a property definition which depends on a bean which will only be resolved at runtime: target sources seem to be a core part of the AOP framework used as object resolvers, but I still need a way to express a dependency on a bean which will not be resolved when the "property" tag is read from the config.

It seems Hivemind is entirely based on an assumption like this one: services are (always?) proxied, and the proxies resolve the service dependency at runtime when the first method is called. http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg37889.html
I imagine this kind of stuff must have been already discussed for spring too: it's the kind of issue that seems simple to put in place, but gives birth to a probably infinite amount of consequences.