Ir al contenido principal

Opinión Servlet 3.0

Leo en el sitio The Server Side, un articulo que da un pequeño recorrido a través de la nueva especificación de Servlets que esta por salir. Como se había escuchado y era de esperar, los Servlets podrán ser creados como Pojos, digamos:

@Servlet(urlMapping={"/myServlet"}, name="MyServlet")
class MyServlet {

@GET
@POST
public void handleRequest(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
....
}
}

Yo le encuentro algunos problemas a esto:

  • No se desacopla del WebContainer o de los objectos Mock para hacer testing, por que se sigue recibiendo el objeto request y response.

  • En caso que ocupe los "init" parámetros o algún método del HTTPServlet, no veo ninguna alternativa

  • Como dice el articulo de ServerSide, un usuario puede anotar dos veces un método con GET o POST, provocando una posible confusión al WebContainer



La primera característica comentada en el articulo, me parece cool, en el sentido que te proporciona un control mas tipo HTTP 1.1 para los request, controlando los hilos del request.

La segunda también esta cool, sin embargo me gustaría que esta característica pudiera ser desconectada cuando una aplicaron es desplegada, por asunto de seguridad, pues alguien podría subir un jar a nuestro classpath y desplegarlo de forma automática.

En fin, parece que los pojos anotados, están en boga y a la luz de los cambios, pienso que esta bien que estén ahí, pero no estoy seguro de querer usar todo el batiburrito con salsa agridulce que nos están dando :)

Link del articulo http://www.theserverside.com/tt/articles/article.tss?l=PonderingAboutJSR135
Etiquetas:

Comentarios

Publicar un comentario

Entradas más populares de este blog

Analizador de expresiones algebraicas recursivo decendente

Como les mencione en un post previo, estoy leyendo el libro el arte de programar en Java, el primer ejercicio consiste en un analizador de expresiones algebraicas recursivo descendente, el mismo consiste en la posibilidad de tomar una cadena que contenga una expresión matemática, la misma puede contener valores en punto flotante, sumar, restar, dividir, multiplicar, sacar exponente (potencia), uso de paréntesis para priorizar una operación, etc. A continuación clase a clase, con una pequeña explicación Lo primero que definiremos es una suite de excepciones para reportar errores, no tiene mucha ciencia, hay una para la division entre cero, cuando no existe una expresión valida, error de sintaxis o cuando los paréntesis no se encuentran balanceados, veamos package cap2; /** * Exception para reportar que hay al intentar dividir entre cero * * User: jsanca * Date: 4/16/13 * Time: 1:30 AM * @author jsanca */ public class DividedByZeroException extends RuntimeException { ...
4 comentarios
Leer más

Impensando acerca de las referencias en Java

Fue hace ya algún tiempo que pase un rato discutiendo con algunos compañeros acerca de si existe o no el paso por referencia; el discurso fue mucho hacia que en Java el comportamiento, en el supuestamente pasamos por referencia un objeto y por valor los objetos primitivos creo mucha polémica. Para ubicarnos en contexto veamos el siguiente ejemplo. public static void main(String[] args) { int value = 10; changeValue(value); System.out.println("value = " + value); User user = new User(); Name name = new Name(); user.setName(name); name.setName("jsanca"); name.setLastName("XXX"); user.setPassword("123queso"); System.out.println("user: " + user.getName().getName() + ", " + user.getName().getLastName() + ", " + user.getPassword()); changeValue1(user); System.out.println("user: " + user.getName().getName() + ", " + user.getName().getLastName() + ", " + user.ge...
11 comentarios
Leer más

Transformando fechas a diferentes zonas horarias (TimeZone)

Ya es sabido por todo programador Java, que uno de los puntos mas bajos, recae en el uso de las fechas, las mismas se encuentran super mal diseñadas y algunos objetos como el caso de Date, practicamente no son usables, pues toda su API esta deprecada (cosa que siento debería de dejar de ponerla deprecada, pues van por la versión 6 y aun la conservan). Recientemente me encontré con el siguiente problema; resulta que al poner un sistema en otro servidor, el cual aparentemente tiene una diferencia horaria configurada, obtenemos como seria de esperar resultados no esperados, cuando realizamos consultas con fechas a la base de datos. La primera solución que se nos ha ocurrido es implementar un convertidor de fechas a diferentes zonas horarias, a continuación coloco el método necesario para realizar la operación: public static Date convertToTimeZoneDate(Date date, TimeZone timeZone) { Date newTimeZoneDate = null; Calendar foreignCalendar = null; // Create a Calendar object with the local ti...
4 comentarios
Leer más