sábado, 24 de septiembre de 2011

Instalación de Oracle ASM 11g sobre redhat 5.7 Desktop virtualizado




1 Instalación de VirtualBox 4.1.2 sobre Ubuntu 10.0.4

  1. Se agrega en Synaptic, el repositorio correspondiente:
    deb http://download.virtualbox.org/virtualbox/debian lucid contrib non-free
  2. Del sitio web de VirtualBox se descarga la clave pública oracle_vbox.asc, y se la agrega al sistema:
    sudo apt-key add oracle_vbox.asc
  3. Se procede con la instalación:
    sudo apt-get update
    sudo apt-get install virtualbox-4.1

2 Instalación de RedHat Enterprise 5.7 – Desktop

2.1 Creación de la máquina virtual

Se crea la máquina virtual con opciones por defecto, pero los archivos de VirtualBox se deben ubicar en una unidad con 100GB aproximadamente en el sistema anfitrión; para esto sugiero montar una partición en una ubicación como /datos.
La memoria que se debe asignar a la máquina virtual debe ser de 2.9GB al menos, para soportar la infraestructura Oracle que se va a instalar y la instancia standalone del curso. Se le asigna un procesador y 128MB para vídeo.
Únicamente se debe tener atención de los siguientes puntos para evitar advertencias y mantener un desempeño aceptable.

2.1.1 Creación del disco para el SO

Para el sistema operativo que se va a instalar se crea una unidad de expansión dinámica en el formato nativo de VirtualBox, con un tamaño máximo de 20GB.

2.1.2 Configuraciones adicionales

Una vez creada la máquina, se activa la caché de E/S para el disco de la máquina, y se agrega el usuario del sistema operativo anfitrión al grupo vboxusers mediante el comando:
sudo usermod -a -G vboxusers oracle
Donde oracle es el usuario anfitrión. Finalmente, se debe instalar el paquete de adiciones para el anfitrión:
Oracle_VM_VirtualBox_Extension_Pack-4.1.2-73507.vbox-extpack
El cual puede ser descargado del sitio de VirtualBox, y debe coincidir en versión con la distribución instalada de VirtualBox.
Para la instalación del paquete de extensión se debe primero asociar el binario descargado (Oracle_VM_VirtualBox_Extension_Pack-4.1.2-73507.vbox-extpack) a la instalación de VirtualBox (menú archivo > preferencias > extensiones) y luego usar el menú de la máquina virtual en ejecución, la opción “Install Guest Additions”. Esto monta una imagen en la máquina huesped, que contiene entre otros ejecutables el archivo VboxLinuxAdditions.run, el cual debe ejecutarse como root luego de haber afinado el sistema hasta llegar la sección 3.6 del presente documento.

2.2 Instalación del SO

El sistema operativo se instala con las opciones por defecto para la configuración de red, se deshabilitan las opciones de corta fuegos y de seguridad adicionales, así como se omite cualquier opción de cifrado.
Se omiten también la instalación de paquetes de sonido y de oficina, para conseguir mayor espacio disponible.
La configuración de particiones sobre el disco de 20GB creado incluye 1 partición SWAP de aproximadamente 3848MB , y el resto de espacio para el montaje del sistema de archivos de Linux ( / ).
La contraseña para root será “oracle”, y se creará un usuario oracle con contraseña “oracle”. En general y por tratarse de un curso, la contraseña que se utilizará para todo siempre será “oracle”.
Durante la instalación se deshabilita el corta fuegos del servidor, ya que se requerirá realizar una gran cantidad de operaciones que podrían fallar si el corta fuegos estuviera habilitado.

3 Instalación de Oracle Grid Infrastructure

La Infraestructura de Grilla de Oracle para un servidor standalone, es software de soporte para la base de datos, ASM (sistema de archivos y manejador de volúmenes) y para Oracle Restart.

3.1 Requisitos de memoria

  • Mínimo recomendado para memoria RAM (Infraestructura + Server): 2.5GB
  • Valor recomendado para memoria RAM (Infraestructura + Server): 4GB
  • SWAP para memoria de 2GB a 16GB, en igual tamaño que la memoria RAM.


Comandos importantes:
free – para conocer el estado de la memoria
grep MemTotal /proc/meminfo – para conocer el total de memoria real
grep SwapTotal /proce/meminfo – para conocer el total de memoria SWAP

3.2 Requisitos de espacio en disco

  • Para la infraestructura, 2.3GB libres bajo /
  • Para el proceso de instalación, 1GB en /tmp


Comandos importantes:
df -kh – para conocer el espacio disponible en disco

3.3 Configuración del ambiente

3.3.1 Configuraciones básicas

Se deberán seguir las siguientes acciones:
  • Si no lo estuviera, se debe habilitar el usuario root, lo cual generalmente se podría hacer con el comando.
    $> sudo passwd root
    En sistemas redhat el usuario root se configura durante la instalación del SO.
  • Crear la variable $ORACLE_BASE. Para esto se deben agregar las siguientes instrucciones al final del archivo /etc/bashrc (archivo de comandos invocado por no-login shells):
    ORACLE_BASE=/u01/app/oracle
    export ORACLE_BASE
  • En el archivo ~/.bash_profile se incluyen las siguientes instrucciones:
    ORACLE_HOME=$ORACLE_BASE/product/11.2.0/grid
    ORACLE_SID=+ASM
    PATH=$PATH:$ORACLE_HOME/bin
    export ORACLE_HOME ORACLE_SID PATH
  • Establecer umask1 a 022 para el usuario dueño de la instalación (en este caso oracle), con esto se asegura que el programa de instalación creará archivos con permisos 755 (u:111 – g:101 – o:101; o lo que es lo mismo, 0 : rwx – 2 : rx – 2 : rx ), es decir, con esto se asegura que los archivos que crea el usuario dueño de la instalación son seguros (root tiene umask 022, un usuario en general tiene 002).
    Para saber cuál es el modo del usuario actual se usa2:
    $> umask -S
    Para establecer el modo para el usuario, se considera el orden de llamadas de scripts para login shells, dado que la instalación se realizará con el usuario oracle, por esta razón se modifica el archivo /etc/bashrc.
    $> su
    $> gedit /etc/bashrc
    Se agrega el siguiente código luego de las instrucciones de inicialización de umask originales del script:
    if [$UID = 500]; then
      umask 022
    fi
  • Los recursos disponibles para el usuario oracle se pueden ver con el comando ulimit3:
    $> ulimit -a
    Para poder realizar la instalación de la infraestructura, se requiere que el máximo de descriptores de archivos abiertos sea de al menos 65536. Este valor se debe modificar para el usuario oracle editando el archivo /etc/security/limits.conf:
    $> su
    $> gedit /etc/security/limits.conf
    En el cual se agregan las siguientes líneas:
    oracle soft nofile 4096
    oracle hard nofile 65536
    Lo cual permite que se pueda ejecutar desde el archivo ~/.bash_profile el comando
    ulimit -n 65536
    Estos cambios se aplican con el reinicio del sistema. Una buena referencia de estas configuraciones se puede revisar en http://www.puschitz.com/TuningLinuxForOracle.shtml.

3.3.2 Parámetros del núcleo

  • Los parámetros del núcleo recomendados para una instalación standalone 11g son:
kernel.shmall = 2097152
kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 6815744
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 4194304
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
fs.aio-max-nr = 1048576
  • Los parámetros del servidor pueden ser revisados ejecutando el comando
    $> /sbin/sysctl -A
  • Para modificar los parámetros que no coincidan con lo recomendado por Oracle, se debe modificar el archivo /etc/sysctl.conf, y una vez hechas las modificaciones se debe ejecutar el comando indicado a continuación (para que los cambios apliquen sin necesidad de reiniciar el servidor):
    $> /sbin/sysctl -p

3.3.3 Usuarios, grupos y variables

  • Para poder instalar la instancia de ASM y la infraestructura, se requiere crear un usuario y grupos con privilegios determinados. Considerando que durante la instalación del SO (sección 2.2) se creó ya un usuario oracle, únicamente se agrega el usuario a los grupos creados (si el usuario no existiera, se usaría el comando ./useradd -g oinstall -G dba oracle):


$> su
$> cd /usr/sbin
$> ./groupadd -g 1000 oinstall
$> ./groupadd -g 1200 dba
$> ./usermod -g oinstall -G dba oracle
$> mkdir -p /u01/app/11.2.0/grid
$> mkdir -p /u01/app/oracle
$> chown -R oracle:oinstall /u01
$> chmod -R 775 /u01


    Los identificadores para usuario y grupos son recomendados, pero por seguridad, se pueden listar los usuarios del sistema revisando el contenido del archivo /etc/passwd4:
$> cat /etc/passwd | grep home
En el caso documentado por el presente documento, el usuario oracle tendrá ya un identificador, que se puede mantener.

3.3.4 Configuración de red

  • El SO necesita una dirección IP fija, y una interfaz de loopback5 (que en sistemas RedHat es configurada por defecto, así como el nombre por defecto del servidor6). Si la dirección del servidor estuviera siendo asignada por DHCP, es conveniente establecerla como fija; para conocer la información general de las interfaces de red del equipo se utiliza el comando:
$> ifconfig


  • Para conocer la dirección del gateway (necesaria para la configuración fija), se utiliza el comando:
$> route -n
Cuya salida incluirá una entrada marcada como UG (up / gateway).


  • Además, de asignar un IP estático al equipo, se debe modificar el archivo /etc/hosts, para registrar dicho IP y asociarlo a un nombre con el cual se registrará el equipo durante la instalación:
    $> su
    $> gedit /etc/hosts
    Agregar en el archivo de hosts:
    IP_CONFIGURADO server11gNNAA


En donde NNAA podrían ser las iniciales de los nombres y apellidos, e IP_CONFIGURADO es el número que se asignó en el paso anterior.
  • Para reiniciar las interfaces de red del servidor, se usan los comandos:
$> su
$> /etc/init.d/network restart
  • Hechos los cambios en la configuración de red, es posible que el servicio sendmail tarde varios minutos en levantarse al no poder ubicar un DNS, lo cual repercute en el tiempo de inicio del sistema operativo. Esto puede ser atendido modificando el nivel de ejecución del servicio sendmail, mediante el comando7:
    $> su
    $> /sbin/chkconfig --level 5 sendmail off

3.3.5 Configuración del driver para las librerías de ASM

  • El software dependerá de la versión del núcleo del SO. Para conocer cuál es la versión del núcleo, se ejecuta el comando:
$> uname -rm
  • Dependiendo del valor mostrado, se descargarán del sitio de Oracle las librerías apropiadas. Por ejemplo, si la ejecución del comando retorna:
$> uname -rm
$> 2.6.18-274.el5 i686
  • Se deberán descargar del sitio de Oracle los ejecutables que correspondan exactamente:
oracleasm-support-2.1.7-1.el5.i386.rpm
oracleasm-2.6.18-274.el5-2.0.5-1.el5.i686.rpm
oracleasmlib-2.0.4-1.el5.i386.rpm
  • Para instalar el software se deben colocar los archivos en un directorio al cual se pueda acceder y se los instala como root. Se utiliza el comando siguiente:
    $> /bin/rpm -Uvh oracleasm-support-2.1.7-1.el5.x86_64.rpm \ oracleasm-2.6.18-274.el5-2.0.5-1.el5.x86_64.rpm \ oracleasmlib-2.0.4-1.el5.x86_64.rpm
  • Para inicializar ASM se requiere conocer el ID del usuario dueño de la instalación y el grupo al cual pertenecerá la interfaz de ASM que se está instalando (el driver):
    $> id oracle
  • Para realizar la configuración se debe ejecutar:
    $> /etc/init.d/oracleasm configure
Los valores que se utilizarán son:
UID: el ID del usuario oracle
GID: el ID del grupo dba creado en el numeral 3.3.3
Iniciar el driver al iniciar el SO:
Escanear por discos ASM al arrancar el SO:

3.4 Oracle ASM – definiciones

Software de la base de datos Oracle (Oracle Installation Software): El software de una instalación de servidor de bases de datos Oracle.
  • Oracle Configuration Asistant (OCA): Programa de creación y configuración de bases de datos.
  • Oracle Restart: Software que permite el reinicio automático de la instancia de base de datos, Oracle Net Listener, Servicios de la base de datos, y OASM.
  • Oracle Automatic Storage Management (OASM): Software especializado, manejador de volúmenes y sistema de archivos que soporta instalaciones de una sola instancia e instalaciones tipo clúster.
  • Oracle Automatic Storage Management Cluster File System (OACFS): Permite trabajar a ASM en ambientes tipo cluster tanto como en ambientes de una sola instancia.
  • Oracle Automatic Dymanic Volumen Manager (OADVM): Manejador de volúmenes que utiliza OASM.
  • Oracle ASM Configuration Asistant (OASMCA): En versiones 10g, la configuración de ASM estaba delegada al OCA. En versiones 11g existe este programa para dicho fin. OASMCA es parte de Oracle Grid Infraestructure.
  • Oracle Grid Infraestructure: Software de Oracle que provee soporte a nivel de sistema para OASM. OACFS, Oracle Restart y para el software de la base de datos en sí mismo.


3.5 Consideraciones para la instalación de OASM

  • ¿Se va a utilizar ASM para DB files? ¿Para recovery files? ¿Para ambos? Esta alternativa se puede decidir durante la creación y configuración de una base de datos cuando se realiza esto en modo AVANZADO.
  • ¿Qué nivel de redundancia se va a utilizar? ASM provee 3 niveles:
  • Redundancia externa: Oracle ASM no refleja los contenidos de sus grupos de discos. Se recomienda esta opción cuando el SO provee redundancia por RAID.
  • Redundancia normal: A este nivel ASM provee por defecto espejamiento de dos vías para archivos de datos (data files) y de tres vías para archivos de control (control files), aunque esto puede ajustarse a un menor nivel si fuese lo requerido. Para usar redundancia normal, se requieren al menos dos grupos de discos de fallo (dos dispositivos de disco). El espacio efectivo disponible en disco en un esquema de este tipo, es igual a la mitad de la suma del espacio disponible en ambos discos.
  • Alta Redundancia: Se requieren al menos tres grupos de discos de fallo (tres dispositivos) y el espejamiento se realiza en tres vías para data files y en cuatro vías para control files.
  • ¿Cómo configurar los grupos de discos (failure groups)? Conceptos relevantes relacionados con alta disponibilidad de discos pueden encontrarse en:
  • Considerando lo anterior, y si existieran discos candidatos para la instalación de ASM, se debe cuidar que:
  • El dueño de la instalación de ASM debe ser también dueño de los dispositivos (de los discos, como /dev/sdb1 por ejemplo).
  • Aunque es posible instalar ASM sobre particiones hechas sobre un disco, lo recomendado por Oracle es usa discos para conformar los grupos de discos de ASM.
  • Todos los dispositivos de un mismo grupo deben tener la misma capacidad y el mismo desempeño.
  • ¿Se puede usar LVM con ASM? Oracle recomienda no hacer esto, pues ASM es en sí un manejador de volúmenes.


3.6 Configuración previa a la instalación de OASM

Si se han revisado y cumplido los pasos descritos en las secciones 3.1 a 3.5, se puede proceder a instalar OASM.
  • Atendiendo lo recomendado, se agregan a la máquina virtual 2 discos de tamaño fijo sobre el controlador SATA existente. Cada disco tiene 8GB de espacio. El SO reconoce los nuevos discos al ser iniciado.
  • Para verificar el estado de los discos, se ejecuta el comando /sbin/fdisk -l como root. Los discos no inicializados aparecerán sin una tabla de particiones válida, nombrados como /dev/sdb, dev/sdc, etc.
  • Para cada disco disponible (/dev/sdb, /dev/sdc, etc), se utiliza el siguiente comando para su inicialización:
    $> /sbin/fdisk /dev/sdb
    Las opciones del diálogo de consola que se utilizan son:
    n (nuevo)
    p (primary partition)
    default (primer cilindro)
    default (último cilindro)
    w (fin de comando)
    Hecho esto se habrán creado particiones primarias no formateadas en cada disco. Por ejemplo, para el disco /dev/sdb se creará la partición /dev/sdb1.
  • Para crear los discos para ASM se ejecutan los comandos:
    /etc/init.d/oracleasm createdisk vol1 /dev/sdb1
    /etc/init.d/oracleasm createdisk vol2 /dev/sdc1
    etc... si se quisieran configurar más discos, en este caso se inicializan y configuran 4 discos.
    El resultado de la ejecución del comando es:
    [root@localhost dev]# /etc/init.d/oracleasm createdisk vol1 /dev/sdb1
    Marking disk "vol1" as an ASM disk: [ OK ]
    [root@localhost dev]# /etc/init.d/oracleasm createdisk vol2 /dev/sdc1
    Marking disk "vol2" as an ASM disk: [ OK ]
    [root@localhost dev]# /etc/init.d/oracleasm createdisk vol3 /dev/sdd1
    Marking disk "vol3" as an ASM disk: [ OK ]
    [root@localhost dev]# /etc/init.d/oracleasm createdisk vol4 /dev/sde1
    Marking disk "vol4" as an ASM disk: [ OK ]
  • El siguiente paso es crear los directorios para la base de datos y para la infraestructura grid. Debe recordarse que se creó anteriormente una variable que concuerda justamente con el directorio para la base de datos ($ORACLE_BASE) y una variable que coincide con la ubicación del software instalado de la infraestructura ($ORACLE_HOME).
    $> su
    $> mkdir -p /u01/app/oracle
    $> mkdir -p /u01/app/oracle/product/11.2.0/grid
    $> chown -R oracle:oinstall /u01
    $> chmod -R 775 /u01
  • El software de instalación se lo debe copiar en el disco duro, lo cual puede hacerse con el usuario oracle, dado que ya se realizó el cambio recursivo de dueño y de permisos sobre /u01:
    $> mkdir -p /u01/app/oracle/stage/grid
    $> mkdir -p /u01/app/oracle/stage/database
    En el directorio grid se copia el software de instalación de la infraestructura, y en el directorio database el software de instalación de la base de datos. Para descomprimir un archivo zip se pude usar el comando unzip.
  • Antes de proseguir con la instalación y considerando que se está utilizando una versión de 32 bits de RedHat Enterprise (uname -a), se debe verificar que los siguientes paquetes estén instalados en el SO:
kernel-headers-2.6.18-274.el5.i386.rpm
kernel-devel-2.6.18-274.el5.i686.rpm
glibc-2.5-65.i386.rpm (para la configuración de este manual debería estar ya instalado)
glibc-headers-2.5-65.i386.rpm
glibc-devel-2.5-65.i386.rpm
gcc-4.1.2-51.el5.i386.rpm
elfutils-libelf-devel-0.137-3.el5.i386.rpm elfutils-libelf-devel-static-0.137-3.el5.i386.rpm *
libstdc++-4.1.2-51.el5.i386.rpm
libstdc++-devel-4.1.2-51.el5.i386.rpm
gcc-c++-4.1.2-51.el5.i386.rpm
libaio-0.3.106-5.i386.rpm (para la configuración de este manual debería estar ya instalado)
libaio-devel-0.3.106-5.i386.rpm
sysstat-7.0.2-11.el5.i386.rpm
unixODBC-2.2.11-7.1.i386.rpm
unixODBC-devel-2.2.11-7.1.i386.rpm
ksh-20060214-1.1.i386.rpm


Muchos de los paquetes no están disponibles en los repositorios de redhat, por lo que deben ser descargados de otros repositorios para la versión Centos OS 5. Son de gran ayuda los siguientes sitios:
(*) Los paquetes elfutils-libelf-devel-0.137-3.el5.i386.rpm y elfutils-libelf-devel-static-0.137-3.el5.i386.rpm son interdependientes, por lo que deben ser instalados en un solo comando:
$> su
$> rpm -Uvh elfutils-libelf-devel-0.137-3.el5.i386.rpm elfutils-libelf-devel-static-0.137-3.el5.i386.rpm

3.7 Ejecución del instalador de la infraestructura

  • Habiendo cumplido lo indicado en los pasos anteriores, se procede a ejecutar el instalador de la infraestructura:
    $> cd /u01/app/oracle/stage/grid
    $> ./runInstaller
  • El asistente guía la instalación a lo largo de 11 pasos, como se muestra en las capturas siguientes:
























  • Se selecciona la instalación de un servidor standalone:










  • Se seleccionan los idiomas para la instalación:










  • Se crea un grupo de discos para datos, por ello se conserva el nombre por defecto DATA. El nivel de redundancia se establece en normal (sección 3.5) y se seleccionan dos discos candidatos puesto que lo recomendado por Oracle para un nivel de redundancia normal es usar al menos dos discos.
  • Si el asistente no encuentra discos candidatos a pesar de haberlos creado y configurado con las librerías del driver de oracle para ASM, se puede cambiar la ruta de acceso de detección hacia el directorio /dev/oracleasm/disks, en donde por defecto ASM incluye los dispositivos configurados.








  • Se utiliza una misma contraseña para las cuentas de administración de ASM: Oracle11










  • Los grupos de usuarios ASM (internos de la instancia) requieren vincularse con un grupo del sistema operativo para autenticarse. Se utiliza el grupo dba creado anteriormente. Si se presenta un mensaje de advertencia se acepta y se prosigue.








  • Dadas las consideraciones de OFA (Oracle Flexible Architecture), se utilizan las ubicaciones para instalación que el asistente plantea por defecto, las cuales concuerdan con las variables de entorno configuradas en la sección 3.3.1. La ubicación por defecto indicada para el inventario de instalación también se puede mantener.








  • El resumen de la instalación que se va a realizar agrega un dato de suma importancia: el espacio en disco. En este punto se puede tomar cualquier correctivo si hiciera falta más espacio en disco o si la cuota del usuario dueño de la instalación no contempla suficiente espacio.
    Tras accionar el botón Terminar se inicia el proceso, mismo que puede durar entre 20 y 30 minutos dependiendo de los recursos del equipo anfitrión. Durante la última etapa del proceso, se solicitará la ejecución de dos scripts.








  • Los scripts pueden ejecutarse con los comandos:
$> su
$> /u01/app/oraInventory/orainstRoot.sh
$> /u01/app/oracle/product/11.2.0/grid/root.sh
El segundo script solicitará que se ingrese la ruta hacia /usr/local/bin.
Tras la ejecución de los scripts se realizan los últimos pasos de la instalación de forma automática.




































  • Una vez finalizada la instalación se presenta la pantalla de confirmación.






4





























1umask: función o comando POSIX que permite establecer la “máscara para el modo de creación de archivos” (file mode creation mask) del proceso actual. POSIX: Portable operative system interface for Unix, conjunto de estándares de la IEEE que definen una API para shells y utilitarios para sistemas basados en UNIX.
2http://www.dba-oracle.com/linux/umask_command_tips.htm
3ulimit y umask son comandos preestablecidos del shell, por esta razón no se usa su ubicación para ejecutarlos.
4Explicación útil en: http://www.cyberciti.biz/faq/understanding-etcpasswd-file-format/
5Interfaz de red interna del servidor 127.0.0.1 (localhost)
6Para conocer el nombre del servidor se puede usar el comando hostname
7El nivel de ejecución de un servicio determina su modo de funcionamiento, el nivel 5 corresponde a la ejecución normal en entorno gráfico. Más información se puede encontrar en este enlace.
Dustin Ghia R.

sábado, 6 de agosto de 2011

Instalación de SQL Developer 3.0.04 sobre Ubuntu 10.04

  1. Para instalar SQL Developer, lo primero será verificar que estén instalados los paquetes debhelper y tofrodos. Esto se lo puede hacer muy fácil con el Gestor de Paquetes Synaptic. Si los paquetes no estuvieran instalados, se los agrega. También se debe tener un JDK, el cual tiene la versión 1.6.0.26 para la presente entrada.
  2. Estando correctamente instalado el paquete tofrodos, se abre un terminal en el directorio /usr/bin y se crean dos enlaces simbólicos mediante los comandos:
    sudo ln -s fromdos dos2unix
    sudo ln -s todos unix2dos
  3. Usando Synaptic o apt, se instala el paquete sqldeveloper-package.
  4. Del sitio de Oracle, se descarga el archivo de instalación de SQL Developer para otras plataformas, el cual es un ZIP. A la fecha de creación de esta entrada el archivo disponible fue sqldeveloper-3.0.04.34-no-jre.zip . Dicho archivo debe ser puesto en un directorio para el cual se tengan permisos de escritura, por ejemplo ~/temporal.
  5. Se crea un paquete en base al archivo de instalación descargado usando el comando:
    make-sqldeveloper-package sqldeveloper-3.0.04.34-no-jre.zip
  6. Para ejecutar el paquete se debe verificar que tenga los permisos necesarios (si no los tuviera se los puede otorgar con sudo chmod u+wx sqldeveloper_3.0.04.34+0.2.3-1_all.deb). El comando de instalación es:
    sudo dpkg --install sqldeveloper_2.1.1.64.45+0.2.3-1_all.deb
  7. Terminada la instalación, el programa será accesible desde el menú principal bajo la opción "Programación". Se deberá proveer la ruta del JDK instalado, por ejemplo "/usr/lib/jvm/java-6-sun".
  8. Generalmente, se lanzará una excepción en la primera instalación, debido a que no existe el directorio "/usr/share/sqldeveloper/sqldeveloper/extensions/oracle.datamodeler/log". Para resolver esto, se lo puede crear como root, y se establece el permiso de escritura para otros usuarios (chmod o+w log)






lunes, 4 de abril de 2011

JEE5 – 2) Configuración y primera aplicación

El presente artículo y los artículos relacionados (JEE) se basan en lo presentado en el libro Beginning Java EE5 (Editorial Apress), en los manuales y tutoriales de Sun/Oracle, y en problemas/soluciones propias.

En esta entrada se realizarán las siguientes tareas:
  • Instalar y configurar Tomcat para trabajar con Eclipse Galileo 3.5.2.
  • Instalar y configurar JBoss 5.1.0 GA.
  • Crear una aplicación básica, desplegarla en Tomcat y JBoss y revisar de manera general su estructura y funcionamiento.
Instalar y configurar Tomcat en Eclipse Galileo
Antes de instalar y configurar de Apache Tomcat, se deben cumplir los siguientes puntos:
  • Instalar Java Development Kit 1.5. La versión que se utiliza en este caso es jdk1.5.0_22, la cual se puede descargar del sitio web de Oracle (jdk-1_5_0_22-windows-i586-p.exe).
  • Configurar la variable JAVA_HOME y agregar el directorio bin de la misma al path del sistema.
  • Configurar la variable JRE_HOME, apuntando al JRE full contenido en la instalación de JDK.
  • Descargar e instalar (descomprimir) Eclipse Galileo 3.5.2.

Puesto que mi sistema es Windows 7 a 64 bits, y dado que he instalado JDK para 32 bits, para poder usar Apache Tomcat 6 con dicho JDK he requerido descargar la distribución binaria de Apache Tomcat para 32 bits: apache-tomcat-6.0.32-windows-x86.zip.

Para instalar Tomcat 6.0.32 de 32 bits (distribución binaria), basta con descomprimirlo y seguir los pasos indicados en el archivo RUNNING.txt. Por defecto, Tomcat se levanta en el puerto 8080, y una vez iniciado debe ser posible validar su funcionamiento accediendo a http://localhost:8080.

Para proseguir, vale verificar que Eclipse utilice el JRE adecuado, lo cual se consigue con el menú [Window > Preferences > Java > Installed JREs].



Para configurar Tomcat en Eclipse, en la vista “Servers”, con el menú contextual para nuevo servidor se inicia el asistente. El nombre del servidor puede estar dado por el IP de la máquina.



El directorio de instalación de apache se denomina CATALINA_HOME, y se utiliza el JRE por defecto del entorno.



Dado que no existen proyectos creados, se pasa esta parte del asistente sin realizar acciones, y se lo finaliza.



Terminado el asistente, se crea un proyecto nuevo llamado “Servers”, el cual debe permanecer abierto para poder agregar proyectos al servidor Tomcat, así como para levantarlo.


Instalar JBoss
Dado que Tomcat es un Contenedor Web (Servlet/JSP) no es apropiado para desplegar EJBs; este trabajo es apropiado para un servidor de aplicaciones como JBoss. La versión que utilizo para este conjunto de entradas es JBoss 5.1.0 GA.

Para instalar y ejecutar JBoss, basta con descargar el comprimido del sitio de JBoss (jboss-5.1.0.GA.zip), y descomprimir el contenido a un directorio con permisos suficientes (En Windows suele ser conveniente hacerlo en una ruta como c:\java\jboss), dicho directorio puede ser llamado JBOSS_HOME.

Proyecto básico
Eclipse IDE cuenta con un sinnúmero de asistentes y poderosas herramientas para crear proyectos web y proyectos JEE; sin embargo, a fin conocer de mejor manera aquello que se está construyendo, se detalla a continuación la elaboración de un proyecto JEE básico, paso a paso y sin asistencia del IDE. El ejemplo original puede ser descargado del sitio web del libro “Beginning Java EE5”.

Construyendo un proyecto JEE básico
En primer lugar, se debe crear un directorio de trabajo, el cual por conveniencia podría estar ubicado dentro del workspace que se vaya a utilizar para Eclipse. Dentro del directorio (JEE501) se agrega una página JSP index.jsp con el siguiente código:

<html>
<head>
<title>
Prueba de la instalacion
</title>
</head>

<body>
<% for(int i = 0; i < 3; i++) { %>
<h<%=i + 1%>> Hola Mundo!!! </h<%=i + 1%>>
<%}%>
</body>
</html>


La página index.jsp será el componente web de la aplicación, para validar su funcionamiento, se la empaqueta en un componente redistribuible de despliegue: holaApp.war

Estando en el directorio de trabajo creado anteriormente (JEE501), usando la consola se ejecuta el siguiente comando:

jar -cvf holaApp.war index.jsp

En donde:
-c: para crear un nuevo contenedor
-f: para que se deba ingresar un nombre para el contenedor
-v: para una salida completa de mensajes en consola

El detalle de las opciones del comando se lo puede obtener ejecutándolo sin argumentos. El resultado es un nuevo archivo war, el cual debe ser copiado al directorio CATALINA_HOME\webapps. Hecho esto, se levanta el servidor Apache Tomcat y se accede a la dirección: http://localhost:8080/holaApp/index.jsp, el resultado debe ser:


Verificación de la instalación de Tomcat y de la creación del primer war

Normalmente un proyecto web tiene más que un archivo trivial, pero la estructura general de un proyecto web se revisará posteriormente, por el momento se ha podido constatar que Tomcat (Servlet/JSP) container ha funcionado perfectamente.

El siguiente paso será empaquetar el war creado (los componentes web) dentro de un ear. Un ear puede contener archivos war, jar, descriptores (archivos xml), etc., todos en el contexto de una misma aplicación empresarial.

Dentro del directorio JEE501, se crea el directorio META-INF, y dentro del mismo, se incluye el archivo application.xml, el cual es el descriptor de despliegue de la aplicación:

<?xml version=“1.0” ?>
<application>
<display-name>Hola JEE</display-name>
<module>
<web>
<web-uri>holaApp.war</web-uri>
<context-root>/hola</context-root>
</web>
</module>
</application>


Para construir el ear, de manera análoga a lo que se hizo con el war, estando en el directorio JEE501 se ejecuta el comando:

jar -cvf holaAppEar.ear holaApp.war META-INF

Para probar el funcionamiento del ear, se lo debe desplegar en el servidor de aplicaciones que se instaló, para hacer esto hay que situarse en JBOSS_HOME\server, allí se encuentran las instancias (configuraciones) que provee el servidor predeterminadamente. Para crear una propia instancia y mantener las existentes sin modificaciones, se puede copiar cualquiera de ellas y renombrar la copia; en este caso, se utiliza como plantilla la instancia default y se crea la instancia “mijee5”.

En el directorio JBOSS_HOME\server\mijee5\conf\bindingservice.beans\META-INF, se encuentra el archivo de configuración bindings-jboss-beans.xml, en el cual se cambia el parámetro que define el conjunto de bindings para uso de la instancia, para que quede de esta forma la configuración:

<parameter>${jboss.service.binding.set:ports-01}</parameter>

Esto resulta útil, puesto que el servidor Tomcat que se configuró utiliza el puerto 8080, y con el cambio indicado en el parámetro, la instancia de mijee5 lo hará en el puerto 8180. Esta configuración también resulta útil para poder levantar distintas instancias de JBoss en una misma máquina al mismo tiempo.

En el directorio deploy de mijee5, se coloca el empaquetado holaAppEar.ear, y estando situado en JBOSS_HOME\bin, se utiliza el siguiente comando para levantar el servidor:

run.bat -c mijee5 -b 0.0.0.0

-c: para indicar cual instancia se va a levantar
-b: para indicar en qué interfaces de red se va a levantar la instancia, 0.0.0.0 es para todas las interfaces

Habiendo seguido los pasos anteriores, el resultado sería:



Consola indicando que la instancia mijee5 se ha levantado correctamente



Página de inicio para la administración de JBoss



La Consola JMX muestra que se han desplegado el ear y su módulo war



La aplicación levantada, nótese que el URL es el contexto raíz indicado en el descriptor application.xml
¿Cómo funciona?
La última pantalla muestra una página web con tres títulos que dicen “Hola Mundo!!!”, si se muestra el código fuente de la página, lo que tenemos es bastante simple:

<html>
<head>
<title>
Prueba de la instalacion
</title>
</head>

<body>
<h1> Hola Mundo!!! </h1>
<h2> Hola Mundo!!! </h2>
<h3> Hola Mundo!!! </h3>
</body>
</html>

La cuestión es, ¿Cómo se transformó el código JSP en el HTML mostrado? Como se mencionó en la primera entrada, “JSP es un lenguaje de plantillas para escribir Servlets”; de hecho, cuando el servidor JBoss recibe una petición de lo que se encuentra en el contexto raíz de su módulo web (holaApp.war, /hola), utiliza sus contendores web, jsp y servlet para generar el código fuente del servlet para la página index.jsp, para compilarlo, cargarlo e instanciarlo, y finalmente es el servlet el encargado de retornar al cliente un flujo (OutputStream) que contiene el HTML que se despliega (el detalle de este punto será retomado en la siguiente entrada).

Como se vio, el war generado pudo desplegarse en Tomcat y podría desplegarse en JBoss de la misma manera; sin embargo, al empaquetarlo en un ear, se posibilita que coexista con lógica que no necesariamente debe residir en “la capa web”, es decir, dentro del war, pero que es parte de la lógica de toda una aplicación.

La estrucutra de archivos del ejemplo es súmamente simple, pues un proyecto real puede ser bastante complejo, no obstante, se cumple un propósito clave con dicha estructura: indicar que en un empaquetado de despliegue existen componentes y archivos de soporte (descriptores, manifiestos, propiedades). En este caso, el empaquetado holaApp.war incluye un componente jsp y un archivo de soporte agregado durante la creación del empaquetado, se trata de un archivo de manifesto, el cual viene a ser como un directorio de contenidos para el empaquetado. Por su parte el ear tiene un módulo web (holaApp.war) y cumpliendo el estándar, dentro de un directorio META-INF tiene el descriptor de despliegue de la aplicación (application.xml), el cual es utilizado por el servidor para saber cómo acceder a los componentes del ear.

Sinópsis y siguientes temas
En el presente documento se ha revisado la instalación y configuración de Apache Tomcat y de JBoss, de manera que ambos servidores puedan trabajar a la vez en una misma máquina. También se ha construido una aplicación JEE elemental, pero útil para explicar lo más relevante sobre su proceso de empaquetamiento y despliegue. Más adelante se revisarán los tópicos más importantes de JSP, con lo cual se conseguirá un sustento sólido para abordar JSF.

jueves, 31 de marzo de 2011

JEE5 - 1) Fundamentos

El presente artículo y los artículos relacionados (JEE) se basan en lo presentado en el libro Beginning Java EE5 (Editorial Apress), en los manuales y tutoriales de Sun/Oracle, y en problemas/soluciones propias.

La importancia de estudiar JEE, se encuentra desde mi punto de vista, en la gran cantidad de sistemas e infraestructuras actualmente implementadas, que requieren mantenimiento evolutivo y correctivo, y por supuesto, en la necesidad aún vigente de implementar nuevos sistemas usando JEE5.

JEE está enfocado en la creación de aplicaciones empresariales , las cuales se caracterizan por:
  • Resolver problemas empresariales, lo cual supone almacenamiento seguro, concurrencia, seguridad, escalabilidad, almacenamiento y procesamiento distrubuidos... “robustez en el plano de la complejidad”
  • Estar construidas sobre una infraestructura base: los servidores de aplicaciones. Haciendo una analogía con las obras civiles, cuando se construye un edificio no se fabrican ladrillos y vigas de acero, se utiliza las que provee algún fabricante y se usan elementos estrucuturales prefabricados en base a patrones adecuados, que permiten construir y a su vez conectar el nuevo edificio a infraestructuras que proveen servicios básicos. En el contexto del software, los servidores de aplicaciones proveen esos elementos e infraestructura base mediante contenedores, servicios y otros componentes, así como las facilidades de interacción respectivas.

Considerando lo anterior, se puede definir a JEE como:
  • Un conjunto de especificaciones para APIs.
  • Una arquitectura distrubuida y multicapa.
  • Definiciones para empaquetar componentes redistruibuibles para despliegue.
  • Un conjunto de componentes, contenedores y servicios estandarizados, para crear y desplegar aplicaciones distribuidas en la arquitectura mencionada.

La plataforma JEE define el estándar para desarrollar aplicaciones empresariales distribuidas basadas en componentes” (Sun Microsystems), y está fundada sobre J2SE. Así como J2SE cuenta con AWT/Swing para la construcción de sus interfaces gráficas de usuario, JEE provee un framework web basado en componentes para alcanzar el mismo fin: JavaServer Faces (JSF).
Arquitecturas multicapa
En general una aplicación puede estar constituida por 3 capas lógicas:
  • Capa de presentación
  • Capa de reglas del negocio o capa media
  • Capa de acceso a datos
Sistemas de una capa
  • Presentación, negocio y acceso a datos se encuentran en una sola capa computacional.
  • No soportan múltiples usuarios.
Sistemas cliente-servidor (dos capas)
  • Presentación y las reglas del negocio se encuentran en el cliente (DLLs, clases), el cual constituye la aplicación.
  • El manejo de datos lo realiza generalmente un servidor de bases de datos, que puede a su vez implementar cierta lógica (PL/SQL, Transact SQL, etc.)
  • El principal problema de esta arquitectura la actualización y gestión de cambios (distribuir una DLL, o cualquier otro componente, entre los n clientes para implementar 1 cambio o mejor).


Arquitectura convencional de dos capas, cliente-servidor (cliente pesado)
Arquitectura n capas
  • Se agrega una capa para implementar lo más crucial de la lógica del sistema, esta capa podría ser implementada en un servidor con gran capacidad de cómputo, mientras que la capa de presentación puede ser ligera, de forma que pueda ser ejecutada en un navegador.


Arquitectura base de tres capas
  • Se agrega una capa para implementar lo más crucial de la lógica del sistema, esta capa podría ser implementada en un servidor con gran capacidad de cómputo, mientras que la capa de presentación puede ser ligera, de forma que pueda ser ejecutada en un navegador.


Ejemplo de arquitectura de n capas
Problemas que atiende la arquitectura de n capas
Una arquitectura de n capas atiende 6 puntos clave:
  • Mantenibilidad: Se adapta a los cambios del negocio.
  • Consistencia: La lógica del negocio se implementa y se distribuye, lo cual previene implementaciones parciales inconsistentes entre múltiples aplicaciones.
  • Interoperabilidad: La arquitectura permite compartir/invocar servicios y datos entre aplicaciones.
  • Flexibilidad: La arquitectura no restringe la implementación de la presentación, la cual puede realizarse mediante GUIs, interfaces web, u otros tipos de interfaces.
  • Escalabilidad: Mediante la aplicación de la arquitectura y los patrones apropiados, una aplicación puede soportar una mayor carga de usuarios mediante cambios/ajustes en la infraestructura que la soporta.
  • Seguridad: Se pueden agregar mecanismos que mejoren la seguridad de las aplicaciones.

JEE se basa en los puntos explicados para una arquitectura de n capas, por ende los servidores de aplicaciones que implementan las especificación JEE, brindan la infraestructura y facilidades necesarias para construir robustas aplicaciones de n capas.

JEE procura independencia con el vendedor-proveedor de la infraestructura (servidor de aplicaciones), pero como especificación, no se ocupa ni del desempeño ni de la disponibilidad de las aplicaciones.
Características y conceptos de JEE
Clientes y servidores
Un cliente JEE puede ser implementado de diferentes maneras:
  • Clientes ligeros (thin), generalmente basados en web, que se ejecutan en un navegador, y bien pueden ser puro código HTML, o estar enriquecidos con JavaScript, o incluso ser applets.
  • Clientes pesados (fat), implementados mediante aplicaciones de consola, o GUIs con AWT/Swing. Este tipo de cliente está soportado por código Java que se ejecuta fuera del servidor.

Por otra parte, el servidor está conformado por dos tipos de componentes:
  • Componentes web (soportados por un contenedor web), que incluyen: JSPs y Servlets.
  • Componentes de negocio (soportados por un contenedor EJB), que son evidentemente componentes EJB.
Contenedores
Proveen un ambiente para los componentes descritos, así como las interfaces para que los componentes puedan acceder a la infraestructura del servidor (red, seguridad, manejo de transacciones, nombres, localización de recursos). JEE provee contenedores para Servlets, JSPs y EJBs.
Servlets.
  • Un servlet es un componente Java que implementa la interfaz javax.servlet.Servlet.
  • Aunque el modelo de Servlet es genérico, en JEE casi siempre se utilizan HTTPServlets.
  • Un servlet es invocado por una petición HTTP del cliente, que viene en forma de una consulta HTTP. El servidor web toma la petición y notifica al Contenedor Servlet, el cual carga el servlet e invoca el método apropiado de la interfaz javax.servlet.Servlet, la respuesta (un flujo) es devuelta por el servidor web al cliente.


Esquema básico de funcionamiento de un servlet
JSP
JSP es una tecnologia Java creada para generar dinámicamente contenido HTML, XML, o de otros tipos (tal como lo hace un servlet). De hecho, ¡JSP es un lenguaje de plantillas que permite generar un Servlet!

En primera instancia, una página JSP es un documento basado en HTML que puede incluir bloques de código Java, llamados scriptlets, que son introducidos mediante una sintaxis particular (<% código java %>), o pueden incluir etiquetas definidas en librerías de etiquetas (Tag Libraries) que son utilizadas para realizar acciones, tal como si se incluyera código Java; dichas etiquetas pueden ser personalizadas (tema que se revisará posteriormente). El propósito de las páginas JSP, podría decirse, es facilitar la construcción de las interfaces web de las aplicaciones a trabajadores que no necesariamente deben conocer los pormenores del lenguaje de programación Java, y que mas bien deben concentrarse en los detalles de la presentación (en vez de escribir servlets).

Cuando el servidor web recibe por primera vez una petición de una página JSP, se comunica con el contenedor JSP, el cual traduce la página JSP a código Java y lo compila en un servlet, el cual es cargado por el contenedor de servlets en la JVM del servidor en donde es instanciado recibiendo los parámetros del request del cliente. El servlet realiza los procesamientos necesarios y responde al servidor web, el cual canaliza dicha respuesta al cliente. Para las peticiones subsiguientes de la misma página JSP, siempre que ésta no haya sufrido cambios, el servidor web se refiere directamente al contenedor de servlets.

Debe acotarse en este punto que JEE enfatiza el uso de JSF, y que aunque para las especificaciones 1.1 y 1.2 de JSF el lenguaje de declaración de vista por defecto era JSP (basado en html), en JSF 2.0 el lenguaje de declaración de vista por defecto es Facelets (Sistema de plantillas web creado por Apache).
JSF
JSF es un framework web basado en componentes, que implementa el modelo MVC. Los componentes JSF facilitan la construcción de ricas interfaces web del lado del servidor, se conectan a fuentes de datos y beans, y conectan transparentemente eventos de cliente con manejadores en el servidor.
Cuando se usa JSF, toma un rol protagónico el servlet llamado FacesServlet, el cual se encarga de: procesar peticiones dirigidas a “vistas JSF”, cargar la plantilla apropiada para la vista requerida, construir un árbol de componentes para esa vista, procesar eventos y retornar la respuesta al cliente (por defecto HTML).
JDBC
Java DataBase Connectivity, es una API capaz de acceder a cualquier fuente tabular de datos, como por ejemplo, bases de datos relacionales. Para acceder transparentemente a las diferentes fuentes de datos que pueden haber, JDBC requiere de librerías específicas para cada sistema (drivers).
EJBs
Los EJBs son los componentes de negocio de una aplicación JEE. Como se mencionó, las aplicaciones empresariales son distribuidas, lo cual implica comunicaciones y servicios que pueden ser invocados de manera local y remota, lo cual en Java se puede conseguir con RMI (Remote method invocation).

El uso de RMI involucra 3 pasos:
  • Declarar una interfaz que extiende a javax.rmi.Remote
  • Implementar dicha interfaz con una clase que extienda a javax.rmi.server.UnicastRemoteObject
  • Instanciar la clase y registrarla mediante RMI Registry (un servicio de búsqueda simple)
Sin embargo, RMI tiene limitaciones en el contexto de las aplicaciones empresariales, lo cual da paso a los EJBs. RMI provee un framework base para comunicaciones que es utilizado por los contenedores EJB, los cuales mantienen separados a los EJBs de la capa de presentación, convirtiéndolos en un conjuto de servicios disponibles para una o más aplicaciones.

Un contenedor EJB realiza las siguientes tareas:
  • Cargar un EJB cuando es requerido.
  • Invoca al método apropiado según lo requerido.
  • Aplica reglas de seguridad.
  • Maneja la transaccionalidad de las operaciones.
Para desplegar un EJB en un contenedor EJB, se deben realizar pasos similares a los indicados para RMI:
  • Crear una interfaz local, o una interfaz remota, o ambas.
  • Implementar dichas interfaces mediante una clase (el EJB).
  • Desplegar el EJB en el contenedor.
Tipos de EJBs
Session Beans
Su propósito es proveer servicios de negocio (como retornar un conjunto de datos, o ejecutar un proceso), y a su vez se clasifican en Stateless Session Beans y Stateful Session Beans. Los session beans existen mientras dura la conversación o la sesión entre el cliente que hace la petición y el contenedor EJB. Los stateless session beans no guardan su estado, mientras que los stateful session beans lo pueden hacer en el ir y venir de requests/responses hasta que explícitamente se los descarte.
Entity beans
Su función es representar los objetos del negocio (entidades), los cuales pueden ser persistidos y recuperados del repositorio de datos mediante dos estrategias: delegando el control total al contenedor EJB (CMP – container managed persistence), o haciéndo “manualmente” (BMP – bean managed persistence).
Message-driven beans
Son especialmente útiles para atender procesos asíncronos. Los Message-driven beans (MDBs) proveen un modelo distinto del tradicional cliente-servidor, que consiste en servicios que escuchan a un Servicio de Mensajes (Message Service). Los servicios que escuchan (MDBs) son suscriptores de una cola, que es en donde se publican los mensajes respectivos.
Soporte XML en JEE
JEE provee un conjunto de APIs para trabajar con XML:
  • Java API for XML Processing (JAXP): provee funcionalidad para generar y procesar (parse) XML con DOM (Documment Object Model) y SAX (Simple API por XML).
  • Java API for XML Binding (JAXB): provee soporte para mapear XML desde y hacia clases Java.
  • Java API for XML Registries (JAXR): permite acceder a registros basados en XML, como UDDI (Universal Description, Discovery and Integration).
  • Java API for XML Messaging (JAXM): habilita comunicación vía XML y SOAP (Simple Object Access Protocol, para transmitir información entre web services).
  • Java API for XML-based Remote Procedure Calls (JAX-RPC): API avanzada para invocar procedimientos remotos.
Web Services
Un web service es “software para soportar la interacción máquina-máquina sobre una red. Su interfaz se describe con WSDL (Web Service Description Language) y se comunica con su cliente mediante SOAP” (el cliente necesita conocer el WSDL del web service para poder comunicarse).
Seguridad
JEE provee:
  • Acceso anónimo
  • Autenticación
  • Autorización
La seguridad en JEE puede ser declarativa (mediante descriptores – durante el despliegue de las aplicaciones) o programática (en tiempo de ejecución).
Arquitectuas JEE habituales
De las muchas variantes posibles, se presentan sólo dos, como casos ilustrativos:
Cliente servidor


Aplicación Web – EJB y/o EJB – Web Services

Sinópsis y siguientes temas
En el presente documento se han cubierto los conceptos y definiciones fundamentales de JEE, pasando por las arquitecturas relacionadas y los elementos constitutivos más importantes de la plataforma: Contenedores, servlets, JSPs, JSF, EJBs, web services y el soporte XML relacionado. Más adelante se revisarán las configuraciones básicas para empezar a construir aplicaciones web dentro del marco de JEE, así como los tópicos más importantes de JSP, con lo cual se conseguirá un sustento sólido para abordar JSF.

domingo, 27 de marzo de 2011

Leer un archivo de propiedades

Una tarea común es leer un archivo de propiedades desde una aplicación Java. Esto suele ser útil cuando se trata de configurar algún parámetro de la aplicación sin la necesidad de tener que compilarla cada vez, como por ejemplo cuando se trata de definir un Contexto Inicial para buscar componentes EJB desplegados en un servidor. Como IDE se utiliza Eclipse Galileo, sobre jdk1.5.0_22. Para empezar, se crea un proyecto nuevo, la perspectiva puede ser Java:



Las demás opciones se mantienen en sus valores por defecto. Una vez creado el proyecto, continuamos con el archivo de propiedades y la clase que lo leerá.

La clase:
package com.programmabilis.util;

import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;

/**
 * Provee funcionalidades basicas para leer y procesar archivos
 
 @author Dustin Ghia
 
 */
public class UtilitarioArchivos {

    public static void main(String[] argumentos) {
        String archivo = "../../../archivo.properties";
        Properties props = new Properties();
        InputStream flujoEntrada = UtilitarioArchivos.class
                .getResourceAsStream(archivo);
        try {
            props.load(flujoEntrada);

            System.out.println("Nombres completos ---> "
                    "".concat(props.getProperty("prop1")).concat(" ").concat(
                            props.getProperty("prop2")));
        catch (IOException e) {
            e.printStackTrace();
        }
    }

}
Java2html

El archivo de propiedades:


prop1=
prop2=P\u00e1ez
Java2html

La vista del proyecto debe quedar aproximadamente así:


Nótese que se deben considerar la ubicación de la clase y la del archivo de propiedades para poder cargarlo. Finalmente, se enfatiza en que es posible obtener un campo con valor vacío del archivo de propiedades, aunque se podría asumir que se obtendría un null.