Por qué renuncié a Jboss y a la comunidad de Jboss
Hasta donde yo sé, puede haber varias situaciones en las que todavía se usa jboss
a. El sistema antiguo se ejecuta en jboss, que es un proyecto heredado y nadie quiere hacerlo. moverse, ni la gente se atreve a moverse.
b. Para reducir costos, migré de weblogic o websphare a jboss
c. Todavía terco y poco considerado con los tomadores de decisiones técnicas (no he visto tanta terquedad)
d. Departamentos gubernamentales y empresas estatales engañados por el personal de ventas
(2) ¿Es jboss realmente tan malo? ?¡No!
Por supuesto que no, desde jboss5---gt; jboss6---gt; jboss7---gt; wildfly (equivalente a jboss7 y 8), estamos avanzando paso a paso, especialmente jboss7. Lo cual es completamente importante. Habiendo escrito todo sobre jboss, recuerdo que cuando salió jboss7 alpha1, ¡estaba completamente! Después de leer el código fuente de jboss7, ¡el proceso de carga y el mecanismo de carga de cada módulo de jboss7 son realmente espectaculares!
Mi opinión es que Jboss, incluido el actual wildfly, es técnicamente avanzado, incluso mejor que weblogic y webspare, pero tiene un concepto atrasado o es incorrecto.
Todos los servidores javaEE, incluidos jboss (wildfly), weblogic y websphare, tienen todas las funciones integradas en el servidor (jsf, jpa, ejb, jta, jms, jndi, jms, cache), pero la realidad es que Hay varias desventajas al usar las funciones del servidor javaee. Muchos proyectos solo usan un contenedor de servlets, pero aún así creo que es un poco innecesario implementar la aplicación en el servidor Jboss.
Lo que canto no es solo jboss sino también servidores Java EE de pila completa como weblogic y websphare. Si una aplicación simple solo necesita un contenedor de servlets pero aún está implementada en jboss, ocurrirán los siguientes problemas. :
a. jboss necesita ocupar una gran cantidad de memoria al iniciarse (jboss7 será mejor después de cargarlo por módulo), y si compra servicios en la nube, la memoria no será barata
b.jboss startup Se iniciarán muchos puertos al mismo tiempo (la limpieza de los puertos hace que la gente se sienta insatisfecha)
c. código que en servicios lógicos.
d. El rendimiento de jboss no es tan bueno como el de tomcat. El rendimiento de jboss es peor que el de tomcat. Siempre que se pueda ajustar el rendimiento de tomcat. Será mejor que jboss.
El equilibrador de carga mod_cluster proporcionado por e.jboss es inteligente pero su rendimiento no será mejor que el de nginx. No creo que jboss mod_cluster sea tan bueno como tomcat nginx
(3) Estoy disgustado con la comunidad jboss:
Las humanidades de la comunidad jboss son realmente buenas. No está mal, pero una cosa que no me gusta es el "narcisismo".
La comunidad jboss quiere usar todo lo que hay en la comunidad para poseer proyectos, y a otros proyectos de la comunidad les gusta depender de otros proyectos en el Comunidad jboss, lo sé. Querían construir un ecosistema, pero no lo hicieron con una filosofía simple.
Por ejemplo: HornetQ usa el paquete jboss-logging de forma predeterminada y genera registros, al igual que infinispan, el proyecto ovirt.org usa jboss como servidor y depende demasiado de fedora, ¿por qué usar jboss cuando puedes? usar gato?
Cambio de nombre de Jboss: cambie el nombre de jboss a wildfly. La declaración oficial es para pedirles a todos que distingan mejor la versión comunitaria de jboss y la versión empresarial. Ahora el nombre de jboss se refiere a jboss EAP de forma predeterminada y abierto. La versión fuente se llama wildfly. Creo que esta mala idea debe haber venido del personal de ventas de Red Hat, para que todos compren mejor la edición empresarial de jboss. Y cambiar el nombre de jboss community edition a wildfly es un movimiento estúpido, cada vez menos gente sabe sobre wildfly, creo que los desarrolladores son ofensivos en este punto, al menos eso creo.