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


90

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?


8
Yo iría a primefaces.org en lugar de IceFaces si quieres luz. Es mucho más rápido y una API más sencilla.
Shervin Asgari

1
Solo Glassfish proporciona JEE6 en este momento. Resin está implementando lentamente el perfil web JEE6 , que podría ser suficiente para ti dependiendo de lo que necesites.
Thorbjørn Ravn Andersen

3
@ Thorbjørn Puede utilizar GlassFish v3 Web Profile si solo desea el perfil web.
Pascal Thivent

@Pascal, fue para detallar que pronto habrá una alternativa a Glassfish para obtener JEE6 si puedes vivir con el perfil web (yo puedo), por no decir que Glassfish no puede.
Thorbjørn Ravn Andersen

@ Thorbjørn Olvidé eliminar el @ Thorbjørn :) El comentario estaba destinado al OP, que parece asumir que el uso de GFv3 "full-stack" es la única opción.
Pascal Thivent

Respuestas:


101

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.


2
Estoy justo después de evaluar un gran proyecto desarrollado con EJB3.0 + Seam en JBoss con Drools, GraniteDS y algunos más. Estoy de acuerdo ¡Seam rocks! Pero gasté el 50% del desarrollo en redistribución, reinicio de servidores, errores de implementación, limpieza de directorios temporales, etc. Por otro lado, el rendimiento de JBoss Tools fue realmente pobre (quiero decir, realmente - ctrl + espacio y 10s cuelgan) Esto realmente me desanima a usar JEE6 que parece tomado del marco de Seam. En cuanto al servidor, no quiero pensar en piscinas de conexión, jndi, jms, jmx, ear deplyment. Necesito algo para poner WAR y ejecutarlo en segundos.
Piotr Gwiazda

6
@peperg Gaving King es el líder de especificaciones de CDI (Weld es el RI), por lo que encontrará similitudes entre Seam y CDI. ¡Pero CDI! = Seam, Java EE 6! = Seam, tu percepción es incorrecta. Tal vez pruebe GlassFish v3 Web Profile, se sorprenderá (y una vez definido el grupo de conexiones, no hay mucho de qué preocuparse).
Pascal Thivent

8
¿Qué pasa con la gente que dice que los EJB son pesados? Estoy usando EJB v3.1 y simplemente son pojos anotados. Cuando dicen pesado, ¿se refieren al rendimiento o qué?
arg20

13
@ arg20 - Esa es de hecho la gran pregunta y Pascal pide con razón que explique qué significa el término "pesado" (o "ligero") en este contexto. Lo más probable es que sea un resto de la vieja disputa entre Spring y EJB. En los primeros días, EJB1 y 2 eran conceptualmente pesados. Un énfasis excesivo en beans con estado y remotos, un descriptor de implementación XML ridículamente detallado y una cantidad totalmente insana de interfaces requeridas para ser implementadas les dio una muy mala reputación. Con EJB3 (2006) esto ha cambiado por completo, pero las personas que dejaron EJB en 2004 para pasar a Spring a veces todavía piensan que es 2004 y EJB2 es el último.
Arjan Tijms

7
Tenga en cuenta que en la página acerca de Spring dice "Creemos que: J2EE debería ser más fácil de usar". Tenga en cuenta que utilizan el término "J2EE" y no "Java EE", que ha sido el nombre correcto desde el lanzamiento de Java EE 5 (creo). Esto dice mucho de ellos ...
Vítor E. Silva Souza

32

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).


1
Exactamente, este es un gran razonamiento.
Palesz

1
Estoy de acuerdo con este razonamiento, muchos de los problemas que he enfrentado han sido con dependencias en la implementación de una especificación de un contenedor. Significativamente menos doloroso de las bibliotecas integradas. Difícil de argumentar, fuera de la preferencia filosófica de una especificación.
Peter Porter

Razonamiento maravilloso. Sin embargo, ¿es esta su experiencia incluso después de JEE 6? Entiendo que las implementaciones de especificaciones de App Server pueden ser un problema, por lo tanto, la misma especificación implementada por App Server 1 puede ser simple y eficiente, pero no para App Server 2
Soumya

1
+1. Además, el servidor de aplicaciones cambia según el horario de Operaciones, donde Spring / Hibernate está bajo el control de los desarrolladores. en el entorno de una gran empresa, la actualización del servidor de aplicaciones es mucho más importante.
Nathan Hughes

Realmente no entendí el punto sobre Dot-Net. Es tan propio como Spring y está desarrollado por un único proveedor que es Microsoft. ¿Podría explicarse por favor?
user1339260

23

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).


1
Entonces, la pregunta es: "¿Tiene sentido usar el servidor de aplicaciones Glassfish de pila completa solo para usar el perfil web"?
Piotr Gwiazda

1
@peperg Use el perfil web GlassFish v3 si solo desea el perfil web, vea mi respuesta.
Pascal Thivent

He publicado algunos argumentos aquí stackoverflow.com/questions/2822812/spring-3-0-vs-j2ee-6-0/… , más bien tomados desde el punto de vista de "cómo llevarlo a producción". Entonces, tal vez eso llene un poco su reserva de argumentos.
Oliver Drotbohm

@peperq, JBoss 6 se lanzó durante las vacaciones.
Thorbjørn Ravn Andersen

17

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.


Java EE 6 es jodidamente lento, el perfil web glassfish y glassfish es muy lento para comenzar a compararlos con jetty / tomcat / lo que sea. Probar el contenedor integrable también es muy lento.
Palesz

15

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á)

21
No veo cómo su propia respuesta se relaciona con la pregunta ...
Pere Villega

1
-1 Parece muy inapropiado aceptar esta respuesta, ya que ni siquiera menciona Java EE 6. Además, no aborda ninguno de los puntos planteados en el bien pensado (y mucho más votado) de @Pascal Thievent responder.
user359996

1
En realidad la pregunta no es más válida. JEE 6 ahora está muy maduro, no fue en marzo de 2010 cuando se hizo la pregunta.
Piotr Gwiazda

@PiotrGwiazda ¿de qué manera cambió JEE 6 desde entonces? La gente le tenía más miedo en ese entonces, pero básicamente era el mismo JEE 6.
ymajoros

1
Quise decir que las implementaciones de JEE6 son más maduras y están disponibles. JBoss 7 ahora es estable y hay más implementaciones disponibles. La comunidad también es más grande ahora. Más herramientas y bibliotecas ahora admiten la pila JEE 6.
Piotr Gwiazda

8

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 '


6
Estamos casi exactamente un año después y JBoss AS 6, que es compatible con Java EE 6, se está utilizando actualmente en producción.
Arjan Tijms

8

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.


Resultó que Java ServerFaces 2 en Java EE 6 podía hacer por sí solo lo que necesitábamos para Tomahawk con JSF 1. Es un marco bastante capaz (pero un poco XML pesado)
Thorbjørn Ravn Andersen

Gran punto, desafortunadamente la gente tiende a olvidar que el software está hecho para vivir durante décadas y que el soporte a largo plazo es una clave crucial.
timmz

6

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.


5

¿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.


4

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.


No estoy de acuerdo con tu primera oración, la elección no se trata de usar JMS o no. Y no creo que JSR-330 sea tan importante en Java EE 6 (está más ahí por razones políticas), la parte importante es JSR-299 (CDI). Al menos, esta es mi opinión.
Pascal Thivent

Estoy de acuerdo en que hubo algunas políticas relacionadas con JSR330; sin embargo, es bastante importante ya que proporciona una base común para la inyección de dependencias en Java (SE o EE) en lugar de convertir a DI en una tecnología solo para JEE. Además, es compatible con Spring Framework y Google Guice, lo que significa que hará que el código Spring / Guice sea fácil de transferir a JEE6 o viceversa. JSR299 también se diseñó para ampliar las funciones de JSR330. Tiene razón en que para las aplicaciones web en JEE6, JSR299 es absolutamente crucial. Gracias a estos dos JSR, JEE6 y Spring tienen un modelo de programación muy similar. ¡Gracias por tu comentario!
Raz

3

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.


1
Gracias por tu comentario. Mi elección fue Spring + Vaadin.
Piotr Gwiazda

3

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.


1
Me gusta tu respuesta. Muy razonable. Cuando publiqué la pregunta, JEE6 era muy joven y Tomcat 7 aún no estaba terminado. "Las razones originales que motivaron a Spring ya no son válidas", es cierto, pero JEE6 con CDI necesita algo de tiempo para recuperarse. Por ejemplo: el monitoreo de Javamelody está disponible para Spring y Guice (no puedo imaginarme trabajando en aplicaciones sin él). EHcache está disponible para Spring (me refiero a los resultados de los métodos de almacenamiento en caché). Muchas cosas como la programación de aspectos son aún más fáciles en Spring, porque muchas bibliotecas y marcos de terceros se integran fácilmente con Spring pero aún no con JEE6.
Piotr Gwiazda

1

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.


1
He creado algunas aplicaciones con Java + Flex y PHP + Flex y estoy de acuerdo en que es la mejor solución para interfaces ricas. Pero en esta aplicación no puedo usar Flex :( Sin embargo, necesito una interfaz de alto nivel, por lo que Spring MVC no es una solución. Quiero pensar en una tabla de datos ordenable que en <tr> <td> en un bucle.
Piotr Gwiazda

1
@duffymo - Puedo discutir si flex es una buena opción. JSF definitivamente no está muerto, especialmente con bibliotecas como richfaces, primefaces, icefaces, etc.
Bozho

1
En IceFaces creo menús, árboles, datagrids, uso acciones, eventos y no creo que la página se recargue o sea una solicitud ajax. Una cuadrícula de datos ordenable o un árbol cargado ajax es un componente incorporado. En Spring MVC, opero en HTML: tablas, listas, etc. Necesito usar algún marco de javascript de terceros y crear la magia AJAX a mano. Me gustaría hacerlo en Flex, pero es una decisión política / empresarial, no mía.
Piotr Gwiazda

1
Mis dos proyectos JSF actuales definitivamente no están muertos;) Y estoy mucho más satisfecho con la forma JSF de construir RIA ("rich" en "richfaces" es para eso), que con Flex. Uno incluso se hará público la próxima semana.
Bozho

2
Realmente me gustaría saber por qué todavía prefieres Spring, Java EE 6 es muy bueno. ¿No cree que ejecutar en una plataforma abierta es importante para el futuro de Java?
Pascal Thivent

0

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.


0

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).


Sí, puede empaquetar EJB en un WAR en Java EE 6, pero esto no significa que pueda implementar dicho WAR en Tomcat. Necesita un contenedor que implemente el perfil web y Tomcat no, y en realidad no hay ningún plan en la comunidad de Tomcat para implementarlo (consulte old.nabble.com/Java-EE-6-Web-Profile-td27715793.html ). Pero hay un perfil web GlassFish v3, habrá resina ...
Pascal Thivent

2
actualización: eche un vistazo al proyecto TomEE
gpilotino

-3

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


1
¿"Procesamiento pesado"? ¿Podría darnos más detalles? Soy curioso.
Pascal Thivent
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.