Announcement Announcement Module
Collapse
No announcement yet.
Circular reference between a singleton and a factory bean Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Circular reference between a singleton and a factory bean

    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.

  • #2
    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

    Comment


    • #3
      Originally posted by 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
      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).

      Comment


      • #4
        Originally posted by 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

        Comment


        • #5
          Originally posted by Andreas Senft
          Originally posted by 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.

          Comment


          • #6
            Originally posted by immanuel
            Originally posted by Andreas Senft
            Originally posted by 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-.../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.

            Comment

            Working...
            X