Apuntes de Java

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

Este es un extracto de un .xml para Spring Framework que crea un DataSource y lo pone al iBatis para implementar DAO. <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"> <!-- obtengo el .properties con las variables que tiene los datos de la conexion --> <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> <property name="locations"> <value>classpath:net/andesconsulting/resources/database.properties</value> </property> </bean> <!-- creo el datasource --> <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method=&

He creado una biblioteca que maneja archivos DBF desde Java. Las funciones básicas que se puede hacer son: Abrir (claro está) archivos DBF, ya sea de Fox 2.x ó 3. Agrega registro en blanco Lee y escribe datos en los registros. Obtiene un registro Navega de registro en registro Obtiene los tipos de cada campo Se puede obtener la biblioteca aquí http://dbf2java-library.googlecode.com/ También se dispone del código fuente para descargar usando subversion. Ah! y está bajo licencia GNU General Public License v3 para quien quiera que desee colaborar, bienvenido sea. ¡ACTUALIZACIÓN! He mudado el proyecto a otro espacio. Más información aquí:  https://www.apuntesdejava.com/2015/05/dbf2java-library-mudado.html

Al crear una clase entidad utilizando el API de persistencia (JPA) con Netbeans, el IDE creará por omisión los ID con las siguientes anotaciones @Id @GeneratedValue(strategy = GenerationType.AUTO) Con ello creará una tabla llamada SEQUENCE donde almacenará el valor del último ID utilizado. Es lo más estándar posible, ya que sabemos que existen RDBMS que no tienen la capacidad de generar un ID autoincrementado (como el Firebird, que necesita de un generator). Pero ¿si uso MySQL, Apache Derby (o un RDBMS que pueda permitir valores de ID autoincrementales)? Pues, si revisamos la documentación de Java http://java.sun.com/javaee/5/docs/api/javax/persistence/GenerationType.html#SEQUENCE dice textualmente " Indicates that the persistence provider must assign primary keys for the entity using database sequence column." entonces, la anotación que necesitamos es @GeneratedValue(strategy = GenerationType.SEQUENCE) Para salir de las dudas, al ejecutar nuestra aplicación, veremos

Como se vió, con el API de Persistencia de Java (Java Persistence API - JPA) se puede mapear todas las tablas de una base de datos como entidades para ser manipuladas desde objetos java. Ahora, ¿qué pasa con entidades débiles? Una entidad débil es aquella que depende su existencia de otra entidad. Por ejemplo, el detalle de una factura no puede existir sin una factura. Si se traslada este concepto a una base de datos, entonces, la clave primaria del detalle de factura será: la clave primaria de la factura a quien pertenece, y el número de orden que se muestra en la lista. Mapear la entidad FACTURA es simple: @Entity public class Factura implements Serializable { @Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name="ID_FACTURA") private Long id; La entidad DETALLE_FACTURA tiene la clave primaria compuesta por dos campos: ID_FACTURA y NRO_ORDEN. En java, toda la clave primara es un objeto con el mismo nombre de la clase primaria más el sufijo "PK". Pero ad

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&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ó

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");