Cómo detectar y solucionar un problema de inyección de dependencia de Guice utilizando Sensei

Publicado el 25 de enero de 2021
por Alan Richardson
ESTUDIO DE CASO

Cómo detectar y solucionar un problema de inyección de dependencia de Guice utilizando Sensei

Publicado el 25 de enero de 2021
por Alan Richardson
Ver recurso
Ver recurso

El propio proyecto Sensei tiene su propio conjunto de recetas que se han ido construyendo con el tiempo. Esta entrada del blog es un ejemplo de uno de los escenarios para los que el equipo de Sensei construyó una receta. Una configuración errónea de Guice, que llevó a que se reportara una NullPointerException en tiempo de ejecución durante las pruebas.

Esto se puede generalizar a muchos escenarios de Inyección de Dependencia donde el código es sintácticamente correcto, pero debido a que la configuración del cableado era incorrecta, se cuela un error.

Esto suele ocurrir cuando estamos aprendiendo la tecnología, y seguimos cometiendo el simple error de olvidarnos de cablear las cosas. Pero esto también le ocurre a los profesionales con experiencia porque, bueno... todos cometemos errores, y puede que no tengamos Unit Tests para cubrir todo.

 

Excepciones en tiempo de ejecución por cableado incorrecto de inyección de dependencia

El código siguiente falla en tiempo de ejecución con una NullPointerException.

injector = Guice.createInjector(new SystemOutModule());
CountReporter reporter = injector.getInstance(CountReporter.class);
String [] lines5 = {"1: line", "2: line", "3: line", "4: line", "5: line"};
reporter.reportThisMany(Arrays.asList(lines5));
Assertions.assertEquals(5, reporter.getCount());


El código es sintácticamente correcto, pero falla porque hemos omitido una requestStaticInjection en nuestra configuración de SystemOutModule.

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
    }
}


Cuando intentamos utilizar el reportero, creado con el Injector, no se instancian completamente y recibimos una NullPointerException cuando llamamos a reportThisMany.

Puede que se nos haya pasado en la revisión del código, o que no hayamos hecho pruebas unitarias que activen la inyección de dependencias, y se nos haya escapado en la compilación.

Señales de advertencia

En este caso, hay una señal de advertencia, el CountReporter tiene un campo estático anotado con @Inject pero... la propia clase CountReporter es paquete privado.

En una base de código complicada, esto podría ser una señal de advertencia de que el código es incorrecto porque la clase del módulo que configura los enlaces debe estar en el mismo paquete para que esto funcione.

class CountReporter {
    @Inject
    private static ILineReporter reporter;


Otro error que cometimos, y que podríamos haber detectado en una revisión de código, es que nos olvidamos de vincular realmente los campos en el método SystemOutModule configure.

binder().requestStaticInjection(CountReporter.class);


Si hubiéramos escrito el código de requestStaticInjection entonces el Error de Sintaxis generado al intentar usar el CountReporter nos habría alertado del simple error.

> 'reporters.CountReporter' no es público en 'reporters'. No se puede acceder desde fuera del paquete

Lamentablemente. Nos olvidamos y no había señales de advertencia sintáctica en el código.

¿Cómo puede ayudar Sensei ?

Probablemente no usaríamos Sensei para recoger el requestStaticInjection que falta, ya que todo nuestro cableado de configuración de Guice necesitaría usar ese método, y no podemos garantizar que todo el cableado vaya a ser tan simple como este caso de uso.

Podríamos escribir una regla en Sensei para buscar algunas señales de advertencia de que nuestro código no está a la altura.

En este caso eso significaría:

  • Encontrar cualquier clase con campos anotados @Inject
  • Donde las clases no son públicas.

Lo anterior fue la señal de advertencia de que era poco probable que estuvieran conectados.

Al crear una receta, entonces tendremos una señal de alerta temprana, durante la codificación, y reduciremos la dependencia de nuestros pull requests o de la resolución de nuestra deuda tecnológica para permitirnos añadir Unit Tests.

¿Cómo crear una receta?

La tarea que quiero completar es:

  • Crear una receta que coincida con los campos anotados con @Inject que están en clases privadas protegidas

Eso debería darnos suficiente aviso para identificar cualquier módulo que lo utilice y añadir el código de cableado que falta.

En mi clase CountReporter, usaré Alt+Enter para crear una nueva receta y empezaré desde cero

Le pondré un nombre y añadiré una descripción:

Nombre: Guice: Campo inyectado no público
Descripción: Si el campo inyectado no es público el código podría no estar conectado
Nivel: Advertencia


La búsqueda que escribo busca una clase con un campo anotado como Inject, pero que no ha sido delimitado como público.

búsqueda:
campo:
con:
anotación:
tipo: "com.google.inject.Inject"
en:
clase:
sin:
modificador: "public"

Fijar

El QuickFix de la receta modificará la clase inyectada cambiando el ámbito. Pero ese no es el único código que tengo que cambiar.

availableFixes:

- nombre: "Cambiar la clase a pública. Recuerda solicitar también la inyección en esta clase"
actions:
- changeModifiers:
visibility: "public"
target: "parentClass"
Sensei editar la configuración de la receta QuickFix

Cuando la receta se dispara todavía tengo que realizar un paso manual en mi código, añadiendo la línea que contiene requestStaticInjection para instanciar completamente el objeto.

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
        // instantiate via dependency injection
        binder().requestStaticInjection(CountReporter.class);
    }
}


Potencialmente podría escribir otra receta para recoger esto. Probablemente no lo haría a menos que olvidar añadir la inyección estática se convirtiera en un error semi-regular que cometiera al codificar.

Resumen

Si alguna vez nos encontramos cometiendo un error con un patrón de raíz común, entonces Sensei puede ayudar a codificar el conocimiento en torno a la detección y corrección del problema, y entonces, con suerte, no se deslizará a través de las revisiones de código y en la producción.

A veces, las recetas que escribimos identifican patrones heurísticos, es decir, que su coincidencia no garantiza que haya un problema, pero es probable que lo haya.

Además, las recetas y los QuickFixes que escribimos no tienen que ser totalmente exhaustivos, sino que tienen que ser lo suficientemente buenos como para ayudarnos a identificar y solucionar los problemas sin ser demasiado complicados. Porque cuando se complican en exceso se vuelven más difíciles de entender y de mantener.

---


Puede instalar Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y luego sólo busque "sensei secure code".


El código fuente y las recetas de este post se encuentran en el repositorio `sensei-blog-examples` de la cuenta de GitHub de Secure Code Warrior , en el módulo `guiceexamples`.


https://github.com/securecodewarrior/sensei-blog-examples

Más información sobre Sensei



Ver recurso
Ver recurso

Autor

Alan Richardson

¿Quieres más?

Sumérjase en nuestras últimas ideas sobre codificación segura en el blog.

Nuestra amplia biblioteca de recursos tiene como objetivo potenciar el enfoque humano de la mejora de la codificación segura.

Ver blog
¿Quieres más?

Obtenga las últimas investigaciones sobre la seguridad impulsada por los desarrolladores

Nuestra amplia biblioteca de recursos está repleta de recursos útiles, desde libros blancos hasta seminarios web, que le ayudarán a iniciarse en la codificación segura orientada a los desarrolladores. Explórela ahora.

Centro de recursos

Cómo detectar y solucionar un problema de inyección de dependencia de Guice utilizando Sensei

Publicado el 25 de enero de 2021
Por Alan Richardson

El propio proyecto Sensei tiene su propio conjunto de recetas que se han ido construyendo con el tiempo. Esta entrada del blog es un ejemplo de uno de los escenarios para los que el equipo de Sensei construyó una receta. Una configuración errónea de Guice, que llevó a que se reportara una NullPointerException en tiempo de ejecución durante las pruebas.

Esto se puede generalizar a muchos escenarios de Inyección de Dependencia donde el código es sintácticamente correcto, pero debido a que la configuración del cableado era incorrecta, se cuela un error.

Esto suele ocurrir cuando estamos aprendiendo la tecnología, y seguimos cometiendo el simple error de olvidarnos de cablear las cosas. Pero esto también le ocurre a los profesionales con experiencia porque, bueno... todos cometemos errores, y puede que no tengamos Unit Tests para cubrir todo.

 

Excepciones en tiempo de ejecución por cableado incorrecto de inyección de dependencia

El código siguiente falla en tiempo de ejecución con una NullPointerException.

injector = Guice.createInjector(new SystemOutModule());
CountReporter reporter = injector.getInstance(CountReporter.class);
String [] lines5 = {"1: line", "2: line", "3: line", "4: line", "5: line"};
reporter.reportThisMany(Arrays.asList(lines5));
Assertions.assertEquals(5, reporter.getCount());


El código es sintácticamente correcto, pero falla porque hemos omitido una requestStaticInjection en nuestra configuración de SystemOutModule.

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
    }
}


Cuando intentamos utilizar el reportero, creado con el Injector, no se instancian completamente y recibimos una NullPointerException cuando llamamos a reportThisMany.

Puede que se nos haya pasado en la revisión del código, o que no hayamos hecho pruebas unitarias que activen la inyección de dependencias, y se nos haya escapado en la compilación.

Señales de advertencia

En este caso, hay una señal de advertencia, el CountReporter tiene un campo estático anotado con @Inject pero... la propia clase CountReporter es paquete privado.

En una base de código complicada, esto podría ser una señal de advertencia de que el código es incorrecto porque la clase del módulo que configura los enlaces debe estar en el mismo paquete para que esto funcione.

class CountReporter {
    @Inject
    private static ILineReporter reporter;


Otro error que cometimos, y que podríamos haber detectado en una revisión de código, es que nos olvidamos de vincular realmente los campos en el método SystemOutModule configure.

binder().requestStaticInjection(CountReporter.class);


Si hubiéramos escrito el código de requestStaticInjection entonces el Error de Sintaxis generado al intentar usar el CountReporter nos habría alertado del simple error.

> 'reporters.CountReporter' no es público en 'reporters'. No se puede acceder desde fuera del paquete

Lamentablemente. Nos olvidamos y no había señales de advertencia sintáctica en el código.

¿Cómo puede ayudar Sensei ?

Probablemente no usaríamos Sensei para recoger el requestStaticInjection que falta, ya que todo nuestro cableado de configuración de Guice necesitaría usar ese método, y no podemos garantizar que todo el cableado vaya a ser tan simple como este caso de uso.

Podríamos escribir una regla en Sensei para buscar algunas señales de advertencia de que nuestro código no está a la altura.

En este caso eso significaría:

  • Encontrar cualquier clase con campos anotados @Inject
  • Donde las clases no son públicas.

Lo anterior fue la señal de advertencia de que era poco probable que estuvieran conectados.

Al crear una receta, entonces tendremos una señal de alerta temprana, durante la codificación, y reduciremos la dependencia de nuestros pull requests o de la resolución de nuestra deuda tecnológica para permitirnos añadir Unit Tests.

¿Cómo crear una receta?

La tarea que quiero completar es:

  • Crear una receta que coincida con los campos anotados con @Inject que están en clases privadas protegidas

Eso debería darnos suficiente aviso para identificar cualquier módulo que lo utilice y añadir el código de cableado que falta.

En mi clase CountReporter, usaré Alt+Enter para crear una nueva receta y empezaré desde cero

Le pondré un nombre y añadiré una descripción:

Nombre: Guice: Campo inyectado no público
Descripción: Si el campo inyectado no es público el código podría no estar conectado
Nivel: Advertencia


La búsqueda que escribo busca una clase con un campo anotado como Inject, pero que no ha sido delimitado como público.

búsqueda:
campo:
con:
anotación:
tipo: "com.google.inject.Inject"
en:
clase:
sin:
modificador: "public"

Fijar

El QuickFix de la receta modificará la clase inyectada cambiando el ámbito. Pero ese no es el único código que tengo que cambiar.

availableFixes:

- nombre: "Cambiar la clase a pública. Recuerda solicitar también la inyección en esta clase"
actions:
- changeModifiers:
visibility: "public"
target: "parentClass"
Sensei editar la configuración de la receta QuickFix

Cuando la receta se dispara todavía tengo que realizar un paso manual en mi código, añadiendo la línea que contiene requestStaticInjection para instanciar completamente el objeto.

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
        // instantiate via dependency injection
        binder().requestStaticInjection(CountReporter.class);
    }
}


Potencialmente podría escribir otra receta para recoger esto. Probablemente no lo haría a menos que olvidar añadir la inyección estática se convirtiera en un error semi-regular que cometiera al codificar.

Resumen

Si alguna vez nos encontramos cometiendo un error con un patrón de raíz común, entonces Sensei puede ayudar a codificar el conocimiento en torno a la detección y corrección del problema, y entonces, con suerte, no se deslizará a través de las revisiones de código y en la producción.

A veces, las recetas que escribimos identifican patrones heurísticos, es decir, que su coincidencia no garantiza que haya un problema, pero es probable que lo haya.

Además, las recetas y los QuickFixes que escribimos no tienen que ser totalmente exhaustivos, sino que tienen que ser lo suficientemente buenos como para ayudarnos a identificar y solucionar los problemas sin ser demasiado complicados. Porque cuando se complican en exceso se vuelven más difíciles de entender y de mantener.

---


Puede instalar Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y luego sólo busque "sensei secure code".


El código fuente y las recetas de este post se encuentran en el repositorio `sensei-blog-examples` de la cuenta de GitHub de Secure Code Warrior , en el módulo `guiceexamples`.


https://github.com/securecodewarrior/sensei-blog-examples

Más información sobre Sensei



Nos gustaría contar con su permiso para enviarle información sobre nuestros productos y/o temas relacionados con la codificación segura. Siempre trataremos sus datos personales con el máximo cuidado y nunca los venderemos a otras empresas con fines de marketing.

Para enviar el formulario, habilite las cookies "Analytics". Siéntase libre de desactivarlas de nuevo una vez que haya terminado.