Apuntes de Java

Los WebSockets son una manera de poder comunicarse vía web entre un cliente y un servidor. A diferencia con otras tecnologías parecidas como los RESTful WebService, es que esta tecnología es bidireccional. El RESTful tiene que constantemente pedir al servidor para ver si hay un cambio, y con algunas técnicas "push" se puede simular una comunicación bidireccional. Con WebSockets, la comunicación es nativa. Ya que estamos cerca del lanzamiento de Java EE 7 implementado en GlassFish 4.0, veremos un pequeño esbozo de esta tecnología.

Hasta el momento hemos visto un CRUD usando RESTful, con un objeto y varios objetos. Ahora, quiero mostrar el manejo de la seguridad en RESTful usando los estándares de Java EE6.

La inyección de dependencia es una técnica popular en el desarrollo de aplicaciones empresariales java. En una inyección de dependencia, también llamada Inversión de Control (Inversion of Control - IoC) , un componente especifica los recursos de los que depende. Un inyector, típicamente un contenedor, proporciona los recursos al componente. Aunque la inyección de dependencia puede ser implementado de varias maneras, muchos desarrolladores lo implementan con anotaciones.

Bueno, la cosa estuvo reñida. Pero aquí los resultados de la encuesta sobre qué software utilizar para el curso de Liferay que estoy elaborando.

Estoy preparando un tutorial de Liferay y - para que los que desean llevar el curso online - me gustaría conocer qué es lo que quieren encontrar ahí

Todo mantenimiento de objetos debe tener siempre lo que en inglés se llama CRUD (Create - Read - Update - Delete). Hasta ahora hemos visto C y R. Faltan el U y el D. Así que en este artículo hablaremos de ello

Comenzamos este año nuevo con la continuación del (creo yo) más esperado tema de tutorial: RESTful . Y esta vez hablaremos sobre el manejo de colecciones y objetos complejos. Por ahora será de manera básica y veremos poco a poco cómo hacerlo más y más complejo.

Hemos visto en el anterior post cómo hacer un servicio REST solo para producir y consumir un texto simple. Ahora bien, en la vida real no son textos simples, sino estructuras de datos algo complicadas. Pero para ir lentos pero seguros, aprenderemos cómo hacer un servicio REST pero para manejar un solo objeto.

He estado buscando alguna opción de Liferay que me permita crear varios usuarios a la vez... pero no tuve éxito. Pensé (y hasta pregunté en el foro de liferay.com) si se podía modificar directamente la base de datos. Pero como es un sistema complejo, hacer esto podría malograr el sistema. Entonces pensé que debería haber otra solución utilizando el API de Liferay. Al final de todo, es una plataforma, y debería existir un API completo para ello.

Cuando salió el EJB 3.1 con la capacidad de poderse ejecutar en un módulo web, comencé a usarlo sin parar. Con los EJB me hace más fácil conectarme a la base de datosusando JPA porque simplemente debería usar  @PersistenceContext respectivamente. Pero no todos los servidores  donde uno va a desplegar aplicaciones son Java EE6, así que las facilidades del EJB 3.1 serían truncadas. Afortunadamente existe Spring para ayudarnos a instanciar clases como si fueran EJB, y más aún, nos permite usar JPA y mantener las notaciones  @PersistenceContext . Veamos cómo se hace esto.

Retomando los tutoriales, ahora vengo con lo de la instalación de Liferay 6 en GlassFish v3. La verdad, es casi lo mismo que está explicado en el anterior post " Instalación de Liferay en un servidor GF v3 para producción ", con la excepción de que se debe considerar algunos cambios:

Hasta el momento hemos visto cómo configurar Liferay sobre un Servidor Glassfish v3 para producción . Esto nos permite tener un Portal en blanco listo para que nosotros le configuremos todo. Es decir, el Liferay que viene preconfigurado con el GF, Tomcat o Jetty que está disponible en la página de descarga de liferay.com , tiene contenido preparado, textos de ejemplo, temas, aplicaciones completas, etc. Además que viene configurado con HSQLDB. Si al preconfigurado le cambiamos el acceso a la base de datos para que utilice el MySQL o cualquiera, en ese momento todo el contenido del Portal estará en blanco. Recomiendo la versión preconfigurada de liferay para conocer un poco cómo funciona, y además, para usarlo como caja de arena para probar nuestros portlets. En este post veremos cómo hacer un Portlet para Liferay usando NetBeans 6.x

En un anterior post mencioné los Portales en Java, y la facilidad que nos da el utilizar una plataforma con muchas funcionalidades, y nosotros simplemente deberíamos hacer los componentes que faltan. Estos componentes se llaman Portlets. Ahora mencionaré uno de los gestores de Portlets en Java que, según mi opinión, es bastante útil. Su nombre LIFERAY. Pero no hablaré de sus cualidades, ni todo lo que puede hacer.. eso ya lo hizo Pedro Edison en su blog :) , y como no hay que amontonar la red con lo mismo, esta vez mostraré cómo instalar el LIFERAY desde cero. No desde la instalación de un .exe, sino desde un archivo .war y sobre GlassFish v3 usando MySQL como gestor de base de datos.

Para comenzar con tutoriales de Portlets, es necesario preparar nuestro IDE para programar con Porlets. Por ello primero vamos en este Post vamos a ver cómo instalar el Portal Pack   para NetBeans.

Siguiendo con los ejemplos después de mucho tiempo , ahora mostraré cómo actualizar una lista dependiendo del texto que se escribe en un input-text, pero usando Ajax. Es decir, a medida que se escribe, se actualizará el contenido del texto. Todo esto usando JSF 2.0 con su tag <ajax />

Uno de los tantos motivos por lo que utilizo NetBeans en lugar de otro IDE, es que utiliza la Apache Ant para compilar, crear .jar .war .ear, javadoc, etc.. prácticamente para todo, y solo usando un archivo .xml. Y lo mejor es que se puede personalizar el .xml a nuestro antojo. En este post se va a explicar cómo empaquetar una aplicación Swing en un archivo .zip para ser distribuido a los usuarios finales.

Las aplicaciones Java EE que se han mostrado en este blog son más orientados para desplegarlos en GlassFish. Esto conlleva a que cada los DataSource sean de acuerdo para proveedor de cada Java EE. Así, mis ejemplos para GlassFish no funcionarían para JBoss, Geronimo, WebLogic, etc. Aún así, cuando se desarrolla la aplicación desde NetBeans, y cuando se genera el .war, este no asegura que en ese archivo no exista la configuración de DataSource para la aplicación para usar. Por ejemplo, para GlassFish desde NetBeans se crea el archivo sun-resources.xml , pero este archivo no existe dentro del .war. Por tanto, antes de desplegar el .war en el GlassFish, se necesita crear manualmente el Pool de Conexiones y el Recurso JDBC. Como siempre he dicho a los que he dictado el curso Java EE: el archivo sun-resources.xml es el archivo de recursos para el modo de desarrollo. Solo es usado desde NetBeans. Ahora bien ¿no debería haber un archivo único? Vamos: el JPA funciona para todos los motores

Leyendo el FAQ de EJB ( https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html ) quiero comentar cómo crear un cliente EJB sin necesidad de desplegarlo en el mismo en servidor. Realmente es muy simple:

Volviendo con mis vídeos tutoriales, aquí presento cómo hacer un servicio RESTful desde NetBeans 6.9.

No sé si ya lo sabíais, pero yo recién lo encontré. Existe un catálogo de bastantes (y eso es poco) ejemplos de Java, para todos los gustos y sabores. http://www.java2s.com/Tutorial/Java/CatalogJava.htm También hay catálogos para otros lenguajes, pero lo que a mi me importa es Java :) Provecho