Archivo

Posts Tagged ‘JDeveloper’

ADF tips: Reglas de auditoría en JDeveloper – Crea tus propias reglas (Integración continua)

septiembre 2, 2015 Deja un comentario

ADF tips

Siguiendo esta serie de posts sobre reglas de auditoría, donde ya hemos explicado cómo crear nuestra propia regla de auditoría y cómo crear un transform que ayude al programador a codificar correctamente, en este post final explicaremos cómo integrar nuestra auditoría en un entorno de integración continua.

Por ejemplo en un entorno con Jenkins donde nuestra aplicación se genera mediante un job que obtiene el código, lo compila y realiza el deploy en nuestro weblogic, en este job podemos añadir un paso más, antes de realizar el deploy, que lance nuestras reglas de auditoría.

Para ello primero generaremos el fichero xml de nuestras reglas de auditoría, iremos a preferencias/audit:

xml

Generaremos nuestro fichero ReglasAuditoria.xml y después lo importamos para que se instale como opción de auditoría, entonces desde la linea de comandos podremos ejecutar lo siguiente:

C:\Oracle\Middleware12\Oracle_Home\jdeveloper\jdev\bin>ojaudit -profile ReglasAvanttic "C:/JDeveloper/mywork12C13/TestAudit/TestAudit.jws" -output TestAudit_auditoria.html -style audit-html

Esto nos generará el fichero TestAudit_auditoria.html donde podremos ver si nuestro código cumple las reglas o no. El resultado será algo como esto:

audit-html

 

 

También podemos añadir a nuestras reglas, las reglas que ya vienen por defecto en JDeveloper y reglas de terceros como las de ADF EMG.

En resumen, en esta serie de posts hemos visto que utilizando las reglas de auditoría que proporciona JDeveloper podemos aplicar nuestras especificaciones QA en tiempo de compilación, cómo ayudar al programador a que su código cumpla estas especificaciones y cómo evitar que en un entorno de integración continua tengamos un código que no cumpla estas reglas.

Bibliografía utilizada para realizar estos posts:

Categorías:ADF / Java Etiquetas: , ,

ADF tips: Reglas de auditoría en JDeveloper – Crea tus propias reglas (Modificador)

ADF tips

Siguiendo con la serie de posts sobre reglas de auditoria, donde ya hemos explicado cómo crear nuestra propia regla de auditoria creando nuestro analizador, ahora explicaremos cómo crear un Transform que nos sugiera el código que debemos poner.

Siguiendo el ejemplo de nuestra regla de auditoria, que no nos deja tener en el código la sentencia System.out.print porque por ejemplo estamos usando ADFLogger y en nuestras clases todas tienen el siguiente código de inicialización del ADFLogger:

 private static ADFLogger logger = ADFLogger.createADFLogger(TestAudit.class);

Vamos a crear una clase Transform que nos cambiará el código System.out.println(‘texto’); por logger.info(‘texto’);

Para hacer esto modificaremos el fichero Extension.xml definiendo nuestra clase y mapeándola con la clase Analizer definida anteriormente, quedando así:

<extension id="com.avanttic.extension.auditreglas" version="1.0.0" esdk-version="2.0" rsbundle-class="com.avanttic.extension.auditreglas.AuditReglas" xmlns="http://jcp.org/jsr/198/extension-manifest">
 <name>${EXTENSION_NAME}</name>
 <owner>${EXTENSION_OWNER}</owner>
 <trigger-hooks xmlns="http://xmlns.oracle.com/ide/extension">
 <!-- TODO Declare triggering functionality provided by extension: com.avanttic.extension.auditreglas -->
 <triggers>
   <audit-hook id="com.avanttic.extension.auditreglas">
    <trigger>
      <technology>Java</technology>
    </trigger>
    <category-definition id="AuditAvanttic"/>
    <category-definition id="ReglaJava">
       <category>AuditAvanttic</category>
    </category-definition>
    <transform-definition id="transform-system-print">
       <transform-class>com.avanttic.extension.auditreglas.transform.java.JavaTransformImpl</transform-class>
    </transform-definition>
    <rule-definition id="system-print">
      <category>ReglaJava</category>
      <enabled>true</enabled>
      <severity>error</severity>
      <transform-binding>
         <transform>transform-system-print</transform>
      </transform-binding>
    </rule-definition>
    <analyzer-definition>
        <analyzer-class>com.avanttic.extension.auditreglas.analizers.java.JavaAnalizerImpl</analyzer-class>
    </analyzer-definition>
   </audit-hook>
 </triggers>
 </trigger-hooks>
 <hooks>
 <!-- TODO Declare functionality provided by extension: com.avanttic.extension.auditreglas -->
 </hooks>
</extension>

Explicación de los nuevos tags:

  • transform-definition: Define una clase java que extenderá  oracle.jdeveloper.audit.transform.Transform y servirá para hacer la modificación.
  • transform-binding: Mapeamos nuestro modificador con el Analizer.

Después crearemos la clase java:

 package com.avanttic.extension.auditreglas.transform.java;

import oracle.javatools.parser.java.v2.internal.symbol.stmt.ExpressionStmt;

import oracle.jdeveloper.audit.java.JavaTransformAdapter;
import oracle.jdeveloper.audit.java.JavaTransformContext;
import oracle.jdeveloper.audit.transform.Transform;

public class JavaTransformImpl extends Transform {
 public JavaTransformImpl() {
 super(new JavaTransformAdapter());
 }

 public void apply(JavaTransformContext context, ExpressionStmt stmt) {
  // Aqui pondremos el codigo que realiará las modificaciones
 }
}

Una vez tengamos esto haremos el deploy de nuestro proyecto de reglas y comprobaremos cómo nos hace el cambio:

transform1

transform2

Conclusión: Hemos visto cómo en tiempo de codificación podemos controlar que se cumplan nuestras especificaciones QA  y cómo podemos ayudar al programador a cumplirlas, al poder sugerirle el código correcto que tiene que usar.

Categorías:ADF / Java Etiquetas: , ,

ADF tips: Reglas de auditoría en JDeveloper – Crea tus propias reglas (Analizador)

ADF tips

En un post anterior explicamos cómo activar las reglas de auditoría que JDeveloper ya lleva por defecto. En este post explicaremos cómo crear nuestra propia regla de auditoría. JDeveloper nos da una herramienta para poder ampliar e implementar nuestras propias reglas de auditoria, mediante lo que denomina extensiones. Lo primero que haremos será instalar la en nuestro JDeveloper 12c las librerías para poder generar extensiones, realizaremos los siguientes pasos:

Iremos a check for updates:

check

Después instalaremos Extension SDK  y tendremos que reiniciar JDeveloper.

extension

Una vez tengamos Extension SDK instalado comenzaremos a crear nuestras propias reglas, sobre la aplicación que creamos en el post anterior.

Lo primero será crear una aplicación tipo Extension Application:

apExtension

Esta aplicación por ejemplo la llamaremos AuditReglas, Se nos creara una aplicación como vemos en la siguiente imagen:

apliAudit

Aquí podemos ver los dos ficheros de configuración de la extensión MANIFEST.MF y extension.xml, editaremos el fichero extension.xml y iremos a overview desde aquí se ven los dos ficheros.

Lo primero que haremos será  ir a la pestaña dependencias y añadiremos las dependencias necesarias para nuestra extensión:

  1. oracle.ide
  2. oracle.jdeveloper
  3. oracle.ide.audit
  4. oracle.ide.audit.core
  5. oracle.ide.xmlef
  6. oracle.javatools
  7. oracle.javatools-nodeps
  8. oracle.jdeveloper.properties

Leer más…

Categorías:ADF / Java Etiquetas: , ,

ADF tips: Reglas de auditoría en JDeveloper – Introducción

Este post es el primero de una serie dedicados a las reglas de auditoría en JDeveloper, donde veremos las ventajas que nos proporcionan para tener un código que cumpla los requisitos de QA de nuestra empresa.

En este post os mostraré una visión rápida de las auditorías que proporciona JDeveloper, por defecto, para nuestro código. La idea es que en tiempo de codificación ya tengamos una herramienta de calidad del código (QA) y no lo dejemos todo para el final de nuestro proyecto, como ocurre normalmente, para esto JDeveloper nos proporciona las reglas de auditoría.

Utilizaremos JDeveloper 12c versión 12.1.3.0.0. Veremos una compilación de código sin las reglas de auditoría y después activándolas.

Empezaremos creando una aplicación.

Crear aplicación ADF

Ahora crearemos una clase java simple y la compilaremos. Veremos que no tenemos ningún mensaje de compilación.

Clase java

Ahora activaremos las reglas de auditorÍa que están en tools/preferences/audit, marcaremos el check de Code Assist y Audit During Compile.

Leer más…

Categorías:ADF / Java Etiquetas: , ,

Modificar archivos propiedades WebLogic 12c en tiempo de ejecución

Muchas veces nos encontramos con la necesidad de modificar en tiempo de ejecución los valores de variables definidas en archivos .properties. Para que estos archivos puedan ser modificados por las aplicaciones o por otro proceso externo (incluso por nosotros mismos mediante un editor de texto) deberán estar situados en una carpeta del sistema de archivos y hallarse fuera de cualquier paquete .ear, .war o .jar.

Tenemos que decidir como accedemos a los archivos en disco:

  1. Usando una ruta absoluta y cargado el archivo, típicamente mediante la clase File, por ejemplo: File file = File(“C:\\abcfolder\\textfile.txt”);
  2. Usando una ruta absoluta obtenida previamente de un archivo .properties incluido en la aplicación, a la que se concatena el nombre del archivo
  3. Apoyándonos en el cargador de clases de la aplicación y creando una librería compartida que incluya una carpeta ‘classes’, donde pondremos nuestros archivos .properties.

Elegir la primera de las opciones no es una buena práctica: si cambia la ubicación del archivo, estaremos obligados a volver a compilar y desplegar nuestra aplicación.

La segunda es una buena opción, pero la tercera tiene la ventaja de poder versionar fácilmente los recursos almacenados en el disco.

Además, los programadores de la aplicación podrá usar el cargador de clases para localizar el archivo sin especificar la ruta o creando una estructura de sub-carpetas a partir de la raíz del classpath (la carpeta ‘classes’), si así lo desean.

Vamos a realizar una pequeña aplicación que haga uso de una librería compartida con un único archivo de propiedades conteniendo dos variables: usuario y contraseña. Si ambos valores introducidos en la página inical coinciden con los valores en el archivo, se mostrará una segunda página indicándonos que hemos tenido éxito en la autenticación; de lo contrario, nos llevará a una tercera diciendo que el usuario o la contraseña no coinciden. Con este sencillo ejemplo podremos cambiar el archivo Credentials.properties y verificar que la aplicación toma los cambios cada vez que suceden.

Veamos la estructura que tendrá nuestra librería compartida antes de ser desplegada:

Estructura de archivos de la libraría

Estructura de archivos de la libraría

Si desplegamos esta carpeta en Weblogic como ‘Biblioteca’ y en el apartado ‘Accesibilidad de Origen’ marcamos la opción ‘Usar Valores por Defecto Definidos por Destinos de Despliegue’ estaremos indicando al servidor de aplicaciones que los archivos localizados en ‘WEB-INF/classes’ serán modificables en tiempo de ejecución por las aplicaciones que hagan referencia a esta librería desde sus weblogic.xml.

La aplicación aquí descrita tiene el siguiente contenido dentro de ‘weblogic.xml’

mikel_blog_modifPropWeblogicXML

La etiqueta <librar-ref> permite a la aplicación hacer uso de la librería cuya versión de implementación detalla mediante <implementation-version>

Y ya sólo nos queda conocer cómo accede nuestra aplicación a este recurso. La forma más sencilla es con un método en el ManagedBean de la página principal que será invocado cuando se pulse el botón ‘Login’.

mikel_blog_modifPropJava

Desplegamos la librería compartida y a continuación la aplicación.

mikel_blog_modifPropResult1

mikel_blog_modifPropResult2

Podéis descargar el proyecto completo para JDeveloper aquí.

Categorías:WebLogic Etiquetas: , ,

ADF tips: Plantillas de código en JDeveloper

En este tip hablaremos de 2 opciones que nos brinda JDeveloper para definir y utilizar fragmentos de código reutilizable.

La primera opción la encontraremos dentro de la paleta de componentes, donde podemos definir “Code Snippets”. La forma de utilizarlos es muy sencilla, simplemente debemos arrastrar el “snippet” en la línea donde queremos utilizarlo. Esta opción tiene una gran limitación, y es que el código definido aquí debe ser código fijo, no podemos definir una serie de variables a reemplazar cada vez que utilicemos el código.

Aquí podemos ver en imágenes cómo definir un Code Snippet y el resultado final:

adftips_template1

adftips_template2

    // ---------------------------------------------------
    // ---    Custom code
    // ---------------------------------------------------

    // ---------------------------------------------------
    // ---    Auto generated code / Do not modify
    // ---------------------------------------------------

La siguiente alternativa ofrece mucho más juego, se trata de la opción de “Code Templates”. Ésta podemos encontrarla dentro de las preferencias de nuestro JDeveloper. Desde aquí definiremos un atajo de teclado que estará disponible en un contexto determinado (Java Code, CSS, HTML, Anywhere….) y una breve descripción.

adftips_template3

Con este método podemos definir el código fuente para ser reutilizable por todo un equipo de desarrollo, haciendo uso de variables si fuese necesario (definidas entre símbolos $).

Leer más…

ADF tips: Cómo enlazar componentes de vista a un Managed Bean

En este tip explicaremos una forma alternativa con la que acceder a componentes JSF desde un managed bean.

La forma más común es añadir un objeto UIComponent como atributo de nuestro bean, con sus accessors correspondientes y enlazar el componente en la página con este atributo. Esta es la vía que JDeveloper nos da por defecto para acceder a componentes JSF desde un bean:

binding="#{myBeanScope.MyBean.myRichcomponentName}"
UIComponent myRichComponentName;

public void setMyRichComponentName(UIComponent myRichComponentName){
   this.myRichComponentName = myRichComponentName;
}

public UIComponent getMyRichComponentName(){
   return myRichComponentName;
}

Esta opción nos puede ocasionar varios problemas. El primero de ellos es que estos objetos no son Serializables, con lo que en entornos de alta disponibilidad obtendremos errores. Otra contra es que el consumo de memoria es elevado, además de que el árbol JSF no será liberado completamente tras su uso y estos objetos perdurarán en memoria más tiempo del que realmente necesitamos.

Llegados a este punto podemos decir que la forma estándar no es del todo óptima, pero… ¿qué otras opciones tenemos?

Existe la posibilidad de utilizar Component Reference de Apache Trinidad (ver detalles de la API), mediante el cual no almacenaremos el componente JSF sino que guardaremos una referencia de acceso directo al componente del árbol JSF. Con esto el consumo de memoria bajará considerablemente y no tendremos objetos en memoria que no necesitemos. Tendríamos que sustituir el código anterior por algo similar a esto:

binding="#{myBeanScope.MyBean.myRichcomponentName}"
private ComponentReference myRichComponentName;

public UIComponent getMyRichComponentName(){
   return myRichComponentName == null ? null : myRichComponentName.getComponent();
}

public void setMyRichComponentName(UIComponent myRichComponentName) {
   myRichComponentName = ComponentReference.newUIComponentReference(myRichComponentName);
}

La parte negativa de este tip es que no podemos configurar JDeveloper para que automáticamente haga uso del componente. Pero gracias al uso de plantillas de código podemos aplicarlo sin tener que recordar las líneas exactas.

El uso de plantillas de código en JDeveloper lo comentaremos en un próximo ADF tip.