Apuntes de Java

Continuaremos con nuestro proyecto de prueba. Ahora lo configuraremos para que permita probar EJB que tendrán la lógica de negocio, y utilizando JPA como motor de persistencia.

Seguimos con RESTful en Java! Ya luego comentaré qué pasó conmigo y por qué no estuve enviando contenido a mi blog. Hasta el momento hemos visto casi de manera abstracta el funcionamiento de RESTful  usando Jersey desde NetBeans . Ahora veremos como probar todo un CRUD de RESTful desde un complemento de Firefox llamado Poster .

Ya que GlassFish v3 es compatible con Java EE6, y permite módulos web con componentes EJB (por la característica propia de EJB 3.1).. y además Liferay puede ser instalado sobre GlassFish v3... y... los portlets son módulos web con otro archivo de despligue ¿los portlets para Liferay/GFv3 deberían permitir EJB 3.1?

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.

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:

En NB 6.8 existe un mejorado asistente para crear un CRUD usando JSF 2.0/EJB 3.1/JPA 2.0. Aquí está un vídeo demostrativo. Las tablas se crean automáticamente a partir de las clases entidad que se crearon.

NetBeans 6.8 viene con una (de muchas) característica novedosa: Pruebas Unitarias para EJB 3.1. Para ello, primero recordemos lo siguiente: EJB 3.1 es parte de Java EE 6 Glassfish V3 implementa Java EE 6 NetBeans 6.8 tiene soporte para Java EE 6, y por tanto también a Glassfish V3 Hecha esta aclaración, probemos lo siguiente: Hacer un módulo ejb para GF3 llamado CalculadoraModule . Ahora, recordemos algunas de las características del EJB 3.1: Existen los @Singleton que son como un Stateless pero único y perpetuo en el contenedor. Permite también sincronización para evitar "datos cruzados". Ya no requiere de una interfaz como local o remote, puede ser una clase y nada más. Para acceder a través de un JDNI no se necesitará de direcciones raras según sea el contenedor. Todas serán "globales" para un mismo estándar. Hecho el recordatorio, crearemos un SessionBean pero que sea Singleton y que no sea ni local ni remote. Este Bean se llamará "SeriesBean...

Aquí podrás encontrar un conjunto de ejemplos y buenas prácticas de Java EE 5 y 6. http://kenai.com/projects/javaee-patterns/ Todos los ejemplos fueron probados en Glassfish V2 / V3 y algunos en OpenEJB y JBoss 5. Puedes utilizar NetBeans 6.7 para acceder a los proyectos y opinar en los foros.

El escenario es el siguiente: Tienes un módulo EJB que consume un WebService, ya sea desde otro proyecto local o desde un WSDL externo al proyecto. Y tienes una aplicación web que utiliza el módulo EJB. Cuando despliegas el EJB, no hay problemas, pero cuando despliegas el módulo web, no sale nada y lanza un error: wsdl file META-INF/wsdl/client/......wsdl does not exist for service-ref... Dirás (como yo dije) "pero si compila!!!".. y pensarás "y si consumo el WS dentro del modulo web?". y te negarás porque eso rompería el esquema que pensabas... bueno... alguien también le pasó y también encontró la solución. Nada más hay que revisar el código que crea NetBeans en el EJB cuando consume un WebService: @WebServiceRef(wsdlLocation = "META-INF/wsdl/client/ProductsList/localhost_8084/ProductsListService/ProductsList.wsdl") private ProductsListService service; El EJB lo consume normalemente, porque el WSDL está dentro del mismo proyecto EJB. Cuando es llamado d...

Si hacemos una aplicación Web ¿para qué necesitamos los EJB, si todo lo podemos programar en los Servlets y los JSP?... y si programos una aplicación Desktop ¿para qué los EJB si todo lo podemos programar en las clases Swing? Pero si queremos una aplicación que sea funcional tanto en Web como en Desktop, donde la lógica de negocio debe ser la misma, y si se cambia la forma de realizar alguna rutina debe ser reflejada en en las dos aplicaciones. ¿qué hacemos? ¿Aún no está claro lo que hablo? Bueno, vayamos directo a la aplicación. Haciendo una aplicación Web que calcula áreas Supongamos que queremos una aplicación web llamada AreasWeb que haga cálculos de área geométricas: el área del círculo, del pentágono regular, del triángulo y del trapecio. Los parámetros que necesitamos son los siguientes: Para calcular el círculo necesitamos el radio . Para el pentágono, la altura Para el triángulo, la base y la altura Y para el trapecio, la base menor , la base mayor y la altura...

Uno de los puntos fuertes e importantes de programar con Java Enteprise es la centralización del código de negocio usando EJBs. De esta manera, cualquier aplicación (ya sea web o desde una aplicación cliente desktop) siempre tendrán la misma lógica. El problema era que hasta antes de la versión 3.0 de EJB la programación era realmente pesada. Aprender lo que eran los beans de sesión (con estado y sin estado), crear interfaces y usar clases como javax.ejb.SessionBean , codificando los archivos de despliegue (y que eran diferentes entre los diferentes contenedores como JBoss, Jonas, etc) y no sé que tanto más... era un lío. Personalmente no me apetecía aprenderlo... ni usando los IDE más sofisticados como NetBeans, JBuilder, JDevelopment... nada.. me quedaría programando en web y listo. Pero no pude huir fácilmente... aún la necesidad de utilizar un solo código de negocio para varias aplicaciones me rondaba. Hasta que salió el Java EE 5. Tuve mis dudas, pensé que sería lo mismo que ant...