Apuntes de Java

Este error me sucedían una y otra vez, revisaba los JSP, los TLD (que estaban dentro del .jar y siempre me aparecía ese error According to TLD or attribute directive in tag file, attribute value does not accept any expressions ... no me dejaría resignar en dejar los JSTL solo porque a veces me sale y otras veces puedo evaluar una evaluación como. <c:out value="${1+2}"/> La solución es sencilla: No debo de usar esta declaración del taglib <%@taglib uri="http://java.sun.com/jstl/core" prefix="c"%> Sino esta: <%@taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%>

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...

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ó

El artículo que traduje " Usando el API de persistencia en aplicaciones de escritorio (Introducción) " ahora pasará a la práctica usando NetBeans 5.5 Pues comenzamos por crear un nuevo proyecto llamado Persistence . Luego, crearemos la unidad de persistencia entrando a New | File dentro de la categoría Persistence. Definiremos el nombre de la unidad de persistencia (por omisión usaremos el nombre propuesto: PersistencePU). Recordemos que es una buena práctica utilizar el mismo nombre de la base de datos, aunque no necesariamente tengan que ser los nombres. Para la conexión de base de datos, crearemos uno nuevo: Podemos usar cualquier base de datos. Naturalmente debemos contar con el driver para el JDBC. Yo utilizaré el Firebird, por tanto los valores de la conexión a la base de datos son como sigue: Ahora vemos que creó el archivo persistence.xml dentro de META-INF, además ya tiene los valores de la plantilla como se mencionó en el artículo: Ahora, entraremos a New | File ...

Los arreglos nos ayudan mucho en la programación... se puede almacenar muchos valores en una misma variable, y se pueden diferenciar a través del índice. En la web (utilizando Struts 1), es posible que necesitemos campos variables que funcionen como arreglo. Es decir, un mismo formulario que tenga una vez 10 campos, la siguiente vez 15, y la siguiente 2 campos. Para ello, nuestro ActionForm deberá tener un campo arreglo: public class Formulario extends ActionForm { private String[] pregunta=new String[10]; public String[] getPregunta() { return pregunta; } public void setPregunta(String[] pregunta) { this.pregunta = pregunta; } Y en la capa de presentación (o sea, en el JSP) deberá mostrarse cada campo con un índice: Pregunta 1:<html:text property="pregunta[0]"/><br/> Pregunta 2:<html:text property="pregunta[1]"/><br/> Pregunta 3:<html:text property="pregunta[2]"/><br/> Si se está usando un DynaActionForm, la so...

(Traducción no oficial de Using the Persistence API in Desktop Applications ) La especificación JSR220 define los EJB 3.0. Uno de los primeros objetivos es la simplicidad en la creación, manejo y almacenamiento de beans de entidad. Trabajando hacia la meta, Sun Microsystems y la colaboración de la comunidad de desarrolladores crearon un nuevo API que te permite usar los antiguos objetos de java (o POJOs) como entidades persistentes. El API de persistencia Java te facilita en el uso de POJOs como beans de entidad y reduce significativamente la necesidad de descriptores de despliegues complciados y beans ayudatnes extras. Adicionalmente, puedes usar siempre el API en aplicaciones de escritorio. Puedes describir muchas razones por la que deberías usar el nuevo API de persistencia, pero aquí hay algunas: No tienes que crear complejos objetos de accesos a datos (DAO). El API te ayuda manejar las transacciones. Escribes código basado en estándares que interactuan con la base de datos relacio...

Recién me doy cuenta. Resulta que al hacer una aplicación en Eclipse importando el archivo blank.war de Struts 1.x, no podría usar expresiones como ${variable} si desea mostrar directamente en un .JSP el valor de esa variable de sesión. El lenguaje de expresiones (más conocido como EL) está disponible recién en la versión 2.4 de JSP . La versión que importé del archivo blank.war era la 2.3. Entonces ¿dónde cambio la versión de la especificación? Pues en el archivo web.xml El que importé decía esto: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> ... Por tanto, para cambiar la versión de la aplicación, debería cambiar con lo siguiente <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XM...