Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

192
Vistas
¿Agrupar los componentes de Spring en una biblioteca para que otros proyectos puedan elegir usar algunos de ellos?

Si tengo un conjunto de componentes Spring útiles y reutilizables, ¿cómo puedo hacer que estén disponibles como una biblioteca de modo que otros proyectos puedan usar cualquier subconjunto de esos componentes que les sea útil?

Por ejemplo, tengo 4 clases, X1 , X2 , X3 y X4 , cada una anotada con @Component (o @Service , @Controller o lo que sea) y quiero agruparlas en una biblioteca.

Luego tengo el proyecto A que solo está interesado en usar X1 y X3 y otro proyecto B que solo está interesado en usar X3 y X4 .

¿Cómo habilitan selectivamente los proyectos A y B solo los componentes que les interesan?

Estoy usando Spring Boot, así que supongo que podría anotar cada uno de mis componentes con @ConditionalOnProperty , por ejemplo, podría anotar X1 , etc. así:

 @ConditionalOnProperty("x1.enabled") @Component public class X1 {

Luego, los proyectos posteriores tendrían que agregar x1.enabled = true a su archivo application.properties si quisieran usar X1 .

¿Es esta la forma de hacer las cosas o existe algún otro enfoque estándar para agrupar componentes para su reutilización?

Puedo pensar en otros enfoques, por ejemplo:

  • Coloque cada componente en su propio paquete y luego los proyectos posteriores podrían usar @ComponentScan para escanear solo los paquetes de los componentes que querían usar.
  • Podría dejar @Component en las clases de componentes y marcarlos como abstractos y luego dejarlo en cualquier proyecto posterior para simplemente subclasificar los componentes que desean y agregar @Component a la subclase.

La primera de esas ideas suena como un truco completo, la segunda no suena tan mal, pero uno tiene que crear subclases simplemente para habilitar algo (pero al menos es bastante explícito lo que está haciendo).

Solo para tener en cuenta: estoy usando una configuración basada en anotaciones sin XML.

over 4 years ago · Santiago Trujillo
2 Respuestas
Responde la pregunta

0

La primera opción que me propusiste, para mí es una buena opción. Puede poner sus clases en diferentes paquetes y escanear los paquetes que le interesen.

Pero no te gusta la primera opción, así que te sugiero la siguiente.

Puede quitar el @componente de sus clases y definirlo como beans en la configuración (archivos xml o clases de @configuración). Al final cada proyecto configura las clases que necesita.

Luego puede inyectar esos beans en otros beans de cada proyecto.

over 4 years ago · Santiago Trujillo Denunciar

0

Para aclarar un poco de confusión al leer esta pregunta:

  • El uso de @Bean antes de un nombre de método/parámetro (en su @Configuración) creará un bean con el mismo nombre que ese método/parámetro (por defecto). Una función llamada myThing() creará un bean llamado "myThing"
  • Usar @Component antes de un nombre de clase creará un bean con el mismo nombre excepto que la primera letra está en minúsculas. Una clase llamada MyThing creará un bean llamado "myThing"

De hecho, puede usar @ComponentScan para buscar cada @Component debajo del nombre del paquete proporcionado.

Si no le gusta eso, puede crear métodos o parámetros en su @Configuración que crean instancias de cada uno de los @Componentes que desea usar.

Si la creación de sus beans es complicada, puede usar @Import para importar toda la @Configuración de su biblioteca.

over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda