Java EE 6 frente a la pila Spring 3 [cerrado]

Estoy comenzando un nuevo proyecto ahora. Tengo que elegir tecnologías. Necesito algo ligero, así que no EJB o Seam. Por otro lado necesito JPA (Hibernate o alternativo) y JSF con IceFaces.

¿Crees que una pila de este tipo en Spring 3 implementada en Tomcat es una buena opción? ¿O una aplicación web Java EE 6 podría ser mejor? Me temo que Java EE 6 es una tecnología nueva, aún no bien documentada. Tomcat parece ser más fácil de mantener que Glassfish 3.

¿Cual es tu opinion? ¿Tienes alguna experiencia?

Necesito algo ligero, así que no EJB o Seam.

¿Le importaría explicar qué hace que los EJB sean pesados ​​desde EJB3? ¿Te das cuenta de que ya no estamos en 2004? Realmente me gustaría leer su definición de luz y sus argumentos (y actualizaré mi respuesta con mucho gusto porque estoy bastante seguro de que tendría algunas cosas sólidas que decir).

Por otro lado necesito JPA (Hibernate o alternativo) y JSF con IceFaces.

Java EE 6 Web Profile, que incluye JSF 2.0, JPA 2.0, Bean Validation, EJB 3.1 Lite, CDI, ... sería perfecto para esto y puede usar GlassFish v3 Web Profile para ejecutar una aplicación construida con Java EE 6 Web Profile .

¿Crees que tal pila en Spring 3 implementada en Tomcat es una buena opción? ¿O una aplicación web Java EE 6 podría ser mejor?

Bueno, me gusta la idea de ejecutar mi código en una plataforma no propietaria (Java EE) en lugar de en un contenedor propietario (Spring). Y creo que Java EE 6 es lo suficientemente bueno (y esto es un eufemismo, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI kick ass). Tenga en cuenta que era un escéptico de JSF pero eché un segundo vistazo y JSF 2.0 con CDI es tan diferente que ni siquiera puedo comparar. Y si no miraste CDI, déjame decirte que es genial.

Me temo que Java EE 6 es una tecnología nueva, aún no bien documentada.

Java EE me parece bastante bien documentado. Esto suena a reclamo gratuito. Y, créanme o no, me pongo a buscar la primavera está complicando, mientras que Java EE cada vez más fácil.

Tomcat parece ser más fácil de mantener que Glassfish 3.

¿Intentaste algo? ¿Enfrentó algún problema en particular? Una vez más, esto suena a reclamo gratuito.

No he usado JavaEE6.

Sin embargo, todas las versiones anteriores de JavaEE y EJB me han golpeado lo suficiente que no confiaré en él hasta que se establezca como el estándar de facto, no solo como el estándar de jure. En este momento, Spring sigue siendo el estándar de facto.

Si me engañas una vez, la culpa es tuya. Si me engañas dos veces, la culpa es mía. Engañame tres veces, EJB.

Algunos dirán que Spring es propietario. Yo diría que las implementaciones de los proveedores de las especificaciones de JavaEE han sido tan propietarias, si no más.

Recientemente pasé por una conversión importante de mover un montón de aplicaciones Java de JBoss a Weblogic. Todas las aplicaciones Spring / Hibernate se portaron sin modificaciones, porque tenían todas las bibliotecas que necesitaban integradas. Todas las aplicaciones que usaban JPA, EJB y JSF fueron un desastre para portar. Las sutiles diferencias en las interpretaciones de JPA, EJB y JSF entre los servidores de aplicaciones causaron todo tipo de errores desagradables que tardaron una eternidad en solucionarse. Incluso algo tan simple como la denominación JNDI era completamente diferente entre AppServers.

Spring es una implementación. JavaEE es una especificación. Es una diferencia enorme. Preferiría usar una especificación SI la especificación fuera 100% hermética y no diera absolutamente ningún margen de maniobra en la forma en que los proveedores implementan esa especificación. Pero la especificación JavaEE nunca ha sido eso. ¿Quizás JavaEE6 sea más hermético? No lo sé. Cuanto más pueda empaquetar en su WAR, y cuanto menos dependa de las bibliotecas de AppServer, más portátil será su aplicación y, después de todo, esa es la razón por la que uso Java y no Dot-NET.

Incluso SI la especificación fuera hermética, sería bueno poder actualizar el servidor de aplicaciones sin tener que actualizar todas mis pilas de tecnología en todas mis aplicaciones junto con él. Si quiero actualizar de JBoss 4.2 a JBoss 7.0, tengo que considerar el impacto de la versión más nueva de JSF en todas mis aplicaciones. No tengo que considerar el impacto en mis aplicaciones Spring-MVC (o Struts).

No importa. Java EE 6 es lo suficientemente bueno y debido a los perfiles que hay allí, no es "pesado", solo usará el perfil web.

Personalmente, prefiero Spring. Pero me estoy quedando sin argumentos racionales contra Java EE 6 :)

(Como me recordó un comentario, es posible que desee probar RichFaces , así como ICEfaces y / o PrimeFaces , según los componentes que necesite).

Recientemente, una de mis asignaciones de cliente involucró la evaluación de Spring Stack Vs Custom Framework stack Vs a Java EE Standards. Después de un mes de evaluación y creación de prototipos, no solo estaba contento, sino también impresionado por el conjunto de características de Java EE 6. Para cualquier nueva arquitectura de proyecto "empresarial" en 2011 y en el futuro, optaría por Java EE 6 y posibles extensiones como Seam 3 o el próximo proyecto de extensiones Apache JSR299. La arquitectura Java EE 6 está optimizada e incorpora lo mejor de muchas ideas de código abierto que han evolucionado en los últimos años.

Considere las siguientes características listas para usar: gestión de eventos, contextos y DI, interceptores, decoradores, servicios web RESTful, pruebas integradas con contenedor integrable, seguridad y muchas más.

La mayoría de mis resultados se publican en mi blog que explica los conceptos clave de Java EE 6 que pueden resultarle útiles.

Por supuesto, no existe una regla estricta y rápida para elegir un marco. Java EE 6 podría estar bien inflado para "sitios web" más simples que no requieren un estado de sesión de conversación rico. ¡También podrías elegir Grails o Play! Marco de referencia. Pero para las aplicaciones web conversacionales, no veo un argumento mejor por el que Java EE 6 no es una buena opción.

Ahora, después de un tiempo, tengo experiencia con pilas:

• Java EE 5 + Seam + GraniteDS + Flex
• Primavera 3 + Vaadin (en GWT)
• Primavera 3 + JSF 2.0 (PrimeFaces)

Mis colusiones son:

• Spring 3 es mucho más simple que Seam (casi Java EE 6) y se ejecuta en Tomcat y Jetty. (Jetty para el desarrollo con el complemento maven es una basura).
• Me encanta Flex (en realidad fui un desarrollador de Flex durante mucho tiempo, así que soy parcial) y si necesitas una interfaz rica y puedes comprar FlashBuilder, usa esto, pero usa este backend Spring + GraniteDS o BlazeDs. Si no puede comprar FlashBuilder, no pierda el tiempo.
• ¡Vaadin es genial !. El proceso de desarrollo es más simple que Flex, pero puede crear aplicaciones enriquecidas fácilmente sin problemas de HTML. No escribirás una sola línea JS. Solo necesitas algo de CSS (en Flex también lo necesitas). Entonces, si la interfaz de su aplicación se comportará como una aplicación de escritorio y no puede (o no quiere) usar Flex, use Vaadin. ¡Advertencia! Vaadin tiene una gran sobrecarga de JS para el navegador.
• Si crea una aplicación similar a un sitio web más simple, use JSF2.0 (con el backend de primavera como el anterior). Tendrás que luchar con HTML (lo odio) y crear una interfaz rica será más difícil que Vaadin (especialmente los diseños). Obtendrá HTML ligero para navegadores / compuetrs más lentos. Me gusta PrimeFaces, es fácil y está bien documentado. El segundo lugar es IceFaces
• Si crea un sitio web (NO una aplicación web) donde necesita darle vida a HTML (en lugar de crear una aplicación empresarial que se ajuste al navegador) use Wicket (si prefiere la actitud basada en componentes) o SpringMVC (si prefiere la plantilla basada en , empuje la actitud) o simplemente use Play! marco de referencia. Recuerde que crear componentes ricos basados ​​en datos será mucho más difícil, pero tendrá control sobre cada etiqueta de html (a su diseñador de HTML / gráficos le encantará)

Lea Future Of Enterprise Java ... Is Clear de Adam Bien (Java EE con / sin Spring y Vice Versa) , incluidos los comentarios para obtener ambas caras de la moneda. Elegiré Spring por varias razones y la siguiente es una de ellas (reproduciendo uno de los comentarios de la publicación)

'No estoy seguro de qué servidor Java EE 6 está hablando. Hay certificación Glassfish y TMAX JEUS. Tomará bastante tiempo (lea: años) hasta que las versiones compatibles con Java EE 6 de WebSphere, WebLogic, JBoss, etc. estén en producción y puedan usarse para aplicaciones reales. Spring 3 solo necesita Java 1.5 y J2EE 1.4, por lo que se puede usar fácilmente en casi todos los entornos '

Mi opinión se basa en algo no mencionado por otros, es decir, que el código en mi trabajo tiende a vivir durante décadas (literalmente) y, por lo tanto, el mantenimiento es muy importante para nosotros. Mantenimiento de nuestro propio código y las librerías que utilizamos. Controlamos nuestro propio código, pero es de nuestro interés que las bibliotecas que usamos sean mantenidas por otros en las décadas mencionadas o más.

Para abreviar la historia, he llegado a la conclusión de que la mejor manera de lograrlo es mediante el uso de implementaciones de código abierto de las especificaciones de Sun hasta la JVM sin procesar.

De las implementaciones de código abierto, Apache Jakarta ha demostrado que mantiene sus bibliotecas, y recientemente Sun ha trabajado mucho en la producción de implementaciones de alta calidad para Glassfish v3. En cualquier caso, también tenemos la fuente para todos los módulos, por lo que si todo lo demás falla, podemos mantenerlos nosotros mismos.

Las especificaciones de Sun suelen ser muy estrictas, lo que significa que las implementaciones que se ajustan a las especificaciones se pueden intercambiar fácilmente. Solo eche un vistazo a los contenedores de servlets.

En este caso particular, sugeriría echar un vistazo a JavaServer Faces simplemente porque es parte de Java EE 6, lo que significa que estará disponible y se mantendrá durante mucho, mucho tiempo. Luego hemos optado por aumentar con MyFaces Tomahawk, ya que brinda algunas adiciones útiles, y es un proyecto de jakarta.

No hay nada de malo con JBoss Seam u otros. Es solo que su enfoque está menos en el tema de mantenimiento que es tan importante para nosotros.

Puedo ver el uso de Spring si ya lo tiene, pero para el nuevo proyecto, ¿cuál es el punto? Iría directamente con Java EE 6 (ejb3, jsf2.0, etc.)

Si el cliente está bien con Flex, hágalo. Utilice BlazeDS o similar, no mvc. Es posible que dedique más tiempo a esa parte (intercambiando datos entre el servidor y el cliente) pero tiene control total en ambos lados.

No use Vaadin, a menos que quiera matar su navegador. Además, dedica más tiempo a sortear el código una vez que sus páginas se vuelven más complejas. Además, su forma de pensar deberá cambiarse por completo y todo lo que sepa sobre el desarrollo de interfaces estándar será un desperdicio. El argumento de que no es necesario utilizar HTML o JS no tiene mucho sentido. Aún tiene que saberlo incluso si no lo usa. Eventualmente se renderiza a HTML y JS. Luego intente depurarlo, asegúrese de tener unos días para cosas simples. Además, no puedo imaginarme a un desarrollador web que no sepa html / js.

Simplemente no entiendo por qué la gente está probando todas esas abstracciones en lugar de usar Java EE directamente.

¿Por qué todavía hay rumores de que EJB será un peso pesado en 2010? Parece que la gente no se está actualizando en las tecnologías Java EE. Pruébelo, se sorprenderá gratamente de cómo se simplifican las cosas en Java EE 6.

La respuesta a sus preguntas depende de los requisitos de su proyecto. Si no necesita las funciones de Java EE, como colas de mensajes, transacciones globales administradas por contenedores, etc., elija tomcat + spring.

También por experiencia, he descubierto que los proyectos que requieren mucha integración de servicios web, programación y colas de mensajes se realizan mejor utilizando parte de la pila Java EE. Lo bueno es que al usar Spring, aún puede integrarse con los módulos Java EE que se ejecutan en un servidor de aplicaciones.

Java EE 6 es muy diferente de las versiones anteriores y realmente hace que todo sea mucho más fácil. Java EE 6 combina las mejores ideas de la diversa comunidad de Java; por ejemplo, Rod Johnson de Spring Framework participó activamente en la creación de Dependency Injection JSR en Java EE 6. Una ventaja de usar Java EE 6 es que está codificando de acuerdo con un estándar, que podría ser importante en algunas organizaciones para el soporte de proveedores, etc.

GlassFish v3 es compatible con Java EE 6 y es bastante ligero y se inicia muy rápido. He estado usando glassfish v3 para mis desarrollos y es realmente fácil de configurar. Viene con una consola de administración muy fácil de usar que le permite administrar gráficamente su servidor.

Si está utilizando GlassfishV3 y JSF 2, puede aprovechar las funciones CDI de Java EE 6, que le permiten crear fácilmente conversaciones (por ejemplo, páginas tipo asistente) en JSF.

Dicho esto, el uso de Java EE 6 también requiere que aprenda una nueva API. Dependiendo del período de tiempo disponible, puede que no sea la mejor opción para usted. Tomcat ha existido durante años, y la combinación tomcat + spring ha sido adoptada por muchos proyectos web, lo que significa que hay mucha documentación / foros.

He trabajado tanto en Spring como en Java EE 6. Lo que puedo decir de mi experiencia es que si opta por el JSP antiguo o el Flex propietario, está seguro si se queda con Spring.

Pero si va a seguir adelante con JSF, entonces es hora de cambiar a Java EE 6. Con Java EE 6 se está moviendo a Facelets y bibliotecas de scripts estandarizados y bibliotecas de componentes. No más incompatibilidades de scripts y matrices de bibliotecas de componentes.

Con respecto a Spring MVC, es bueno siempre que su proyecto no crezca demasiado. Si se trata de una gran aplicación empresarial, apéguese a Java EE 6. Porque esa es la única forma en que podría mantener sus propias bibliotecas de componentes y paquetes de recursos de manera ordenada.

Si necesita la pila completa de Java EE, le recomiendo GlassFish 3.1. Comienza muy rápido en comparación con otros contenedores Java EE que implementan una parte o todo Java EE 6 (JBoss 6, WebLogic 10.3.4), la redistribución toma segundos y casi todo se puede hacer por convención sobre la configuración, es muy amigable.

Si quieres algo "ligero", puedes personalizar un Apache Tomcat 7.x con las características deseadas. Usé mucho con las siguientes bibliotecas: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - solo transacciones locales de recursos JSF 2.x (Mojarra) RichFaces 4.0 BIRT runtime

He sido desarrollador de Java EE durante los últimos 10 años (sufro las primeras tecnologías EJB, JSF y web), Java EE 6 es muy fácil, está bien acoplado y el hardware actual funciona sin problemas, por lo que las razones originales que motivaron a Spring ya no son válidas.

Todavía prefiero la primavera.

Y pasaría JSF. Creo que es una tecnología muerta. Spring MVC sería una mejor alternativa. Flex también. Piense en términos de contrato primero con servicios XML y podrá desacoplar el back-end de la interfaz de usuario por completo.

Recomendaría Spring + Tomcat a menos que pueda esperar el tiempo para que glassfish v3 y Weld sean más maduros. Actualmente, existen algunos problemas con el consumo de memoria / carga de la CPU al ejecutar Glassfish con aplicaciones habilitadas para CDI.

No leí todo, pero solo para decir que ahora puede usar EJB3 dentro de una guerra en Java EE 6 para que pueda usar EJB3 en Tomcat (creo).

Te recomendé Tomcat con Spring porque:

1. Spring puede crear beans de respaldo para JSP
2. Usarás Spring para persistir el objeto a través de JPA

Es una buena opción elegir Tomcat porque no necesita ningún procesamiento pesado