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

JMX es una tecnología que permite la administración y monitoreo de aplicaciones Java. A partir de la versión 6, en el JDK viene incluido el Java VisualVM que es una herramienta que permite monitorear visualmente las aplicaciones Java en la máquina virtual. Lo pueden encontrar dentro de la carpeta bin del JDK. Cuando lo ejecutan, pueden ver como se está ejecutando las aplicaciones en Java, sus clases, qué tipo de objeto es el que está usándose más, etc. Es muy recomendable usarlo para mejorar el rendimientos de las aplicaciones. Tomcat también puede ser monitoreado desde Java VisualVM, pero encontré un detalle si ejecuto el Tomcat en modo servicio de Windows: no puedo conectarme desde el Java VisualVM. La solución es simple: modificar la configuración del servicio de Tomcat. Ejecutamos el tomcat7w.exe desde el servidores, y nos mostrará la configuración del servicio Tomcat. En la sección "Java" agregar estas líneas en la sección "Java options" -Dcom.sun.ma

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.

Apache ha lanzado Tomcat 7.0, con compatibilidad para Servlet 3.0, JSP 2.2, EL 2.2 Se puede descargar desde aquí: http://tomcat.apache.org/download-70.cgi Y más documentación, aquí: http://tomcat.apache.org/tomcat-7.0-doc/

En Sun InnerCircle se publica un interesante artículo que compara Glassfish con Tomcat. En inglés: http://www.sun.com/emrkt/innercircle/newsletter/0209/feature-itm.html En español: http://mx.sun.com/emrkt/innercircle/newsletter/0209/feature-itm.html?cid=e7959f Para empezar, lo que siempre digo cuando me preguntan: Tomcat es solo Web, y Glassfish es web y muchas cosas más. Pero para la gente terca que aún no entienden que no son la misma cosa, va este artículo para ver si así dejan de preguntar :)

Quizás el Tomcat no es muy bien visto porque no tiene una interfaz de administración tan amigable como el de IIS. Pero esto es totalmente falso. Desde las primeras versiones, Tomcat ha tenido un administrador vía web. Pero por razones de seguridad el acceso era bloqueado. Quizás todos los hemos visto, pero no le hemos dado importancia. Cuando iniciamos el tomcat, se nos muestra una página como esta. Vemos un bloque llamado "Administration" y dentro un enlace que dice "Tomcat Manager". Y cuando se trata de ingresar allí, pide un usuario y una clave que ignoramos. Pues bien, si vemos en esta misma página, está la explicación. Editemos el archivo $CATALINA_HOME/conf/tomcat-users.xml y agreguemos una línea como esta: <?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="manager"/> <role rolename="admin"/> <user username="admin" password="admin" roles="admin,manager&q

Cuando ejecutaba el tomcat 5.5 sobre Ubuntu, de manera local (desde el usuario) las aplicaciones se ejecutaban correctamente. Pero cuando quería correrlo desde un demonio como parte del sistema, siempre mandaba un error de seguridad. Después de revisar por ahí, encontré que el ubuntu pone algunas seguridades sobre las acciones desde el tomcat. Edité este archivo /etc/tomcat5.5/policy.d/50user.policy y agregué lo siguiente: grant codeBase "file:/var/lib/tomcat5.5/webapps/ mi-aplicacion-web /-" { permission java.security.AllPermission; permission java.net.SocketPermission "127.0.0.1:3306", "connect,resolve"; permission java.net.SocketPermission "*.noaa.gov:80", "connect"; permission java.io.FilePermission "/var/lib/tomcat5.5/webapps/ mi-aplicacion-web /WEB-INF/logs-", "read,write,delete"; }; ... y vaya que resultó

Después de revisar varios ejemplos, probar y probar, logré encontrar una configuración para usar Realm con el ActiveDirectory de Windows. Esta es la configuración que usé: <Context path="/ldap" > <Realm className="org.apache.catalina.realm.JNDIRealm" connectionURL="ldap://med_spdom01" debug="99" userPattern="{0}@meduca.gob.pe" roleBase="OU=Politicas,DC=meduca,DC=gob,DC=pe" roleName="cn"/> </Context> Como se ve en userPattern, le estoy poniendo el dominio del usuario. Primero había probado logearme con ese formato en la ventana de inicio de sesión del windows. Al momento de escribir el árroba (@) en el nombre de usuario, la lista de dominios se me desactiva. Ya no hacía falta especificar el dominio. Con esa premisa fue que intenté utilizar el mismo formato para el Realm en el Tomcat

Para generar XLS generalmente se usa el Jakarta POI (en java), pero para web es mejor engañar al navegador. El navegador recibe como cabecera el tipo del archivo (mime-type) que está recibiendo y sabrá qué programa abrir. Si es de tipo text/html, abrirá el mismo navegador, pero si es un video tendrá otro tipo y le pedirá al sistema operativo abrir el reproductor de vídeo correspondiente. Para el caso de XLS es lo mismo, y como el Excel puede abrir hasta html, entonces lo engañaremos con más facilidad: Al inicio del JSP colocaremos esta línea: <%@page contentType="application/vnd.ms-excel"%> Con esto, cuando se acceda al .jsp abrirá el contenido con el excel. Pero si se estuviese usando el Internet Explorer, el xls saldrá incrustado en el navegador. Esto puede ser molestoso. Lo que podemos hacer es que se le pregunte al navegador si desea abrirlo o descargarlo. Colocaremos las siguientes líneas: <%@page contentType="application/vnd.ms-excel"%> <%respon

El Tomcat utiliza - por omisión - el puerto 8080 para mostrar los contenidos web. Se puede cambiar el puerto de salida en el archivo $CATALINA_HOME/conf/server.xml de 8080 a 80, para que el acceso sea más simple y evitar escribir un "apellido" como http://midominio :8080 /sistemaweb/. Pero quizás en nuestro host también estemos utilizando el apache para publicar otras aplicaciones que no son necesariamente jsp/servlet. Es posible hacer que todas las peticiones que reciba el apache a un determinado "directorio" sea redireccionado al tomcat, para que este lo atienda y envie su respueta al cliente através del Apache. Hay dos maneras para lograr esto: con el ProxyHTTP y con el conector AJP. En este mensaje mostraré cómo se utiliza el AJP. En este diagrama se muestra como funciona el AJP. Por omisión utiliza el puerto 8009 localmente. Paso 0: descargar el conector: El conector se puede encontrar en el sitio web de Tomcat . Debemos escoger el jk1.2( el jk2 es obsoleto). S

"Normalmente", cuando un newbie en desarrollo hace su aplicación web y lo quiere publicar, suele colocarlo junto con los documentos del servidor web. Por ejemplo, si se tratase de PHP en Apache, lo coloca dentro de DocumentRoot; y si es Tomcat, en $CATALINA_HOME/webapps. Esto es normal, pero es algo desordenado tener la aplicación dentro del sistema que lo ejecuta. (Recuerdo que los perfiles de usuario en Windows NT estaban dentro del directorio Windows, si se instalaba nuevamente el sistema operativo, todos los perfiles se borraba. A partir del Windows 2K, los perfiles se guardan en un directorio a parte llamado "c:\Document and Settings"). Esto se puede hacer en Tomcat. Si deseamos cambiar de contenedor web (a una versión superior, o cambiar de propietario), los módulos web seguirán en el mismo sitio. Lo principal es tener todos los módulos web en un directorio aparte, que lo podamos identificar tan fácilmente como el "Document and Settings" del Windows.

La documentación del Tomcat Native dice que se puede encontrar esa biblioteca en el directorio $TOMCAT_HOME/bin.. pero cada vez que inicio el tomcat me aparece la advertencia "se encontró la versión 1.1.3, considere actualizarlo a una versión superior al 1.1.4"... pero debería venir eso con el tomcat!.. je, encontré un servidor mirror con esos archivos: http://tomcat.heanet.ie/ Aunque ahora que lo pienso... creo que debí examinar su sección " browse download area " de la sección " Tomcat connectors downloads ". ¡AH! no olvidar bajar el APR ( Apache Portable Runtime ) y compilarlo antes de compilar el Tomcat Native Library . Asegurarse que sea la última versión. Si viene el APR de un RPM (como en CentOS o Fedora), desinstalarlo antes.