Archivo de la categoría ‘Programación’

Evolución del EL (expression language)

Sábado, 8 de Febrero de 2014
glassfish

glassfish

En un artículo en stackoverflowBauke Scholtz describe de una manera muy clara la evolución EL (expression language). En este post voy a traducirlo ya que me ha parecido muy interesante.

  • Jun 2002: JSTL 1.0 se presentó con EL por primera vez. Eran esas cosas ${} que funcionaban solo en las etiquetas JSTL. Estaban diseñadas para llamar a los métodos get de los Javabean.
  • Nov 2003: JSP 2.0 se presentó y EL fue transferido desde JSTL 1.0 a JSP 2.0 en el paquete javax.servlet.jsp.el y se convirtió en standard EL como parte de J2EE 1.4 standard. JSTL 1.1 llegó sin EL. En este momento ${} funcionaba fuera de las etiquetas JSTL y también en las plantillas  JSP.
  • Marzo 2004: JSF 1.0 se presentó con deferred EL en el paquete javax.faces.el.Eran esas cosas #{} que funcionaban solo dentro de las etiquetas JSF. La diferencia con standard JSP EL ${} era que no solamente podían hacer get, sino que también podían hacer set. Esto era obligatorio para la auto-creación de los managed bean y la asignación de los valores de los componentes input. El standard EL ${} también funciona en las etiquetas output de JSF, pero no pueden auto-crear beans si no existen previamente en el scope y no ‘setean’ (inicializan) valores.
  • Mayo 2005:  Mientras aún se preparaba una nueva versión  JSP 2.1 que debería ser lanzada en Marzo 2006, deferred EL #{}se trasladó desde JSF  y se combinó con standard EL ${} en el paquete javax.el. En este punto se vino a llamar unified EL el cual se presentó dentro de JSF 1.2 y se convirtió en un estándar de JSP 2.1 y Java EE 5. Los #{} ahora también se pueden usar en etiquetas JSP para recoger valores (get) pero no para establecerlos (set).
  • Nov 2006: Facelets se presenta como un sucesor de JSP. Permite el uso de #{} en plantillas fuera de etiquetas JSF, como sustituto de <h:outputText> sin atributos. Interpreta ${} como #{}, por lo que se pueden utilizar indistintamente en Facelets.
  • Dic 2009: EL 2.2 se presenta con JSP 2.2 / Java EE 6 el cual permite llamar dentro de la sintaxis #{} a acciones (actions) de métodos específicos en lugar de solo métodos get y set de los Javabean, por ejemplo #{bean.method(argument)}. Facelets comienza a formar parte del estándar Java EE 6.

Fuente: http://stackoverflow.com/questions/4812755/difference-between-jsp-el-jsf-el-and-unified-el

Hibernate y su empleo de Javassist

Miércoles, 5 de Diciembre de 2012

hibernate

Hibernate emplea las librerías Javassist (Java Programming Assistant) para realizar tareas de reflexión java (java reflection), por ejemplo, para construir objetos definidos como lazy que se obtienen posteriormente a la ejecución de una consulta. Las clases construidas, aunque respetan el interfaz de la clase original, tienen diferente nombre de clase, formando parte del nombre la palabra ‘javassist’, por ejemplo una clase de nombre ‘Item’ formada con javassist puede pasar a llamarse ‘Item_$$_javassist_165’. Esto a veces conduce a errores ya que si se comparan los nombres de clase de un objeto, por ejemplo, en el método ‘equals’ de una clase,  los nombres serán diferentes.
(más…)

Conversión de cadenas vacías en tipos no primitivos

Miércoles, 22 de Febrero de 2012

Hace poco actualizando Eclipse me encontraba con el problema de que a pesar de que las aplicaciones se desplegaban en el servidor correctamente (Tomcat en este caso), los formularios de las vistas no funcionaban como se esperaba. En concreto, había campos de formulario vacíos que se convertían en valores reales (no nulos) al trasladarse al backing bean. Por ejemplo, un elemento de texto que estaba vacío en el formulario, al trasladarse a una propiedad de tipo Long del backing bean se convertía en 0L en lugar de en el valor null esperado.

El problema parece estar causado en un cambio en la especificación EL.

Para solucionar este problema en Tomcat, que se comporta de esta manera a partir de la versión 6.0.16, podemos arrancar el servidor añadiendo en el arranque la opción: -Dorg.apache.el.parser.COERCE_TO_ZERO=false

En eclipse haremos doble click sobre el servidor tomcat en la pestaña de servidores:
Eclipse Servers
Accederemos a la configuración de arranque pulsando sobre el enlace “Open launch configuration”:

Añadiremos la opción mencionada anteriormente en el cuadro de texto “VM Arguments” de la pestaña “Arguments”:

Fuente

‘Connection reset by peer’ en conexión bluetooth (Ubuntu)

Sábado, 10 de Septiembre de 2011

Haciendo pruebas de comunicación bluetooth entre Android y Linux (Ubuntu 11.04 Natty Narwhal) me he encontrado con que Android se vinculaba correctamente con Linux, sin embargo al proseguir con la comunicación, en Android saltaba el error “Connection reset by peer”.

Mirando el log de sistema de linux ‘/var/log/syslog’ se observaba:

Sep 10 10:38:07 linuxPC bluetoothd[3589]: Unable to spawn pnatd: Failed to execute child process "/usr/bin/phonet-at" (No such file or directory)

El problema parece residir en que por defecto Ubuntu tiene configurada la llamada a un módulo que no tiene instalado y que además según he leído solo tiene sentido compilarlo cuando se trabaja con dispositivos Nokia. Podemos evitar la llamada a dicho módulo añadiendo al archivo principal de configuración del bluetooth ‘/etc/bluetooth/main.conf’ la línea:

DisablePlugins=pnat

Después de esta modificación y el reinicio del servicio de bluetooth todo a funcionado perfectamente.