Apuntes de Java

En este vídeo cómo instalar el Apache NetBeans 10 y también configuarlo para que funcione con Jakarta EE. Los archivos descargados son los siguientes: Apache NetBeans 10:  https://netbeans.apache.org/download/index.html Apache Tomcat 8:  https://tomcat.apache.org/download-80.cgi Payara 5:  https://www.payara.fish/software/downloads/all-downloads/ También deberíamos tener instalado tanto el Java 8, como el JDK 11. El IDE necesita del JDK 11, y los servidores como Payara, Tomcat necesitan de Java 8, es por ello que lo tengo preinstalados. La instalación de JDK 11 es bastante simple: Descargar de aquí el .zip  https://jdk.java.net/11/ Descomprimir el .zip.. y listo. Para el Java 8 (si estamos en Windows) se tendría que descargar de la página de oracle ( https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html ) e instalarlo como un software de Windows. O.. (mejor aún) descargar la distribución de Amazon: Amazon Corretto 8:  https:/

En este post veremos una aplicación Java Web donde la conexión a la base de datos se hará usando Spring, y también veremos cómo manipular la data con JDBC y con JPA. Todo esto lo ejecutaremos desde Tomcat.

Todas las aplicaciones en Java EE va a necesitar - al menos - una conexión a una base de datos relacional. Según el Diseño de Patrones, la conexión a base de datos debe estar fuera de la aplicación que estamos construyendo. Según el estándar de Java EE, la conexión a la base de datos debe estar basada en un Pool de Conexiones y que esté administrado por el Contenedor Java EE. Esta conexión a la base de datos es a través de los DataSource del Contenedor Java EE. En este post veremos que existen tres maneras para implementar un DataSource, con sus ventajas y desventajas, dependiendo de lo que uno desea para su propia implementación.

Si estás tratando de programar RESTful con Jersey sobre Tomcat (porque el Tomcat es más fácil de desplegar y más ligero, Jersey es el más recomendado por Oracle, y RESTful luce bien) y justo cuando quieres probar que devuelva un objeto simple que has creado, lanza el siguiente error: 26-Feb-2016 16:54:00.889 SEVERE [http-nio-18080-exec-2] org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo MessageBodyWriter not found for media type=application/json, type=class... Optas por alguna de estas opciones: Dejas Tomcat porque sabes que, como no es un JavaEE Container, migras a JBoss, Wildfly o lo que sea.. pero Tomcat no lo vuelves a usar porque solo es para web. Ya no usas Jersey, y cuando migras usas algo como SimpleREST de JBoss O usas Spring y te llenas de documentación solo para montar un RESTful simple. Por lo que finalmente dejas de lado tu primera motivación: Tomcat + Jersey. Ahora bien, vamos a revisar qué ocurr

En este post veremos de qué se trata el Spring MVC (como para descansar un poco de JSF). No es que sea JSF mejor que MVC ni viceversa. Sino es para conocer ambas propuestas. Además, en el nuevo Java EE 8 aparecerá un framework llamado MVC 1.0 que lucirá mucho al Spring MVC. (Igual que JPA a Hibernate)

Por la mala experiencia que tengo con los instaladores en Windows, prefiero que los aplicativos sean unos archivos que se puedan descomprimir. Si no hay más remedio que instalarlos, pues lo hago. NetBeans tiene una versión "portable" siendo el instalador un archivo .zip con todo el IDE dentro. Lo bueno de esto es que el mismo .zip puede ser ejecutado en cualquier plataforma que tenga instalado el JDK. (Ese es el gran motivo por lo que uso poco el Eclipse). Lo malo de esto es que no incluye los servidores Java EE. Es algo obvio el motivo, ya que el instalador nativo genera todos los archivos y configuraciones necesarias para que el IDE funcione.... en cambio un .zip solo contiene el contenido. Pero no hay de qué preocuparse, porque podemos configurar el NB con un Tomcat, GlassFish y demás servidores, sean nuevos, o existentes. Aquí hablaremos un poco de esto.

¿Para qué usar Apache con Tomcat si Tomcat ya es un servidor web? Pues bien, sabemos que el Tomcat utiliza el puerto 8080, y el Apache 80. Bastaría con que cambiemos el puerto del Tomcat a 80 y listo, los url deberían ser de la forma http://midominio.com y ya no http://midominio.com:8080 Sabemos que es más elegante evitar que la dirección no tenga puerto. Pero, si tenemos una aplicación en PHP o Python que necesariamente debe correr en Apache ¿qué hacemos? Creamos un subdominio de la forma http://app1.midominio.com http://app2.midominio.com Pues, no está mal. Lo pondré más especial: no se van a crear subdominios, sino, que todo debe estar dentro del dominio principal, como sub carpetas.  Así, por ejemplo: http://midominio.com/app1.python http://midominio.com/app2.php http://midominio.com/app3.tomcat y.. algo más divertido... le agregamos otro contenedor java totalmente diferente http://midominio.com/app4.weblogic Entonces, ya tenemos un pequeño problema ¿cómo hacemos p

Este es un post pequeño, y quizás un poco fastidiado por algo que encontré en esta nueva versión de Liferay 6.1 GA2 (es decir, la 6.1.1) Para crear un JSON WebService, basta con crear un Service en el Portlet y ya está publicado. (Leer aquí  http://www.liferay.com/community/wiki/-/wiki/Main/JSON+Web+Services ) Si usamos Tomcat, no existe ningún problema. Es más, podemos ver el API WebService en una web para hacer las pruebas desde la misma web. Por ejemplo: si creamos un portlet llamado "Test-portlet" y creamos un servicio llamado "Calc", podemos entrar a http://localhost:8080/Test-portlet/api/jsonws y vemos todo el API. Pero... si usamos el GlassFish, no aparecerá la página. Según la gente de LR, cada contenedor tiene manera diferente de reconocer su contexto. Me consta: depuré el código fuente, y desde GlassFish devuelve el contexto "null" mientras que con tomcat devuelve el contexto (o sea, Test-portlet) Y la salida que me dan es llamar a un URL c