Blog de Seguridad

Actualmente, este blog ha tenido una actividad prácticamente nula, esto debido a que actualmente me encuentro dedicado a escribir entradas sobre seguridad informática y técnicas de gray hat hacking en mi otro blog personal. Si te interesa estos temas, te invito a que lo visites aquí:
  http://thehackerway.com
No obstante, si tienes dudas relacionadas con desarrollo de aplicaciones en Java, c/c++ o Ruby, puedes escribirme e intentaré responderte lo más pronto posible (si conozco la respuesta, evidentemente). Saludos.

JPA, TopLink, Spring, Glassfish Ejemplo practico y configuración

Desde que salio la especificación JSR220 (Especificación oficial EJB 3.0-JPA) hace unos cuantos años, el entusiasmo y la cantidad de recursos que han surgido sobre el tema son suficientes para afrontar diversos problemas con los cuales nos podriamos topar haciendo uso de esta tecnologia, sin embargo, muchos de los mismos se centran principalmente en el uso de la especificiación con EJB3.0 y JPA,
lo cual tiene mucho sentido dado que la JSR220 es en principio la especificación para EJB y JPA es visto como "un complemento" que obviamente puede usarse sin necesidad de usar EJB,

Hoy en dia, Spring tiene un gran soporte para muchisimas JSR y obviamente esta no iba a quedarse fuera de este robusto framework de desarrollo. Aunque existen muchos tutoriales y recursos sobre Spring y JPA en la web esta entrada se centra principalmente en un proyecto basico con Spring, TopLink, JPA y un Pool de conexiones manejado por el servidor de aplicaciones en este caso Glassfish.

Primero que nada creación y configuración del Pool de Conexiones, en este caso particular haremos uso de una base de datos Oracle 10g sin embargo no hay ninguna restricción en el uso de algun otro motor de bases de datos:

1. Instalar el servidor de aplicaciones aquí, luego se deberá configurar el classpath para que se reconozca el comando asadmin, en GNU/Linux basado en Debian o Ubuntu editar el fichero .bashrc ubicado en el directorio raiz del usuario en sesión (Esto es opcional, si se utiliza Eclipse, desde el IDE se podra iniciar y detener el servidor) luego se debe ubicar el Driver JDBC adecuado en la ruta, en este caso particular usaremos ojdbc14.jar y deberemos ubicarlo en: DIR_INSTALL_GLASSFISH/domains/domain1/lib/ext/ en este directorio se ubicaria cualquier otro Driver JDBC en el caso de que se utilice otro motor de Bases de datos.
   
2. Iniciar el servidor de aplicaciones.
3. Dirigirse a la consola de administración normalmente en http://localhost:4848 e iniciar sesión, en el caso de que en el momento de la instalación se haya ingresado un número de puerto diferente, especificarlo.
4. En el menu seleccionar, Resources->JDBC->Connection Pools seleccionar new, especificar un nombre, como por ejemplo OraclePool, como Resource Type: javax.sql.ConnectionPoolDataSource, Database Vendor: Oracle (en nuestro caso, pero si se utiliza un motor diferente se podria seleccionar tambien), pulsar en Next
5. Especificar las propiedades del Pool, al final de la pagina especificar las siguientes propiedades
1. User: Usuario de base de datos.
2. Password: Password de base de datos.
3. url: jdbc:oracle:thin:@localhost:PUERTO_ORACLE:SID_ORACLE
4. Las demas propiedades se pueden dejar con sus valor por defecto.
6. Al terminar de configurar esta configuración se debera probar pulsando Ping, una vez de una respuesta de conexión correcta pasamos al siguiente punto.
   
7. Finalmente en Resources->JDBC->JDBC Resources pulsar en New, especificar un JNDI name, como por ejemplo jdbc/OraclePool seleccionar el Pool Name creado en los pasos anteriores y pulsar OK, con esto ya queda configurado y listo para ser utilizado nuestro Pool de conexiones.
   
   

Ahora necesitamos ubicar los ficheros .jar necesarios en el directorio de librerias de la aplicación (normalemente en WEB-INF/lib) es posible utilizar las implementaciones que proporciona el servidor de aplicaciones sobre todo las de Toplink, ahora bien, las librerias de Spring pueden ser descargadas desde aquí se deja a libre elección el uso de cualquier versión superior a la 2.0, preferiblemente desde la versión 2.5, el fichero de configuración de Spring debera contener las siguientes lineas en primer termino:


<jee:jndi-lookup id="dataSource" jndi-name="jdbc/OraclePool"/>
<bean id="entityManagerFactory"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSource"/>
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.TopLinkJpaVendorAdapter">
<property name="showSql" value="true"/>
<property name="database" value="ORACLE"/>
</bean>
</property>
<property name="persistenceUnitName" value="Seth" />
<property name="loadTimeWeaver">
<bean class="org.springframework.instrument.classloading.glassfish.GlassFishLoadTimeWeaver" />
</property>
</bean>


Estas lineas iniciales basicamente contienen la definición del DataSource, el cual sera tomado del servidor de aplicaciones, (que se ha creado en unas lineas atras) posteriormente se especifica que el proveedor de persistencia sera TopLink y algunas propiedades adicional, así como el LoadTimeWeaver, especificando que se trata de la especificación de Glassfish
Luego se definen las siguientes lineas:


<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/> <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/>
<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager" />
<tx:annotation-driven transaction-manager="transactionManager"/>


Con esto se habilita el soporte de anotaciones tales como PersistenceContext para la inyección del EntityManager dentro de la aplicación y poder utilizar JPA sin inconveniente, esto se realiza básicamente gracias a los beans de Spring PersistenceExceptionTranslationPostProcessor y PersistenceAnnotationBeanPostProcessor.
Posteriormente se habilita soporte para transacciones, en este caso por medio de JTA, por lo que despues en el código es posible introducir la anotación @Transactional para definir métodos y/o clases transaccionales, pudiendo especificar bastante opciones relacionadas con esto. En una proxima entrada profundizaré un poco mas sobre el tema de transacciones con JPA y las diferencias que hay entre un modelo bastante conocido de aplicaciones basadas con JDBC sin el uso de ningun tipo de framework de persistencia.

Ahora esta será la definición del fichero persistence.xml el cual debe de estar definido en el directorio META-INF accesible al classpath por esta razón es muy común que en una aplicación Web se incluya en WEB-INF/classes/META-INF/ en dicho fichero se destaca basicamente el uso del proveedor de persistencia, en este fichero se define que proveedor de persistencia se encargara de las operaciones de acceso a datos y operaciones persistentes, donde podriamos definir algunos ya conocidos como Hibernate, OpenJPA, Kodo, TopLink, etc. Tambien allí se define el tipo de transaccionalidad, es decir, RESOURCE_LOCAL o JTA, asi seria el fichero:



<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="Seth" transaction-type="JTA">
<provider>oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider</provider>
<jta-data-source>jdbc/OraclePool</jta-data-source>

<properties>
<property name="toplink.ddl-generation" value="create-tables"/>
<property name="toplink.ddl-generation" value="drop-and-create-tables"/>
</properties>
</persistence-unit>
</persistence>


Una vez se cuenta con esta estructura básica de ficheros de configuración a continuación se detallan algunas clases que se hacen referencia desde allí, partiendo desde la capa de entidades, de este modo podemos tener una entidad Usuario como esta:

package testingjpa;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

@Entity
public class Usuario {
@Id
@GeneratedValue(strategy=GenerationType.AUTO)
@Column(name="id")
private Long idUsuario;

@Column(name="nombre")
private String nombre;

@Column(name="edad")
private Integer edad;

@Column(name="sexo")
private String sexo;

@Column(name="password")
private String password;


public void setIdUsuario(Long idUsuario) {
this.idUsuario = idUsuario;
}

public Long getIdUsuario() {
return idUsuario;
}

public void setNombre(String nombre) {
this.nombre = nombre;
}

public String getNombre() {
return nombre;
}

public void setEdad(Integer edad) {
this.edad = edad;
}

public Integer getEdad() {
return edad;
}

public void setSexo(String sexo) {
this.sexo = sexo;
}

public String getSexo() {
return sexo;
}

public void setPassword(String password) {
this.password = password;
}

public String getPassword() {
return password;
}
}


Como se puede ver, es una clase normal, un Pojo Java como es conocido desde los origenes del lenguaje, solamente que se adicionan anotaciones propias de JPA que le permiten al motor de persistencia identificar este pojo como una entidad persistente en base de datos, es decir, como una tabla con columnas y demas elementos que la conforman.

Posterior a esto es necesario definir la forma en la cual accedemos a las entidades, los enfoques mas comunes de hacer esto con Spring, es por medio de la Extensión de plantillas "helper" propias de Spring, o por medio del uso de anotaciones, para este ejemplo, usaremos anotaciones que es la forma más estandar, ya que, en el caso de que la aplicación quiera migrarse a otra tecnologia (como EJB3) seria necesario escribir nuevamente el codigo, con el uso de anotaciones el uso de dicho objeto de acceso a datos, seria completamente reutilizable y "expansible". El ejemplo del DAO sería el siguiente:


package testingdao;

import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import org.springframework.transaction.annotation.Transactional;
import testingjpa.Usuario;

public class TestingDaoImpl implements TestingDao {

@PersistenceContext(unitName="Seth")
private EntityManager entityManager;

public void removeUsuario(Usuario usuario) {
getEntityManager().remove(usuario);
}

@Transactional
public Usuario saveUsuario(Usuario usuario) {
return getEntityManager().merge(usuario);
}

public void setEntityManager(EntityManager entityManager) {
this.entityManager = entityManager;
}

public EntityManager getEntityManager() {
return entityManager;
}
}



En esta clase se incluye solamente un método de inserción/actualización, y uno de borrado, el metodo de inserción/actualización sería saveUsuario, el cual invoca al metodo merge del objeto EntityManager, el cual inserta en el caso de que la entidad no tenga una identidad persistente (nueva) y en el caso de que la entidad ya exista (gestionada) se realiza la actualización de los datos ingresados en la entidad. En este caso en particular, se han definido las propiedades en el fichero applicationContext.xml en las lineas:


<property name="showSql" value="true"/>


Con lo cual se mostraran en pantalla las consultas SQL por consola, desde allí se podran ver los insert, update, delete, select, alter y demas comandos SQL.
En el applicationContext será necesario adicionar el Dao para que pueda ser manejado como un bean de Spring por lo tanto es necesario adicionar la siguiente linea en el fichero de configuración:


<bean id="daoTesting" class="testingdao.TestingDaoImpl">


Con esto ya lo tenemos hecho, ahora solamente queda crear las capas de acceso al DAO es decir, capas de negocio, gestión o como se le quiera llamar, inclusive si se trata pruebas, basta con invocar directamente el DAO desde un cliente, ya sea una aplicación Web común o una aplicacion stand-alone, dado que este ejemplo esta sobre Glassfish, y en este servidor de aplicaciones se encuentra la implementación de JSF1.2, seria bastante interesante hacerlo desde una aplicación Web, por lo tanto se puede crear una pagina JSF cuyo contenido podria ser el siguiente para fines de pruebas:


<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<f:view>
<h1> Formulario de Inserción de Usuario</h1>
<h:form>
<h:panelGrid columns="2">
<h:outputText value="Nombre"/>
<h:inputText value="#{JSFBean.usuario.nombre}" />
<h:outputText value="Edad"/>
<h:inputText value="#{JSFBean.usuario.edad}">
<f:validateLongRange maximum="2" minimum="2"/>
</h:inputText>
<h:outputText value="Sexo"/>
<h:selectOneMenu value="#{JSFBean.usuario.sexo}">
<f:selectItem itemLabel="Masculino" itemValue="M"/>
<f:selectItem itemLabel="Femenino" itemValue="F"/>
</h:selectOneMenu>
<h:outputText value="Password" />
<h:inputSecret value="#{JSFBean.usuario.password}" />
<h:commandButton value="Guardar" actionListener="#{JSFBean.createUsuario}" />
</h:panelGrid>
</h:form>
</f:view>


Ahora el cotenido del fichero de configuración de JSF puede ser:


<?xml version="1.0"?>
<!DOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
"http://java.sun.com/dtd/web-facesconfig_1_0.dtd">
<faces-config>
<managed-bean>
<description>Bean</description>
<managed-bean-name>JSFBean</managed-bean-name>
<managed-bean-class>testingspring.TestingBeanJSF</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
</faces-config>


Finalmente, para terminar con esta prueba, proseguimos con la creación del MBean de JSF, el contenido seria:


package testingspring;

import javax.faces.context.FacesContext;
import javax.faces.event.ActionEvent;
import javax.servlet.ServletContext;
import org.springframework.context.ApplicationContext;
import org.springframework.web.context.support.WebApplicationContextUtils;
import testingdao.TestingDao;
import testingjpa.Usuario;

public class TestingBeanJSF {

private Usuario usuario = new Usuario();

public void createUsuario(ActionEvent evt) {
ApplicationContext appContext;
ServletContext servletContext;
FacesContext contexto = FacesContext.getCurrentInstance();
servletContext=(ServletContext)contexto.getExternalContext().getContext();
appContext= WebApplicationContextUtils.getWebApplicationContext(servletContext);
Object bean = appContext.getBean("daoTesting");
TestingDao dao = (TestingDao) bean;
dao.saveUsuario(usuario);
}

public void setUsuario(Usuario usuario) {
this.usuario = usuario;
}

public Usuario getUsuario() {
return usuario;
}
}


El método que resulta interesante es el createUsuario(Usuario usuario) el cual se encarga de obtener el Bean de Spring a partir de las utilidades de Spring Framework para acceso al contexto de Spring en base al contexto de JSF, una vez hecho esto, solamente utilizamos el bean (DAO) para realizar las operaciones de inserción/actualización de datos.

Bien, con esto termina esta entrada espero que sirva como punto de documentación cualquier duda, o comentario será recibido.

JDaanial.

[+/-] Continuar leyendo...

Beans JSF Manejados por el contexto de Spring

La forma común en la cual se inyectan los Beans Manejados de JSF es por medio del fichero de configuración faces-config.xml, esto es conocido por cualquier programador de JSF con un nivel básico de conocimientos en el tema,
sin embargo, lo mas común en una aplicación J2EE es tener un conjunto de modulos independientes como por ejemplo modulos de negocio con Spring, Ejb, persistencia con JPA, Hibernate, iBatis, TopLink, etc.
En este punto ocurre algo de lo cual se ha mencionado en la entrada anterior, y es el tema de la Inyección de Dependencias, efectivamente cuado inyectamos un Managed Bean de JSF estamos haciendo uso de un contenedor JSF para el almacenamiento y recuperación de objetos destinado para los Managed Beans, luego, en capas de negocio encontramos que Spring o EJB tambien necesita realizar inyección de dependecias de sus recursos (Tipicamente Beans en el caso concreto de Spring), Sin embargo es aquí, cuando podriamos preguntarnos ¿Y para que necesito 2 contenedores para realizar la inyección de dependecias de los recursos de la aplicación? probablemente esta misma pregunta se han formulado los desarrolladores de Spring, por lo tanto desde la versión 2.0 es posible expandir el soporte de JSF que tiene Spring para que los Beans sean manejados por la implementación del BeanResolver propio de Spring.Para ilustrar esto de un modo practico, indico los siguientes pasos:

Se asume que se cuenta con una configuración de Spring y JSF instalados correctamente con todas las librerias necesarias, posteriormente, se deberan insertar las siguientes lineas en el faces-config:


<?xml version="1.0"
!DOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
"http://java.sun.com/dtd/web-facesconfig_1_0.dtd">;
faces-config>
<application>
variable-resolver>
org.springframework.web.jsf.DelegatingVariableResolver
</variable-resolver>
</application>
</faces-config>




De este modo le decimos a JSF que la forma en la cual el Expression Lenguage resolvera los beans que se referencien en las paginas, ahora bien para probarlo, basta con crear un Bean de Spring en el fichero de configuración de Spring, (por nómenclatura se nombra applicationContext.xml, pero es igual, como lo llames)

Despues de esto lo unico que debemos hacer es crear el Bean de Spring con un contenido como este:

package testingspring;

public class TestingBeanJSF {
private String mensajeTexto="Bean Manejado de Spring";
public void setMensajeTexto(String mensajeTexto) {
this.mensajeTexto = mensajeTexto;
}
public String getMensajeTexto() {
return mensajeTexto;}
}



Finalmente, adicionamos el bean de la siguiente forma en el fichero de configuración:

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:jee="http://www.springframework.org/schema/jee"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-2.5.xsd
http://www.springframework.org/schema/jee
http://www.springframework.org/schema/jee/spring-jee-2.5.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-2.5.xsd">
<bean id="testing" class="testingspring.TestingBeanJSF" />
</beans>




Como podemos comprobar en el fichero faces-config, no exite ningun bean manejado, para probarlo podemos tener una pagina como esta:

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<f:view>
<h:form>
<h:outputText value="#{testing.mensajeTexto}"/>
</h:form>


Con esto Bastara para probar, espero que esta entrada simple sea de utilidad.

Jdaanial.


[+/-] Continuar leyendo...

Spring, Buenas Practicas

SPRING FRAMEWORK Y BUENAS PRACTICAS

En esta entrada quiero hablar de temas que pocos Para nadie es un secreto la fama y la gran cuota de mercado de las aplicaciones J2EE desarrolladas con Spring Framework sin embargo, a pesar de que Spring guia y facilita el desarrollo de componentes en diferentes capas de una aplicación J2EE haciendo uso de buenas practicas de programación, pocos desarrolladores advierten que en muchos casos (de forma accidental por supuesto) se escribe código que rompe los principios de buenas practicas en desarrollo de Software, todos hemos caido esto y muchas veces creemos de forma errada que al usar técnicas orientadas a patrones de diseño como Inversion Of Control (IoC) tenemos una aplicación funcional y programaticamente "correcta" pero... no es así.
Ahora la pregunta es, por que? antes de comenzar con cualquier proyecto de Software y desde la etapa de análisis y diseño se deberia considerar los 3 siguientes principios y tratar de responder las 3 siguientes preguntas:

1. os componentes de Software son rigidos? es decir, cambiar fragmentos de código es dificil debido a que puede afectar considerablemente de forma negativa otros componentes del sistema?
2. El sistema es fragil? es decir, cambiar fragmentos de código puede producir efectos negativos inesperados en otras partes del sistema?
3. Los componentes de Software no son reutilizables? es decir, un componente determinado de software puede ser reutilizado en otro sistema.

Seguramente quien tenga un poco de experiencia en el campo de desarrollo de Software, se ha visto respondiendo de forma desfavorable a una o muchas de estas preguntas (que en realidad son principios ampliamente aceptados en el mundo del desarrollo de software en todo el mundo), Aunque se encuentre usando Spring y sea uno de los frameworks probablemente mas amplios en el mundo de software basado en Java actualmente, los frameworks no convierten un "mal código" en un "buen código", ahora bien, para estos problemas tan comunes existen respuestas que son tambien comunes y se definen basicamente en 2 principios de diseño que son VITALES y que ningun arquitecto de software debera olvidad nunca:

1. Los modulos de alto nivel no deben depender directamente de los modulos de bajo nivel, ambos deben depeder de abstracciones, o definiciones comunes.
2. Las abstracciones no deben depender de los detalles espeficios de las implementaciones, por el contrario las implementaciones deben depender de las abstracciones.

Por lo que hemos visto anteriormente, cobra sentido el uso de clases abstractas e interfaces como una buena practica en desarrollo de software Orientado a Objetos, algo que comunmente realizan los desarrolladores sin conocimiento de causa, y solamente lo hacen por que lo han visto en un tutorial de Spring y "así les funciona" pero todo en el mundo del Software tiene su causa y su(s) efecto(s), nuestra tarea es conocer las causas y posibles efectos.
Es muy importante tener muy presente que, la Inyección de Dependencia en Java es normalmente conocida bajo el concepto de Factoria la cual instancia objetos e inyecta otros que dependen de ellos para ser utilizados en una aplicación, ahora bien, cuando usamos Spring tenemos una ventaja importante de la que por desgracia no tenemos con el uso con otras especificaciones tan comunes y potentes como EJB y es el testing y la administración de la construcción/destrucción de los Beans Out of Box, esto en realidad lo que quiere decir es que el contenedor IoC de Spring desarrolla todas estas tareas (y mas) de una forma autonoma e independiente del contenedor J2EE subyacente, por lo tanto podemos ejecutar Spring sin necesitar de forma obligatoria un contenedor J2EE, lo cual es tipico en este tipo aplicaciones me refiero efectivamente a que es normal que sea necesario un contenedor y busquedas JNDI para encontrar Factorias o recursos, pero con Spring, esto no es necesariamente obligatorio.
Otro tema un poco a nivel de diseño, (pero que es aun muy importante a nivel de arquitectura) es el uso de adecuado de una nomenclatura estandar para tareas comunes, Vamos a declarar un escenario frecuente: "Llamo en un Objeto de acceso a datos con un metodo llamado guardarAlgoX() y luego tengo otro tiene un metodo llamado insertarAlgoY(), y ambos metodos realizan una inserción comun en base de datos" Ahora bien, existe un concepto muy importante que es Programación Orientada a Aspectos (AOP) mas que un concepto, es un modelo de programación diferente al modelo clasico orientado a objetos, no entraré en mayores detalles, basta con decir que (AOP) nos brinda flexibilidad adicional que no disponemos con la POO, esto debido a la introducción de conceptos como Aspectos, Puntos de Corte, etc. Necesario anotar que AOP no es una "sustitución" del modelo OO por el contrario se trata de un modelo adicional complementario y es justo aquí en el momento en el que Spring entra en acción, en la situación anterior, lo normal deberia ser definir una nomenclatura "estandar" donde los nombres de los métodos contengan nombres auto-explicativos deacuerdo a las operaciones que realizan como "guardar", "buscar" "eliminar", etc. por ejemplo en el caso anterior, los metodos deberian nombrarse de una forma similar a: guardarAlgoX(), guardarAlgoY() de este modo es mucho mas simple manejar temas complejos como transacciones y auditorias, dado que se pueden insertar puntos de corte para "monitorizar" determinadas acciones en los metodos que comienzan o contienen una cadena determinada como por ejemplo "eliminar", "insertar", etc. Pequeños detalles que muchas veces por inexperiencia, desconocimiento o simplemente descuido nos hacen tener un código con errores, dificil de mantener, y mucho mas dificil de modificar o extender.

Bien, una entrada corta, que espero que os haga reflexionar un poco en el modo en el cual hacemos las cosas....

Jdaanial.

[+/-] Continuar leyendo...

Implementando MyFaces, Tommahawk y SandBox.

En el mundo de JSF existen muchas implementaciones que siguen el modelo y la filosofia de este robusto Framework de desarrollo enfocado principalmente en la capa de presentación, resaltan Oracle ADF Faces, RichFaces, MyFaces, Trinidad, ICEFaces, etc. Todos enfocados a extender la implementación estandar de JSF siguiendo obviamente el modelo y arquitectura definidos por la implementación de referencia.

En esta ocasión hablaré un poco sobre MyFaces una de las implementaciónes de JSF mas conocida y utilizada, como información general este es uno de los muchos proyectos con exito de Apache, ahora bien,Tommahawk y SandBoxpueden tomarse como extensiones o subproyectos de MyFaces, con componentes y utilidades que no se encuentran en la distribución core de MyFaces, una de las grandes ventajas que tenemos los desarrolladores de JSF es que podemos hacer una mezcla de diversos frameworks dentro de nuestros proyectos y hacer uso de una gran gama de componentes que, a final nos sirven para que los proyectos que desarrollemos haciendo uso de tecnologia J2EE tengan una buena calidad.

Configuración e instalación del Proyecto:

Para comenzar debemos contar con una estructura de aplicación Web, donde cuando menos debemos contar con un direcotorio WEB-INF y en el interior de dichos directorios deberan existir por lo menos los directorios lib, classes, conf (opcional) y los ficheros web.xml (fichero de configuración de la aplicación web) y faces-config.xml (fichero de configuración de JSF).Con esta estructura creada es necesario tener las librerias adecuadas en el directorio WEB-INF/lib para la correcta instalación y configuración de la aplicación es necesario descargar MyFaces y las correspondientes librerias commons al momento de redactar este documento nos encontramos en la versión 1.2.7, para descargarlo la ruta es: http://www.apache.org/dyn/closer.cgi/myfaces/binaries/myfaces-core-1.2.7-bin.tar.gz
El fichero contiene las librerias commons adecuadas deacuerdo la versión de MyFaces. Sin embargo, en algunos casos (dependiendo del servidor de aplicaciones o contenedor web de despliegue) sera necesario la libreria commons-el (Expression Lenguage) este asunto se explicará con detenimiento mas adelante.
Posteriormente debemos descargar Tommahawk desde aqui: http://www.apache.org/dyn/closer.cgi/myfaces/binaries/tomahawk-1.1.9-bin.tar.gz
La versión al momento de escribir este documento es la 1.1.9.
Finalmente nos descargamos SandBox desde la siguiente ruta:
http://people.apache.org/maven-snapshot-repository/org/apache/myfaces/tomahawk/
Una vez ubicadas estas librerias en el directorio WEB_INF/lib procedemos a configurar el proyecto de la forma mas adecuada, en MyFaces es necesario configurar los filtros de extensión para Tommahawk ademas es necesario tener en cuenta que para una aplicación Web normal con MyFaces, no se pueden incluir en el directorio WEB_INF/lib las librerias de la implementación estandar de JSF, es decir los ficheros jsf-api.jar y jsf-impl.jar principalmente debido a conflictos entre las especificaciones de JSF estandar y MyFaces.

Ahora el fichero de configuración de la aplicación Web debera contener las siguientes lineas:

FICHERO WEB.XML

El contenido del fichero es casi "auto-explicativo" solamente por resaltar lo explicado anteriormente sobre la definición del ExtensionFilter aquí es importante anotar que la etiqueta de estas lineas deben de coincidir con la definición del Faces Servlet que como se muestra en las lineas anteriores contiene *.faces lo que indica que cualquier petición a una pagina en el servidor con extensión .faces será procesada por el Servlet de Faces.

Prueba de Configuración y Ejecución:

Para verificar el correcto funcionamiento de la configuración realizada se podra componer una pagina de prueba que haga uso de componentes simples de MyFaces, Tommahawk y SandBox.
Crearemos un fichero llamado index.jsp con el siguiente contenido

FICHERO INDEX.JSP

Si el nombre de la pagina es index.jsp, para que sea manejada por JSF es necesario invocarla como index.faces, esto debido a que la extensión faces es la que se ha configurado en el web.xml

Posibles problemas de configuración:
Es probable que se detecten errores de configuración cuando se configura MyFaces relacionado con librerias especialmente, en algunos casos el servidor de aplicaciones o contenedor Web prevee las librerias necesarias, en otras ocasiones no, como es el caso de las librerias commons-el y commons-lang ahora bien, los errores relacionados con esto como ya se podria imaginar son ClassNotFoundException. por lo tanto es necesario incluirlas tambien en el directorio WEB_INF/lib aquí las dejo:

commons-el
commons-lang

Tambien es posible que el ExtensionFilter no se encuentre bien configurado sin embargo con el fichero de configuración implementado en lineas anteriores se encuentra correctamente configurado y no deberia haber problemas, sin embargo la documentación se encuentra aquí:

http://myfaces.apache.org/tomahawk/extensionsFilter.html
Por el momento es todo por el momento, espero que sea de utilidad, si alguien tiene alguna duda deja tu comentario.

Jdaanial.

[+/-] Continuar leyendo...

Plugin de Eclipse para poder usar Glassfish

Normalmente cuando trabajamos con un IDE basado en Java tenemos muchas opciones de donde elegir, algunos nos dan herramientas y opciones que no se encuentran en otros y así vamos probando, ensayando y jugando un poco, actualmente existen muchisimos, sin embargo los mas conocidos en el mundo de Java sin lugar a dudas son NetBeans y Eclipse, desde mi punto de vista ambos tienen opciones, herramientas y formas de desarrollar que son muy útiles, y en mi caso no entraría en el debate de decir que uno es mejor que otro.



ECLIPSE Y GLASSFISH

Aunque es completamente cierto que Netbeans esta mucho mejor integrado para trabajar con Glassfish que Eclipse en sus versiones posteriores a la 3.5, opino lo mejor seria utilizar ambos y explotar las potencialidades que ofrecen, no estamos hablando de productos comerciales, sino de productos opensource, así que podemos sentirnos libres de usarlos sin mayores limitaciones independiente de esta eterna "batalla" de opiniones y absurdas criticas de lado a lado que en realidad no llevan a nada, voy a centrarme en estas lineas solamente a comentar algo que resulta ser muy útil y a su vez muy simple a la hora de desarrollar aplicaciones J2EE con Eclipse y Glassfish, en primer lugar, cabe aclarar un par de asuntos:

1- Eclipse utiliza un sistema de plugins y features en donde se encuentran las configuraciones de nuestro entorno, desde allí podremos instalar características que harán que nuestro Eclipse pueda adquirir nuevas capacidades que nos pueden parecer muy útiles. Este sistema se complementa con una interfaz de descarga e instalación de características que nos permite ingresar un repositorio valido e instalar características interesantes para nuestro entorno.
2- Existen diferentes versiones de Eclipse como muchos ya saben, sin embargo la que resulta interesante es la versión integrada de desarrollo con j2EE la cual contiene las herramientas necesarias para trabajar con las tecnologías mas punteras en el mundo de Java Enterprise.


Ahora bien desde este enlace https://glassfishplugins.dev.java.net/download/ se encuentran las versiones disponibles y los métodos de instalación del plugin, es posible descargar los ficheros de plugins y features y pegarlos en el directorio de Eclipse donde corresponde, es decir en el directorio plugins y en el directorio features, una vez descomprimidos allí es posible encontrar un server adapter adecuado.
Nuevamente como comente anteriormente este procedimiento solamente es valido para versiónes anteriores a la 3.5, dado que la versión Galileo de Eclipse ya contiene este plugin y no necesita configuración adicional.

Espero que sirva de algo estas pocas lineas para despejar algunas dudas.

Jdaanial

[+/-] Continuar leyendo...

Instalar y Configurar Oracle 10G en Debian Etch junto con SQLDeveloper 1.5

Bueno, pues eso, llevo un par de semanas haciendo que funcione Oracle 10g en mi computadora, casi que no lo logro, aquí trataré de contar un poco como ha sido mi experiencia, los pasos que he tenido que realizar y otros detalles de la instalación, una guiá que me ha parecido excelente y que me ha servido bastante para conseguir este objetivo ha sido esta

Voy a tratar de explicar un poco los pasos que he seguido en esta guiá, las dificultades que he tenido y como las he afrontado para poder instalar el motor, finalmente mostraré como instalar un cliente que particularmente me parece que es bastante util, me refiero a SQLDeveloper 1.5. Bueno.... comencemos:

INSTALACIÓN Y CONFIGURACIÓN DE ORACLE 10G:

Primero que nada, se debe descargar la base de datos desde aqui en este momento en este sitio se puede descargar Oracle 10g, se requiere el siguiente fichero: ship.db.lnx32.cpio.gz (649,170,233 bytes) (cksum - 1778052285) Tener en cuenta que debe de ser este fichero solamente, con el cual se instala la base de datos oracle 10g y herramientas bastante utiles como sqlplus, isqlplus, Enterprise Manager 10g Datagrid Control, Net Configuration Assistant... entre otras. Vamos a comenzar con la configuración inicial de paquetes y parámetros que se deben de modificar para su correcto funcionamiento, primero que todo las librerías necesarias, en mi experiencia personal, no todas las que dicen que se requieren se encuentran disponibles para Debian Etch, claro, esto también es debido a que Oracle 10g no esta disponible para Debian Etch, de hecho solamente esta certificado para Red Hat, mas adelante explicaré un poco sobre esto, es importante tener al menos las siguientes:

• libc6-dev (de vital importancia que sea la ultima versión)

• binutils

• lesstif2

Estas son las mas importantes, he encontrado que en muchos sitios recomiendan otras como libmotif3, esta no se encuentra en los repositorios de Debian, pase de ella, y al final no tuve ningún problema con la instalación ;) Posterior a esto me dedique a crear los grupos y el usuario oracle para la instalación y ejecución de todos los servicios que se usaran, he ejecutado lo siguiente como root claro esta:

groupadd oinstall

groupadd dba

useradd -c "Usuario Oracle10g" -g oinstall -G dba -m -d /home/oracle oracle

En Debian Etch, hay que considerar que al usar el comando useradd el directorio HOME no es creado implícitamente, debe indicarse que se quiere crear dicho directorio y especificar su ubicación esto con las opciones -m y -d Se asigna password al nuevo usuario de este modo: sudo passwd oracle
Como root obviamente Y listo, después de esto ya esta el usuario creado, ahora debemos crear la estructura de directorios base para la instalación del producto, simplemente creación de directorios, nada de que preocuparse:

mkdir -p /u01/app/oracle

mkdir -p /u02/oradata

chown -R oracle:oinstall /u02 /u01

chmod -R 775 /u01 /u02

Luego viene la parte de configuración, donde se especifican los parámetros del Kernel que deben modificarse, en este punto los pasos que se deben realizar son los siguientes:

Nota Importante: Los pasos son tomados de la guiá anterior encontrada aqui

1. Enlaces Simbólicos: Primero que todo añadir los siguientes enlaces simbolicos, que en sistemas certificados por Oracle como (Red Hat Enterprise) se encuentran normalmente ya creados, sin embargo, en Debian deben ser creados, ejecutar:
   ln -s /usr/bin/awk /bin/awk
   ln -s /usr/bin/rpm /bin/rpm
   ln -s /usr/bin/basename /bin/basename
   ln -s /etc /etc/rc.d
   
   

2. Requerimientos del Sistema: Se deben verificar los requerimientos mínimos del sistema, asumo que cuando menos conoces tu maquina ;) lo que debes de tener en cuenta es que la instalación de Oracle 10g requiere como mínimo 512 de memoria RAM y 1 Giga de SWAP, aunque esto si queremos instalarlo, en ningún momento se ha hablado de ejecutarlo, Oracle es bastante pesado y para efectos prácticos, instalarlo en un equipo GNU/Linux con 512 de RAM es... digamos tedioso de trabajar, ya que Oracle consumiría absolutamente todos los recursos..., es mejor emplear un sistema un poco mas robusto, con por lo menos 1 Giga de RAM, aunque 2 Gigas no vendrían mal ;).
   En cualquier caso si desconoces esas características las puedes consultar con los siguientes comandos:

   grep MemTotal /proc/meminfo grep SwapTotal /proc/meminfo

3. Modificar los limites del Kernel: En esta parte es necesario modificar los parámetros del Kernel, de modo tal que quede algo optimizado para la instalación de Oracle 10g. Se deberán ejecutar inicialmente las siguientes instrucciones por separado:
   
   /sbin/sysctl -a |grep sem
   /sbin/sysctl -a |grep shm
   /sbin/sysctl -a |grep file-max
   /sbin/sysctl -a |grep ip_local_port_range
   

   La salida de este comando solamente determina los limites del Kernel que tiene en ese momento el sistema, una configuración adecuada para cada una de estas entradas seriá como se indica a continuación, en el caso de que algunos de estos valores no concuerden se deben modificar el archivo /etc/sysctl.conf y ejecutar el comando sysctl -p:
   
   kernel.sem = 250 32000 100 128
   kernel.shmmni = 4096
   kernel.shmall= 2097152
   kernel.shmmax = 2147484648
   fs.file-max=65536
   net.ipv4.ip_local_port_range=1024 65000
   
   

4. Seguimos modificando los limites: Ahora se deben de modificar (si es el caso) el valor por defecto de los descriptores de fichero para el usuario oracle, podría adicionarse las siguientes lineas en el archivo /etc/security/limits.conf En la guiá indicada anteriormente define las siguientes lineas para todos los usuarios, pero este no es el objetivo, ya que solamente el usuario oracle debería tener configuradas estas variables:
   
   * soft nproc 2047 * hard nproc 16384 * soft nofile 1024 * hard nofile 65536
   
   Luego se deberá adicionar la siguiente linea (sino existe ya) al fichero /etc/pam.d/login:
   
   session required /lib/security/pam_limits.so
   

5. Modificar el profile del usuario Oracle:
   Solamente basta con adicionar las siguientes lineas al fichero $ORACLE_HOME/.bash_profile:
   
   

   if [ $USER = "oracle" ]; then
   
      if [ $SHELL = "/bin/sh" ]; then
   
           ulimit -p 16384
   
   ulimit -n 65536
   
   
   
   	else
   
           ulimit -u 16384 -n 65536
   
   fi
   
   fi
   
   

   
   

6. MODIFICACION DE LAS VARIABLES DE ENTORNO:
   
   Se modifican las variables de entorno del usuario oracle con el fin de que se puedan ejecutar sin ningún problema los comandos relacionados con inicio de los listeners, inicio de la base de datos, sqlplus e inicio de isqlplus... etc. Entre otras cosas también se adicionan las rutas relacionadas:
   
   

   ORACLE_BASE=/u01/app/oracle
   
   ORACLE_HOME=/u01/app/oracle
   
   /product/10.1.0/db_1; export ORACLE_HOME
   
   ORACLE_SID=test; export ORACLE_SID
   
   ORACLE_TERM=xterm; export ORACLE_TERM
   
   ORACLE_OWNER=oracle; export ORACLE_OWNER
   
   NLS_LANG=SPANISH_SPAIN.WE8ISO8859P1; export NLS_LANG
   
   CLASSPATH=${CLASSPATH}:${ORACLE_HOME}/jdbc/lib/classes12.zip
   
   LD_LIBRARY_PATH=${ORACLE_HOME}/lib;
   
   export LD_LIBRARY_PATH
   
   DISABLE_HUGETLBFS=1; export DISABLE_HUGETLBFS
   
   TEMP=/tmp; export TEMP
   
   TMPDIR=/tmp; export TMP
   
   PATH=$PATH:/u01/app/oracle/product/10.1.0/db_1/bin;
   
   export PATH

   
   

7. "Engañar" al instalador de Oracle: 

   Al descargar Oracle muy posiblemente te has dado cuenta de que este software esta solamente disponible para la distribución Red Hat..., esto es un problema al momento en el que se esta realzando la instalación de Oracle sobre Debian ya que el instalador verifica que se trata de instalar el software sobre una versión de GNU/Linux certificada, sin embargo esto puede ser resuelto sin muchas dificultades solamente creando el fichero de configuración que indica la distribución del sistema operativo que se esta empleando el instalador busca este fichero para comprobar que se trata de un sistema Red Hat, solamente se crea dicho archivo con el contenido adecuado y no es mas.... se hace de la siguiente manera:
   
   nano /etc/redhat-release ---Podras utilizar cualquier editor de texto...
   
   en el archivo escribir y guardar este contenido:

   
   

   Red Hat Linux release 2.1 (drupal)
   
   
   
   Y esto es todo, Ahora se continua con la instalación

   
   

INSTALACIÓN DE ORACLE 10G EN DEBIAN ETCH
Pues inicialmente, vamos a descomprimir de la siguiente forma el archivo descargado:

gunzip ship.XXXX.cpio.gz cpio -idmv <>

Con esto se crea el directorio Disk1 el cual contiene el instalador de oracle 10g llamado runInstaller, lo ejecutamos:
./runInstaller.sh

En el caso de que en las comprobaciones de la pantalla arroje un error y no se pueda proceder con la instalación, es probable que se tr ate de que el servidor x no se encuentra iniciado , (bastante comun), para solucionarlo como root tratar de ejecutar lo siguiente

xhost +

Esto mostrara un mensaje informando que el servidor x se encuentra listo para recibir nuevos clientes, después como el usuario normal creado anteriormente se vuelve a ejecutar el instalador


PASOS DE INSTALACIÓN:
1. En el primer paso se selecciona instalación avanzada:

2. Se dejan los valores por defecto:

 

3. Se elige edición Enterprise del producto en la siguiente interfaz.

Posterior a esto se realiza la verificación del producto para validar que las librerías necesarias se encuentren instaladas y los requisitos de sistema se cumplan correctamente, posterior a esto, se selecciona el tipo de base de datos que se quiere instalar, especificando que se creara una nueva base de datos, Se introducen los datos relacionados con la misma, nombre de la BD y SID, normalmente se deja el SID generado a partir del nombre.
Se sigue el proceso de instalación con los valores por defecto hasta que se llega al punto de especificar el tipo de almacenamiento, el mas común es "Sistema de archivos" donde se especificara el directorio creado anteriormente

/u02/oradata
se continua con los valores por defecto las próximas 2 pantallas, y se procede a instalar cuando aparece el botón Instalar, después de aproximadamente 20 minutos o 30 dependiendo de tu computadora, veras que el instalador termina y comienza la creación de la nueva base de datos, esto tarda aproximadamente 5 o 10 minutos.
Finalmente se muestran las rutas de acceso a las herramientas instaladas, tales como Oracle Enterprise Manager 10g, iSQLPlus UltraSearch normalmente ubicadas en las direcciones:

URL de Ultra Search:

http://localhost:5620/ultrasearch

URL de Herramienta de Administración de Ultra Search:

http://localhost:5620/ultrasearch/admin

URL de iSQL*Plus:

http://localhost:5560/isqlplus

URL de Enterprise Manager 10g Database Control:

http://localhost:5500/em

Con esto finaliza la instalación y configuración de Oracle 10g en Debian Etch, ahora se explicara un poco las bases previas para usar las herramientas, y servicios relacionados:


1. Creación del Servicio de Oracle:

Si se necesita que la base de datos arranque con el sistema (algo que personalmente no recomiendo mucho por el tema de consumo innecesario de recursos) se deberá editar el archivo de configuración /etc/oratab en este fichero se especifica lo siguiente:

*:/u01/app/oracle/product/10.1.0/db_1:N

SID_BD:/u01/app/oracle/product/10.1.0/db_1:Y

Luego se crea el script de arranque en /etc/init.d/oracle con el siguiente contenido:

#!/bin/bash

#

# Run-level Startup script for the Oracle Instance and Listener

#

# chkconfig: 345 91 19

# description: Startup/Shutdown Oracle listener and instance

ORA_HOME="/u01/app/oracle/product/10.1.0/db_1"

ORA_OWNR="oracle"

# if the executables do not exist -- display error

if [ ! -f $ORA_HOME/bin/dbstart -o ! -d $ORA_HOME ]

then

echo "Oracle startup: cannot start"

exit 1

fi

# depending on parameter -- startup, shutdown, restart

# of the instance and listener or usage display

case "$1" in

start)

# Oracle listener and instance startup

echo -n "Starting Oracle: "

# start TNS listener

su - $ORA_OWNR -c "$ORA_HOME/bin/lsnrctl start"

# start database

su - $ORA_OWNR -c $ORA_HOME/bin/dbstart

touch /var/lock/subsys/oracle

echo "OK"

;;

stop)

# Oracle listener and instance shutdown

echo -n "Shutdown Oracle: "

# stop TNS listener

su - $ORA_OWNR -c "$ORA_HOME/bin/lsnrctl stop"

# stop database

su - $ORA_OWNR -c $ORA_HOME/bin/dbshut

rm -f /var/lock/subsys/oracle

echo "OK"

;;

reload|restart)

$0 stop

$0 start

;;

*)

echo "Usage: $0 start|stop|restart|reload"

exit 1

esac

exit 0

Luego se le dan permisos de ejecución

chmod 755 oracle

Y se añaden los niveles de ejecución

ln -s /etc/init.d/oracle /etc/rc.d/rc2.d/S99oracle

ln -s /etc/init.d/oracle /etc/rc.d/rc3.d/S99oracle

ln -s /etc/init.d/oracle /etc/rc.d/rc4.d/S99oracle

ln -s /etc/init.d/oracle /etc/rc.d/rc0.d/K01oracle

ln -s /etc/init.d/oracle /etc/rc.d/rc6.d/K01oracle

Y con esto basta ya cada vez que se inicie el sistema oracle es iniciado también, en el caso de que se requiera iniciar o detener la base de datos, se puede ejecutar como cualquier servicio de GNU/Linux ejecutando desde /etc/init.d/

./oracle start|stop

Ahora vamos con los servicios:
Listener:
Para que clientes como SQLDeveloper puedan conectarse a la base de datos Oracle y hacer uso de ella, es necesario que el servicio de red este disponible, inclusive aunque dicho cliente se ejecute en la maquina local, esto se consigue con un Listener de la base de datos, dicho servicio se crea normalmente con un fichero de configuración muy importante ubicado en $ORACLE_HOME/network/admin/listener.ora, en el se especifica el tipo de servicio de red que se presta y la dirección de la base de datos, en un plano mas general pueden crearse los listeners manualmente o utilizar la utilidad del Asistente de Configuración de Red el cual es una interfaz sencilla que permite crear los listeners con un sencillo paso a paso de forma gráfica.
Para ejecutarlo basta con escribir en consola el comando netca en pasos anteriores se han configurado las variables de entorno y el path para el usuario oracle, se espera que siempre se ejecuten todos los comando que se dan a continuación con dicho usuario. En el caso de que el comando netca no sea reconocido, todas las utilidades de oracle se encuentran en el directorio $ORACLE_HOME/bin/ desde donde se podrán ejecutar todos los comandos sin ningún tipo de dificultad como si se tratara de un servicio normal. Otro comando que permite una administración mas completa de los servicios en red es netmgr Ahora se puede ejecutar el comando de inicio del listener, es un servicio que permite iniciar y detener el listener con el comando
lsnrctl start|stop

Se debe tener precaución en ejecutarse con el usuario adecuado, es decir el usuario Oracle para que no falle el inicio o parada del servicio.

ISQLPlus:
Al igual que el listener, se trata de un servicio de Oracle que viene desde la versión 9i, donde se pueden ejecutar los comandos SQL ingresados por un usuario desde una consola Web por medio del puerto 5620 normalmente, esta ruta completa se da cuando se termina de instalar el motor.
para iniciar o detener el servicio basta con ejecutar el comando

isqlplusctl start|stop

Y ya esta, se puede acceder desde un navegador web a esta herramienta haciendo uso de Login y Password.

OEM (Oracle Enterprise Manager) :
Se trata de una potente herramienta incluida desde oracle 10g que permite visualizar y generar reportes muy variados sobre administración, rendimiento y tuning de la base de datos, permite realizar tareas administrativas de mantenimiento y generación de copias de seguridad, bastante robusta y fácil de manejar, se encuentra en un entorno web, asi que al igual que isqlplus se puede acceder a ella por medio de un navegador web y con un usuario con rol de sysdba, normalmente usuario sys. Para iniciar o detener el servicio se ejecuta:

emctl start|stop dbconsole

SQLPLUS:
Otra opción menos interactiva pero bastante robusta y común para los desarrolladores de oracle desde antiguas versiones es SQLPlus, basada en una consola de texto, donde se permite conectar a una base de datos oracle sin necesidad de tener un listener activo en el momento de la conexión
Su uso típico es el siguiente:

sqlplus /nolog
SQL> conn sys/passdesys as sysdba
Conectado.
SQL> SELECT * FROM V$INSTANCE;

INSTALANDO SQLDEVELOPER PARA CONEXIÓN A BASE DE DATOS ORACLE 10G:

Ahora se procede a instalar SQLDeveloper, el procedimiento es realmente simple, solamente se requiere descargar SQLDeveloper desde el sitio oficial de Oracle aqui
En el enlace que dice SQLDeveloper 1.5 se podrá descargar el software que vendrá en forma de un paquete RPM, el cual se puede convertir posteriormente en un paquete .deb por medio del comando alien el cual se puede instalar con un simple comando de instalación con APT
Para ejecutarlo saldría en consola algo similar a esto:

jdaanialdebian:/home/oracle# alien sqldeveloper-1.5.54.40-1.noarch.rpm
Warning: Skipping conversion of scripts in package sqldeveloper: postinst
Warning: Use the --scripts parameter to include the scripts.
sqldeveloper_1.5.54.40-2_all.deb generated
jdaanialdebian:/home/oracle#

Esto indica que el paquete .deb ha sido generado y puede instalarse sin ningun problema con el uso del comando dpkg de la siguiente forma:

jdaanialdebian:/home/oracle# dpkg -i sqldeveloper_1.5.54.40-2_all.deb
(Leyendo la base de datos ...
131324 ficheros y directorios instalados actualmente.)
Preparando para reemplazar sqldeveloper 1.5.54.40-2 (usando sqldeveloper_1.5.54.40-2_all.deb) ...
Desempaquetando el reemplazo de sqldeveloper ...
Configurando sqldeveloper (1.5.54.40-2) ...
jdaanialdebian:/home/oracle# sqldeveloper

Oracle SQL Developer
Copyright (c) 2008, Oracle. All rights reserved.

Type the full pathname of a J2SE installation (or Ctrl-C to quit), the path will be stored in ~/.sqldeveloper/jdk

En este punto al ser la primera vez que se ejecuta el instalador pide la ruta de instalación del JDK de Java, en el caso de que no sepas como instalarlo y configurarlo, puedes remitirte a una entrada anterior a este blog donde se explican este tipo de tareas y algunas otras aqui
Una vez se configura esto, ya se puede ejecutar el SQLDeveloper con tan solo escribir sqldeveloper en la consola.

Por el momento es todo, espero que esta guiá le sirva de algo a aquellas personas que necesitan ayuda con Oracle 10g en GNU/Linux Debian.

JDAANIAL.

[+/-] Continuar leyendo...