Rajiv Mordani escribe en su blog una semblanza acerca de la nueva especificación JSR 315 para la versión 3.0 del API para Servlets. Esta especificación forma parte de lo que será JEE 6.
Sin duda, desde su concepción este API ha sido la más usada en el mundo de JEE y no ha sufrido grandes cambios desde su primera versión. Sin embargo en esta especificación en progreso se planean cambios importantes que desde mi punto de vista facilitarán la tarea al desarrollador. De hecho los compararía con aquellos que sufrió EJB en su versión 3 ya que buscan un modelo más dinámico y ligero para el manejo de lo Servlets.
El primer punto de los explicados por Rajiv es el uso de fragmentos web o la muerte del monolítico web.xml como lo conocemos hasta ahora. Hasta la versión 2, para definir nuevos servlets y componentes web (Listeners, Filters, etc) había que editar el fichero web.xml de nuestra aplicación. Lo que supone que a la hora de usar la mayoría de los frameworks web en el mercado en el mejor de los casos había que declarar el Servlet FrontController de los mismos, o incluso Listeners y Filters. En servlets 3.0 la especificación permitirá usar varios web.xml en una misma aplicación, de esta forma al instalar un framework web x, el web.xml con los elementos necesarios para dicho framework podrá venir dentro del .jar que lo contiene y al iniciar el contenedor, éste será el encargado de juntar dichos web.xml para formar uno solo.
El siguiente punto que menciona Rajiv es el uso de anotaciones para construir nuestros servlets, de esta forma un servlet será un POJO anotado con "@Servlet". Resulta curioso que a partir de JEE 5, el JCP decidió crear anotaciones para EJB, JPA, servicios web JAXWS y sin embargo a los Servlets los habían dejado afuera. Pues bueno en esta nueva especificación los Servlets se mueven a la tierra de los POJOs, lo que de hecho hace (junto con los fragmentos web) que el otrora omnipresente web.xml se convierta en un elemento opcional de las aplicaciones web java.
El tercer punto resulta bastante interesante, es el soporte para Servlets asíncronos. Por lo que menciona Rajiv este soporte no está muy definido todavía. Pero la idea es incluir en el API nuevos métodos para el procesamiento asíncrono de peticiones HTTP, Rajiv da la siguiente lista de nuevos métodos:
La idea es permitir la construcción de aplicaciones Comet (o server Push o reverse Ajax o como le llaméis) usando directamente el API de Servlets. En el pasado se ha hablado del interés de Sun de incorporar las Continuations que Jetty desarrolló para soportar Comet en su servidor de aplicaciones al API de JEE; quizás la especificación de Servlets 3.0 sea donde se pueda integrar dicha tecnología.
Otras mejoras al API mencionadas por Rajiv incluyen el añadir a la clase HTTPServletRequest los métodos login y logout y a la de HttpServletSession logout; con el fin de permitir la autenticación de forma programática.
Sin duda una importante puesta al día del API para esta nueva especificación de JEE. ¿Qué os parecen estas modificaciones?
Etiquetas: j2ee, servlets, jsr315
a mi me gustan, llego la era de los Pollos (POJOs,pronunciado en english)... :D Todo lo que sea para facilitarnos la vida bienvenido sea, trabajamos menos, cobramos mas (claro, estoy utilizando lo ultimo en tecnlogia java). Es como JPA, gracias a el he podido ahorrar un monton de tiempo..
PD: mmm ya me dio hambre, voy por un pollo.. xD
Yo sigo dando la vara a ver si arreglan la seguridad de una vez...
La estandarización de Comet seguramente influirá mucho en los frameworks web, y veremos aplicaciones tipo Gmail con mucha más frecuencia. Y con respecto a los Servlets/POJO, son una adición obvia. Los POJOs anotados son un alivio en un lenguaje como Java, pero el éxito que estan teniendo muestra un poco las falencias del lenguaje. La carencia de soporte de composición o mixins lleva a la adopción de estas soluciones que no son muy typesafe ni OOP que digamos.
Pues sera cosas mira, pero teniendo en cuenta que el 90% de los frameworks modernos utilizan 1 solo servlet como base, lo de anotar los "mappings" en el .java me parece una ***conada.
Lo de Comet suena interesante, pero habra que ver que aplicaciones le damos... de momento a mi me parece que es añadir un grado de complejidad aun mas, para que los que ya no se aclaran con la simplicidad de peticion/respuesta la caguen aun mas... :)
Una consulta sobre Comet. ¿Que tal se lleva con los Proxys? porque no creo que un proxy tenga la paciencia de dejar abierta la conexión tanto tiempo.
Yo creo que a lo de Comet le quedan unos hervores. Mirando este "simple ejemplo de Comet en 100 lineas": http://weblogs.java.net/blog/driscoll/archive/2008/05/dead_simple_com_1.html y leyendo el artículo, te encuentras que el mismo que lo escribe dice que tiene que usar hacks, que aun quedan bugs sin resolver, que a veces hay que darle dos veces a actualizar... en fin.
De momento lo de Comet lleva el camino del "JavaScript Avanzado", muy bonito para algunos casos pero a la que no tengas un ferreo control sobre navegadores, red, etc. pues mejor no meterse en fregados. Yo creo que estamos llevando al pobre HTTP mucho mas alla de lo que pensaba que iba a llegar, y en cuanto le das un poco de "marcha" ya va con la lengua fuera y sin aire...
Lo de los POJO para los Servlet no lo tengo claro.
¿Que gano por poner una anotación en vez de extender de él?
Por otro lado respecto al web.xml la idea es muy buena pero ¿es técnicamente posible?
Mirar los jars y buscar el web.xml es facil pero ¿Y si las clases estan en una base de datos? o en otro sitio.
Hasta donde yo se no se puede pedir a Java que te diga las clases que hay en un paquete, y supongo que menos aun los ficheros que hay en un paquete.¿Alguien sabe más de este tema.?
Respecto a Comet, ya era hora que lo estandarizaran. Espero que lo hagan bien y todos sigamos el estandard pq sino cada servidor sacará su propio estandar.
Y greeneyed, yo le pago mucha caña al JavaScript y al principio cuesta un poco pero luego realmente no hay tantas diferencias (Aunque solo uso IE6, IE7 y FF2). Tengo más problemas con el HTML/CSS que con JavaScript.
Saludos.
realmente no hay tantas diferencias (Aunque solo uso IE6, IE7 y FF2).
La segunda parte es en gran parte culpable de lo que ves ;). De todas formas, nos hemos acostumbrado a usar librerias que nos aislen de las diferencias entre unas implementaciones de JavaScript y otras. No es que este mal, pero simplemente oculta el problema, no lo elimina. Lo de las CSS si que toca la moral, si.
De más esta decir que se han jugado por crear al fin algo que simplifica mucho código desperso por montón de clases, ya sean Servlets, Filtros y Listeners para controlar el flujo de llamadas y también con respecto a las validaciones. Trabajo con Struts y gran parte de mis proyectos han comenzado con los simples Servlets básicos de años atrás hasta los JSP. Muy bueno este punto y espero que siga creciendo para que, más allá de facilitarnos el trabajo a todos, que se puede ser más performante simplificando contenidos y potenciarlos al máximo.
Estoy de acuerdo con GREENEEYED, y desde luego un "cuidado exquisito" con el javascript (a pelo) que penséis utilizar os evitará muchos dolores de muelas, pues siempre se queda uno expuesto a las más insospechadas genialidades de los navegadores. En mi caso y como ejemplo, para una "sencilla" aplicación de reservas con servlets y JSP's, una de las primeras actualizaciones de seguridad del IE7 (que manda narices) ,literalmente el mismo código en la mismas páginas HTML COLGABA el IE7 (configuración por defecto). Sí señores y señoras, haga click aquí para colgar su navegador. La anécdota puede parecer divertida, pero cuando tienes 1200 oficinas utilizando tu aplicación os prometo que uno se acuerda de los de Redmon ( y muy escatológicamente).
Me parece genial el uso de la anotaciones....desde que las descubrí no puedo vivir sin ellas!!!.
A la API Servlet ya le tocaba una buena ampliación....
Escribe tu comentario