2011-11-30 13 views
5

Usando el Spring-Context MANIFEST definitions, estoy tratando de hacer un component-scan para buscar paquetes para los beans con anotaciones de Spring. Mi configuración XML primavera se ve algo como esto:Spring componente-scan en OSGi no encuentra nada

<?xml version="1.0" encoding="UTF-8"?> 
<beans xmlns="http://www.springframework.org/schema/beans" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" 
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd 
     http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd 
     http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd"> 

    <!-- Scans the classpath of this application for @Components to deploy as 
     beans --> 
    <context:component-scan 
     base-package="com.some.other.module.one,com.another.module.two" /> 

    <context:annotation-config /> 
.... 

</beans> 

en el manifiesto, puedo importar los paquetes que contienen las clases con las anotaciones de la primavera. Sin embargo, cuando inspecciono el ApplicationContext, no tiene ninguno de los beans anotados en él.

Creo que esto está sucediendo porque las rutas de clases que está escaneando están en diferentes paquetes. Esos paquetes no importan directamente los paquetes con las clases que tienen anotaciones Spring en ellos. Lo que es confuso es por qué Spring no recoge el classpath del paquete principal desde el que se inició el componente-scan. Parece que está utilizando el classpath de cada paquete cuando está haciendo un escaneo de classpath. ¿Hay alguna manera de hacer que el análisis de ruta de clases use el classpath del paquete en el que comienza el análisis? .

Editar

Como dijo Danail Nachev a continuación, cuando la primavera hace una exploración ruta de clases, esto solo ocurre dentro del módulo que la ruta de clases está sucediendo en el trabajo alrededor es utilizar:

  1. Coloque sus configuraciones por módulo en un bean Spring 3 @Configuration.
  2. Utilice un archivo XML en el paquete de nivel superior que inicializa el bean @Configuration.
  3. En la parte superior de frijol nivel @Configuration utilice el @Import para importar los otros archivos de configuración.
  4. Asegúrese de Require-Bundle en su MANIFEST para asegurarse de que la configuración que está importando esté disponible.

Respuesta

7

OSGi tiene que ver con ser modular, por lo que es muy importante tener una separación clara entre los paquetes. Si Spring puede ir y unirlos en un solo ApplicationContext, no será diferente de la aplicación Spring habitual, donde todo está disponible en una sola classpath. Algo como esto.

Lo que sucede es que cada paquete recibe su propia Application Context. Estos ApplicationContexts pueden intercambiar beans utilizando OSGi Service Registry. Debe marcar frijoles como exportados e importarlos en otros ApplicationContexts, de lo contrario, no serán visibles entre sí.

Esto debería explicar por qué no se puede configurar todo con un único contexto Spring y esperar que a partir de un paquete vaya a buscar todos los beans. El contexto de Spring escanea solo un paquete único y opcionalmente puede importar/exportar beans como servicios OSGi.

interpretado desde aquí: Chapter 8. Packaging and Deploying Spring-based OSGi applications

+0

Gracias, eso es exactamente el comportamiento que se observó. Me las he arreglado para encontrar una solución alternativa sin usar un análisis de ruta de clases. –

Cuestiones relacionadas