简体   繁体   English

Spring,多模块应用程序上下文,B依赖于A但看不到bean

[英]Spring, Multi module application context, B depends on A but cannot see bean

should the following application context load all bean definitions across the different *-context.xml before initializing beans? 初始化bean之前,以下应用程序上下文是否应跨不同的* -context.xml加载所有bean定义? I'm finding that one of my classes can't find a dependant bean unless i mark it as lazy-init so the bean gets a chance to load. 我发现我的一个类无法找到依赖的bean,除非我将其标记为lazy-init,这样bean才有机会加载。 However i thought that the entire context is read before initializing any beans. 但是我认为在初始化任何bean之前先读取整个上下文。

Also, This could be something to do with multiple config locations as opposed to bean imports using the <import.../> tag 另外,这可能与多个配置位置有关,而不是使用<import.../>标签<import.../> bean

My structure is as follows: 我的结构如下:

APP.ear
|-- utilJars
|   |-- A.jar
|   |-- A-API.jar
|   |-- B.jar
|   |-- B-API.jar
|   `-- CONTROL.jar
`-- WEB.war
  • A-API.jar contains a service interface called MyService A-API.jar包含一个名为MyService的服务接口
  • A.jar contains a context.xml with the MyServiceImpl bean declaration A.jar包含带有MyServiceImpl bean声明的context.xml
  • B-API.jar contains a service interface called MyOtherService B-API.jar包含一个名为MyOtherService的服务接口
  • B.jar depends on A-API.jar + B-API.jar B.jar取决于A-API.jar + B-API.jar
  • B.jar contains a context.xml with the MyOtherServiceImpl that depends on the timeService to be autowired. B.jar包含一个context.xml和MyOtherServiceImpl,该依赖项取决于要自动连线的timeService。
  • CONTROL.jar depends on all other utilJars. CONTROL.jar取决于所有其他utilJars。
  • CONTROL.jar contains a beanRefContext.xml that defines a ClassPathXmlApplicationContext with the given contstructor Args: CONTROL.jar包含一个beanRefContext.xml,它使用给定的构造函数Args定义了ClassPathXmlApplicationContext:

.

<!-- in CONTROL.jar -->
<bean id="ear.context" class="org.springframework.context.support.ClassPathXmlApplicationContext">
    <constructor-arg>
        <list>
            <value>classpath*:META-INF/**/*-context.xml</value>
        </list>
    </constructor-arg>
</bean>
  • WEB.war contains the AppInitializer that declares the parentContextKey with the value classpath:META-INF/beanRefContext.xml web.war中包含声明的AppInitializer parentContextKey与价值classpath:META-INF/beanRefContext.xml

When I start the application, I get the following message during Initialization: 启动应用程序时,在初始化期间收到以下消息:

org.springframework.beans.factory.access.BootstrapException: Unable to initialize group definition. Group resource name [classpath:META-INF/beanRefContext.xml], factory key [ear.context]; 
`-> nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ear.context' defined in class path resource [META-INF/beanRefContext.xml]: Instantiation of bean failed; 
`-> nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.springframework.context.support.ClassPathXmlApplicationContext]: Constructor threw exception; 
`-> nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'myService' is defined.

Can someone please help me understand how the configuration and instantiation of spring app contexts work so i can solve this murder? 有人可以帮我理解Spring应用程序上下文的配置和实例化如何工作,以便我可以解决此谋杀案吗?

UPDATE: documentation states: 更新: 文档指出:

When constructing an XML-based application context, a location string may use the special classpath*: prefix: 在构造基于XML的应用程序上下文时,位置字符串可以使用特殊的classpath *:前缀:

ApplicationContext ctx = new ClassPathXmlApplicationContext("classpath*:conf/appContext.xml");

This special prefix specifies that all classpath resources that match the given name must be obtained (internally, this essentially happens via a ClassLoader.getResources(...) call), and then merged to form the final application context definition. 这个特殊的前缀指定必须获取与给定名称匹配的所有类路径资源(内部,这实际上是通过ClassLoader.getResources(...)调用发生的),然后合并以形成最终的应用程序上下文定义。

Thank you for your time. 感谢您的时间。

A.jar没有A-API.jar的清单条目,因此看不到该接口。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM