Apuntes de Java

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