Does anyone have a good pattern for initializing a spring bean once another one has been initialized?

I've got a situation that keeps cropping up in my system and I'm looking for a good code/config pattern. I haven't come up with one that makes me happy yet.

The system is spring-based and almost all of the beans are lazily-initialized. There are a number of different main classes that use the same spring context. Each one ends up using a different subset of the beans by explicitly initializing a few beans and then spring takes care of initializing all the dependencies. Everything works great except for this one case.

The problem is that some of my beans use a pattern (in the spring config) where my business bean is declared and then another bean depends on it and provides some peripheral functionality. However, the natural dependency of other beans is the former, being the business class.

Here's an example:

<bean id="cache">
  ...
</bean>

<bean id="cacheCuller" class="ScheduledJobBean">
  <property name="scheduler" ref="scheduler"/>
  <property name="jobDetail">
    <bean class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean">
      <property name="targetObject" ref="cache"/>
      <property name="targetMethod" value="removeExpiredEntries"/>
      <property name="concurrent" value="false"/>
    </bean>
  </property>
  <property name="repeatInterval" value="300000" />
</bean>

So, the second bean above basically registers a trigger with the scheduler that will cause a method on the first bean to be called periodically. Remember, all these beans are lazy. I don't want to create "cacheCuller" and have that initialize "cache" if there are no active "cache" client beans. I want spring to initialize "cache" when it needs to be injected into a dependency (this is easy) but I also want it to initialize "cacheCuller" immediately afterwards (this is hard).

I know that I can put the scheduling logic into the "cache" class, but I thought it would be nice to keep it in spring configuration. I'd also like to keep the "cache" class free of spring-specific code. If other beans naturally depended on "cacheCuller" this would be easy, but they don't.

The same situation comes up in other areas, like registering the beans with the MBeanServer. I'd like to have a secon开发者_运维知识库d bean register the business bean, but I don't want that to initialize the business bean itself if it's not being used as a dependency of some other (third) bean.

I think you're looking for depends-on.

There are a number of different main classes that use the same spring context. Each one ends up using a different subset of the beans by explicitly initializing a few beans and then spring takes care of initializing all the dependencies.

Maybe you should re-consider this approach.

You could split up the application context into several files, and have each main classes load the required combination thereof. That will make your application context more modular and easier to understand IMHO (e.g. eliminate the problem you've described).