En este pequeño artículo intentaré explicar por qué creé esta biblioteca. ¿Y cómo se implementa?

¿Por qué creé esta biblioteca?

Trabajé con el marco Java EE en muchos proyectos y en la mayoría de ellos no había limitación en los recursos disponibles para ejecutar la aplicación, pero en algunos casos raros teníamos recursos limitados, especialmente la memoria para implementar la aplicación en un servicio de implementación. , por lo que cuando la aplicación excede el límite, el servicio de implementación ralentizará la aplicación al principio y luego, si continúa, el servicio la cerrará. Estábamos usando el marco Spring heredado sin siquiera arrancar Spring, intentamos usar una biblioteca diferente pero la diferencia era mínima y sin valor, y aquí es donde comenzó la idea de crear una alternativa Spring liviana que se centre en reducir el consumo de memoria tanto como sea posible. .

solo tenía dos objetivos en mente cuando comencé a diseñar la biblioteca:
1 - reducir el consumo de memoria tanto como sea posible
2: intente utilizar la API Java EE existente tanto como sea posible para facilitar la transición a la biblioteca desde el punto de vista del aprendizaje y desde la complejidad de la transición en sí.
y con estos 2 objetivos logré reducir la huella de memoria de una de mis aplicaciones alrededor del 40% y hacer la transición fácil y rápida ya que es similar a las soluciones existentes.

¿Cómo creé esta biblioteca?

Aquí tienes el repositorio de GitHub para que puedas comprobar el código mientras lo lees.

La biblioteca en su conjunto tiene muchas partes (captura de pantalla a continuación), la mayor parte de la implementación en el módulo principal que también se divide en tres tipos de módulos independientes: Core, JPA, Web. Los módulos de la aplicación son principalmente para la integración, el módulo de complemento es un complemento de Maven para ayudar a crear los archivos necesarios dentro del archivo del paquete para que la biblioteca funcione correctamente

Módulo principal

Entonces comenzaremos con el módulo principal que, como su nombre indica, contiene la funcionalidad principal de la biblioteca, que es la inyección de dependencia o la inversión de control.
Para lograr esta funcionalidad, primero se comienza escaneando la ruta de clase de la aplicación durante la fase de compilación para todas las clases anotadas que la biblioteca debe administrar para crear definiciones de componentes para las clases anotadas.

La definición del componente contiene básicamente toda la información que necesitaremos para crear una instancia de un objeto de esta clase más adelante, como la información del constructor, si hay algunos definidores con anotación de inyección (solo se admiten la inyección de constructor y definidor) si la clase tiene alguna interfaz o extender alguna otra clase, tendremos toda la información que necesitamos para crear un objeto a partir de esta clase (captura de pantalla a continuación).
Y luego, después de escanear todas las anotaciones de la ruta de clases y crear todas las definiciones de componentes que necesitamos, las almacenaremos en la ruta de clases como un archivo JSON.

La segunda y principal funcionalidad del módulo principal es la inyección de dependencia y la inversión de control que se basa en el patrón de diseño de fábrica, por lo que tenemos la interfaz ApplicationContext que en sí misma extiende ComponentFactory interfaz y el método principal de esta interfaz es el método getComponent que devolverá el objeto a partir del nombre del componente.

Como puede ver en la captura de pantalla anterior primero, intentamos verificar si el componente existe en los componentes Singleton ya inicializados; si no es así, comenzamos obteniendo la definición del componente del archivo JSON y luego iniciamos el ciclo while para obtenga todas las dependencias del componente antes de pasar la definición del componente y sus dependencias al ensamblador del componente para obtener un objeto completo listo para ser inyectado.

módulo APP

La implementación del módulo JPA es muy similar a Spring Data JPA pero muy mínima, la razón es muy similar porque usé Spring Data en muchos proyectos y lo encontré fácil de usar y, como dije antes, quería la transición al La biblioteca sea fluida y requiera menos trabajo tanto como sea posible, por lo que implementar mi propia versión de datos mini Spring fue la mejor opción.

La implementación se realiza en torno a la interfaz JpaRepository, que contiene las operaciones más comunes para la base de datos, como guardar, eliminar y buscar todo... y para utilizar el módulo JPA necesita ampliar esta interfaz y proporcionar la entidad que esta interfaz debe administrar y es id, luego de extender la interfaz y anotar con la anotación del Repositorio, puede definir sus métodos y anotarlos con la anotación de Consulta y proporcionar la consulta JPQL, y luego la biblioteca en la fase de compilación creará una clase completamente funcional que implementará esta interfaz.

La biblioteca también administrará la parte transaccional de la aplicación, por lo que toda la interfaz del repositorio y cualquier clase anotada con transaccional será administrada por la biblioteca desde el punto de vista de la transacción. por lo tanto, para cualquier componente transaccional, la biblioteca creará un proxy para administrar la transacción en función de la anotación Transaccional y también administrará el ciclo de vida del administrador de la entidad.

módulo web

El modelo web es responsable de administrar toda la parte web de la aplicación y por diseño es un módulo independiente, lo que significa que se puede usar independientemente del resto de los módulos de la biblioteca, como de costumbre es muy similar en uso a algunos Biblioteca Java EE familiar como Spring web o Jax-rs.

La implementación se basa en anotaciones, tiene clases anotadas con la anotación Controlador y dentro de este controlador encontrará un método anotado con PathMapping y estos métodos manejarán una ruta específica o una ruta específica. solicitud basada en algunos criterios como el tipo de solicitud, el tipo de contenido...

Desde fuera se verá muy similar a la otra biblioteca, pero desde dentro es diferente porque la biblioteca cambiará estas clases Controller en tiempo de ejecución para que todas extiendan el BaseHttpServlet , que también extiende el HttpServlet y funcionará como un servlet normal.

Como puede ver en la captura de pantalla anterior, primero inicializamos el componente en el método init para inyectar todas las dependencias usando WebApplicationContext, y luego manejaremos todas las solicitudes. Llegando a este controlador usando el método handleRequest, con este enfoque usaremos la API de servlet existente para administrar los controladores, esto ayudará a mantener baja la huella de memoria y también reducirá la sobrecarga ya que la biblioteca actúa como un complemento. para complementar el trabajo de la API de servlet.

Primero, intentamos asignar la solicitud al método correcto y después de eso, intentamos inyectar toda la información solicitada dentro del método obteniendo la información ya sea del contexto o del HttpServletRequest como la solicitud. parámetro o encabezados o variable de ruta o el cuerpo de la solicitud...

Convertimos toda esta información y luego la inyectamos como parámetro al método cuando se solicita y luego ejecutamos el método y convertimos el resultado o el resultado basado en PathMapping produce o tipo de contenido (por por defecto es aplicación/Json) y luego escribimos el contenido en HttpServletResponse.

Por último, si algo sale mal en el proceso y se genera un error, detectamos este error o la excepción e intentamos manejarlo según el tipo de excepción, tenemos un controlador de excepciones para manejar diferentes tipos de excepción y el El usuario también puede proporcionar más controladores para manejar cualquier excepción de la forma que desee.

Complemento Maven

La última e importante parte es el complemento maven que creará todos los archivos necesarios para que la aplicación funcione correctamente y también para construir el paquete jar o war.
Primero, el complemento escaneará la ruta de clase y las dependencias para buscar archivos definiciones-de-componentes-json, a partir de estos archivos generará:
lazy-application.json: contiene todos los componentes y sus dependencias para la aplicación

lazy-application.properties: contiene la lista de controladores y entidades, por lo que no necesitamos escanear la ruta de clase en tiempo de ejecución.
y por último, si el embalaje es un frasco, obtendremos la clase principal.

y por último construimos el archivo del paquete que contendrá el código de la aplicación con sus dependencias y los archivos que generamos en el paso anterior.

Intenté no profundizar en detalles para que los artículos fueran breves y no tan complicados de entender. Por supuesto, el código está disponible en GitHub para que puedas jugar con él también. Si tienes preguntas, déjalas a continuación y lo intentaré. para responderlas.