Así que después de una gran cantidad de excavar alrededor descubrí que la primavera es compatible con JSR-330. Esta JSR define una API simple, la especificación completa es, literalmente, solo esta API, que estandariza varias interfaces, anotaciones y comportamientos de inyección de dependencias.
A diferencia de FactoryBean
de Spring, la interfaz javax.inject.Provider
no arroja una excepción al obtener la referencia de bean. Además, aún necesitaría definir este FactoryBean en algún lugar (lea XML, o @Configuration
clase, y esto es subóptimo).
Debido a un error, en la primavera actual 3.1.1, el javax.inject.Provider no funciona. Es funciona en Spring 3.1.0.
Con el fin de utilizarlo es simple necesidad de incluir el frasco javax.inject - si utiliza experto puede:
<dependency>
<groupId>javax.inject</groupId>
<artifactId>javax.inject</artifactId>
<version>1</version>
</dependency>
primavera lo detectará, y desde ese momento puede simplemente:
@Inject
Provider<MyObject> myObjectInstance;
//...
MyObject myObjectInstance.get();
como en el ejemplo de Guice, ya que es la misma API.
A pesar de mi comentario anterior a Konstantin, Spring crea el proveedor por sí mismo. (Lo estaba probando contra Spring 3.1.1 y me encontré con este Spring Provider regression issue)
+1 Buena respuesta. –
Me temo que existen diferencias significativas entre el Proveedor <> y la Instancia <> (Espero estar equivocado). Primero: Instance implementa Iterable y esto tiene un gran impacto en cómo lo usa. P.ej. un uso regular para mí es declarar @Inject Instance xxx ... así que podré iterar a través de las instancias de cada clase que implemente la interfaz sin saber el nombre de clase. Quiero saber cómo hacer esto usando el proveedor. –
Rafael
'Instance <>' no es parte de JSR-330, y tampoco forma parte de Spring. El problema que tenía en ese momento era obtener prototipos de frijoles (que dependen de algunas variables de contexto) sin tener que detener el ApplicationContext. –