Apuntes de Java

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

Ahora con todo eso de las aplicaciones web enriquecidas, y que las interfaces web no deberian recargarse del todo cuando se hace un pequeño cambio, pues aquí pongo un script (en javascript, obviamente) que permite agregar y quitar INPUT-TEXT según sea el gusto. <fieldset id="alternativas"> <legend>Alternativas</legend> <input type="Text" id="alt1" name="alternativa" size="100"/><br/> <input type="Text" id="alt2" name="alternativa" size="100"/> </fieldset> <input type="Button" value="Agregar alternativa" onclick="agregar_alternativa()"/> <input type="submit" value="Guardar"/> <script type="text/javascript"> function agregar_alternativa(){ var fieldset=document.getElementById("alternativas"); var inputs=document.getElementsByName("alternativa"); ...

Hice una vez un algoritmo para extraer pedazos de una cadena y pasarlo por la clase Calendar para obtener la fecha. Pero creo que son muchos pasos. Pues bien, creo que la siguiente manera deberá ser la más sencilla. Supongamos que tenemos la cadena "1976/03/27" y queremos convertirlo a java.util.Date. Pues este será el código: DateFormat df=DateFormat.getDateInstance(DateFormat.SHORT,Locale.JAPAN); Date d=df.parse("1976/03/27"); Uso el Locale.JAPAN por qué sé que ellos usan ese formato (yyyy/mm/dd) para las fechas.