Red de conocimiento informático - Conocimiento sistemático - Prueba de código fuente webmvc

Prueba de código fuente webmvc

Recientemente, los miembros del equipo modificaron las dependencias públicas de algunos microservicios. En una de las dependencias, necesitamos realizar algunas personalizaciones en el contenedor de flujo utilizado por nuestros microservicios, por lo que agregamos la dependencia del contenedor web bajo flujo. Sin embargo, en términos generales, esta dependencia del marco subyacente debe tener en cuenta si el contenedor web utilizado actualmente para este proyecto está subactual. Este compañero de clase escribió @conditional:

Sin embargo, el alcance agregado de la dependencia undetow no está configurado como proporcionado, lo que resulta en que mientras se agregue esta dependencia, se agregará la dependencia Undertow. Sucede que la puerta de enlace también usa esta dependencia y nuestra puerta de enlace usa Spring-Cloud-Gateway. Esto resultó en que el contenedor web Reactive de Netty de Spring-Cloud-Gateway fuera reemplazado por el contenedor web Reactive de Undertow, lo que resultó en una serie de problemas de incompatibilidad con Spring-Cloud-Gateway.

Sabemos que la capa inferior de Spring-Cloud-Gateway en realidad se basa en Spring Boot. Primero, echemos un vistazo a los principios de selección para los cuales se inicializa el contenedor web Spring Boot: Primero, el primer paso es determinar qué WebApplicationType se basa en si la clase existe:

tipo de aplicación web

Se puede ver en el código fuente que cuando hay WEBFLUX_INDICATOR_CLASS pero no WEBMVC_INDICATOR_CLASS y JERSEY_INDICATOR_CLASS, se considera un entorno reactivo. Si todas las clases_indicadores_SERVLET se consideran entornos de servlet. De hecho, también se puede ver que si se introducen spring-web y spring-webflux, en realidad es un entorno SERVLET. Si nada de lo anterior es cierto, entonces es un entorno sin contenedor web. En Spring-Cloud-Gateway, es un entorno reactivo.

Si es un entorno reactivo, se creará un contenedor web utilizando los beans de implementación de la organización. spring framework.web.reactive.serverfactory. Actualmente hay cuatro implementaciones (Spring-boot 2.7.x):

Cuál se usará realmente para ver qué Bean se registrará en ApplicationContext:

Configuración de fábrica del servidor web reactivo

p>

Como se puede ver en el código original, cada configuración tiene @ ConditionalonMissingBean (ReactiveWebServiceFactory. class) y condiciones para determinar si existe una clase correspondiente al contenedor, como @ ConditionalonClass ({Undertow. clase}). @configuration (métodos proxybean = false) es desactivar el proxy entre beans en esta configuración para acelerar la carga.

Debido a que cada configuración tiene @ConditionalonMissingBean (ReactiveWebServerFactory.Class), en realidad se garantiza que incluso si se cumplen las condiciones de múltiples configuraciones, al final solo habrá una ReactiveWebServerFactory.

Entonces, cuando se cumplen varias condiciones, ¿cuál debería cargarse primero? Depende del código fuente aquí:

configuración automática de fábrica del servidor web reactivo

Se puede ver que se importa en el orden de EmbeddedTomcat, EmbeddedJetty, EmbeddedUndertow y Embedded Dnetty, también Eso es decir, siempre que se agregue cualquier contenedor web (como Undertow) a sus dependencias, eventualmente se creará un contenedor asincrónico basado en ese contenedor web, no basado en netty.

En primer lugar, el documento oficial de Spring Cloud Gateway dice:

Es decir, Spring Cloud Gateway solo se puede ejecutar en el entorno Netty. ¿Por qué es esto? Durante el diseño se partió del supuesto de que el contenedor sólo podía ser reticulado. Al desarrollar varios filtros integrados y complementos de filtro de Spring Cloud Gateway, una gran cantidad de código actualmente supone que es Netty, como la clase de herramienta ServerWebExchangeUtils utilizada para almacenar en caché el filtro principal:

ServerWebExchangeUtils

Se puede ver en el código fuente que el código piensa directamente que BufferFactory en la respuesta es NettyDataBufferFactory, y en el caso de otros contenedores web, actualmente debería ser DefaultDataBufferFactory, por lo que habrá excepciones. Sin embargo, en versiones posteriores a la v3.0.5, este fuerte cambio se ha solucionado. Referencia: /Spring-Cloud/Spring-Cloud-Gateway/Commit/68dc 355119e 057 af 1e4f 664 c 814c 5.

Esto realmente allana el camino para la compatibilidad con todos los contenedores web. Entonces, ¿existe algún plan para ser compatible con todos los contenedores web? Se ha planificado y todavía se está haciendo. Se ha realizado durante casi cuatro años y debería realizarse pronto, lo que significa que todas las pruebas unitarias deben volver a ejecutarse o incluso rediseñarse. Puede seguir este problema: Admite la ejecución de puerta de enlace con otros contenedores de reacción basados ​​en netty #145.

Ver el progreso de la compatibilidad.

上篇: Pregunte por qué la experiencia del usuario del software libre es malaLa experiencia del usuario del software libre ha mejorado mucho en los últimos años, pero la calidad general aún no es comparable a la del software propietario. La mayor parte del software libre está plagado de problemas de diseño, redacción y publicación, lo que da como resultado su mala calidad y una mala experiencia de usuario. Faltan incentivos para que los desarrolladores de software libre participen en proyectos, principalmente de forma voluntaria. No es su trabajo desarrollar software libre y su remuneración e ingresos no están vinculados a las perspectivas de mercado del software. Por tanto, factores como el número de usuarios del software y la satisfacción no afectarán directamente en gran medida a sus intereses. Además, debido al código abierto y la distribución gratuita del software gratuito, no es conveniente calcular el número de usuarios u otros indicadores cuantitativos. En este caso, los desarrolladores inician un proyecto basándose en sus propios intereses o necesidades, y cuando pierden el interés o las necesidades ya no existen, el proyecto muere si nadie se hace cargo. Por ejemplo, el proyecto Elementary, que goza de gran reputación entre los usuarios de Linux, inicialmente tenía grandes esperanzas en el administrador de archivos Marlin. Implementa muchas características distintivas y tiene una atención exquisita al detalle. Pero después de que el autor abandonó el proyecto porque "perdió interés en el desarrollo del administrador de archivos", el proyecto Marin nunca continuó. El software propietario, por otro lado, es responsable del desarrollo del software, y sus ingresos y beneficios están directamente relacionados con las perspectivas y el desempeño del software en el mercado. Una buena experiencia de usuario es la base para un buen desempeño del mercado, y tratar las actividades de desarrollo como un trabajo también garantizará una inversión de tiempo más regular. En este caso, los desarrolladores tienen una motivación más realista y fuerte para mejorar la experiencia del usuario del software. La solución utiliza indicadores cuantitativos claros para medir el trabajo de los desarrolladores y el desempeño del mercado de software, brindando a los desarrolladores beneficios económicos y retornos espirituales más directos. De hecho, los proyectos de software libre más conocidos, como Firefox y OpenOffice.org, tienen las bases de usuarios más grandes, se ejecutan con personal de tiempo completo en su núcleo y operan de forma estándar y estandarizada, como los proyectos de empresa. Problemas débiles de planificación y diseño de productos Las empresas de software propietario exitosas y los equipos pequeños estarán formados al menos por personal de producto, diseñadores y programadores. En los proyectos de software libre, los programadores suelen ocupar una posición abrumadora. En muchos casos, a menudo no hay personal de producto ni diseñadores en el proyecto, o los programadores deciden la dirección y el diseño del producto ellos mismos. Muchos problemas con la experiencia del usuario del software libre se deben a errores de planificación del producto y a un mal diseño. Una buena planificación del producto, un diseño de alta calidad y un código eficiente también desempeñan un papel importante en el proceso de desarrollo de software. Sin embargo, por diversas razones, los proyectos de software libre suelen contar con muchos programadores voluntarios que contribuyen con código, pero pocos diseñadores voluntarios que contribuyen con diseños, y las sugerencias para la planificación de productos a menudo se ignoran. Este defecto da lugar a muchos aspectos insatisfactorios del software libre en términos de estilo general, diseño de interfaz, detalles de uso, etc., lo que afecta gravemente a la experiencia del usuario. Muchas veces, los diseñadores se encuentran en una posición débil en los proyectos de software libre, y los programadores tienen más voz y, como gerentes de producto, deciden la dirección del producto. En muchos proyectos, si los usuarios detectan errores de uso, los programadores los solucionarán rápidamente, pero si los usuarios hacen sugerencias sobre su diseño, apariencia o detalles del producto, a menudo son ignoradas. Los programadores tienden a decidir ellos mismos las cuestiones de diseño del producto. Si los programadores no están de acuerdo, el proyecto se divide y cada parte implementa sus propias ideas. En los sistemas de escritorio Linux, la debilidad de la planificación y el diseño de productos también se refleja en la falta de un estilo unificado entre las aplicaciones. Los proyectos de software libre tienden a trabajar en silos, resolviendo sus propios problemas de interfaz y diseño, pero carecen de pautas unificadas para la interacción persona-computadora. Por ejemplo, en la revisión detallada anterior de Ubuntu 12.04 se mencionó que hay cuatro estilos diferentes de programas de uso común en Ubuntu 12.04, y esas inconsistencias abundan. La solución fomenta el conocimiento del producto y valora el papel de los diseñadores. Realice una planificación eficaz del producto antes de codificar para animar a más diseñadores a unirse a proyectos de software libre. Los desarrolladores deben darse cuenta de que un buen producto requiere una planificación integral, que se logra conjuntamente entre programadores y diseñadores, y deben prestar suficiente atención a las opiniones de los diseñadores. Además, cuando el software libre se organiza en un sistema, debe seguir los principios de diseño unificado de la interfaz de interacción persona-computadora. Ofrezca a los usuarios una impresión visual y operativa unificada de todo el sistema. 下篇: Puntos adicionales por las características de selección de armas de Rogue WVW, PVP y PVE

Artículos populares