有没有人有一个好的模式可以在初始化另一个 spring bean 后初始化它?
我的系统中不断出现这种情况,我正在寻找一个好的代码/配置模式。我还没有想出一个让我开心的事情。
该系统是基于 spring 的,几乎所有的 Bean 都是延迟初始化的。有许多不同的主类使用相同的 spring 上下文。每个 bean 最终通过显式初始化一些 bean 来使用不同的 bean 子集,然后 spring 负责初始化所有依赖项。除了这一种情况外,一切都很好。
问题是我的一些 bean 使用一种模式(在 spring 配置中),其中声明了我的业务 bean,然后另一个 bean 依赖于它并提供一些外围功能。然而,其他 Bean 的天然依赖性是前者,即业务类。
下面是一个示例:
<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>
因此,上面的第二个 bean 基本上向调度程序注册了一个触发器,这将导致定期调用第一个 bean 上的方法。请记住,所有这些豆子都是懒惰的。如果没有活动的“缓存”客户端 bean,我不想创建“cacheCuller”并初始化“缓存”。我希望 spring 在需要注入依赖项时初始化“cache”(这很容易),但我也希望它随后立即初始化“cacheCuller”(这很难)。
我知道我可以将调度逻辑放入“缓存”类中,但我认为将其保留在 spring 配置中会很好。我还想让“cache”类不含特定于 spring 的代码。如果其他 bean 自然依赖于“cacheCuller”,这会很容易,但它们却不然。
同样的情况也出现在其他领域,例如向 MBeanServer 注册 Bean。我想让第二个 bean 注册业务 bean,但如果它不被用作某些其他(第三个)bean 的依赖项,我不希望它初始化业务 bean 本身。
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 second 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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我认为您正在寻找 取决于。
I think you're looking for depends-on.
也许您应该重新考虑这种方法。
您可以将应用程序上下文拆分为多个文件,并让每个主类加载所需的组合。这将使您的应用程序上下文更加模块化并且更容易理解恕我直言(例如消除您所描述的问题)。
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).