Eclipse aumentando su rendimiento (Performance)

Hola

En esta entrada voy a hablar sobre eclipse el IDE más usado por la gente (eso creo) , en esta ocasion voy a explicar como aumentar el rendimiento de nuestro ide favorito para programar en Java. Como mucho de vosotros ya sabeis que eclipse esta hecho con Java con la libreria SWT. Al ser una aplicación java pues logicamente esta funciona sobre una JVM, como ya habréis imaginado para aumentar la velocidad de eclipse tenemos que poner o tocar parametros de configuración de la JVM.

Lo ideal seria tener memoria RAM infinita entonces podriamos a nuestro eclipse uan burrada de memoria, pero por desgracia eso no es asi la memoria RAM es finita. Actualmente todo los PC o Portatiles tiene 4 o más de GB de RAM(en caso contrario intenta aumentar tu memoria ram). Yo voy a poner una configuración para un ordenador con 4 GB de RAM. Para tocar los paramentros de ejecución de eclipse para JVM tenemos que abrir el fichero eclipse.ini que se encuentra en la carpeta donde tengamos eclipse instalado.

${HOME_ECLIPSE}/eclipse.ini

-vmargs
-server
-Xmn128m
-Xms1024m
-Xmx2048m
-Xss2m
-XX:PermSize=512m
-XX:MaxPermSize=512m
-XX:+UseParallelGC
-Xverify:none

Algunos parametros estaran y otros no, como veis lo que hago es reservar la mitad de la memoria ram para eclipse este valor podemos bajarlo a un 1,5GB para dejar 2,5GB al sistema operativo y otros programas. (Yo con esto funciono bien). Con esto ya tenemos configurado el eclipse para que no de problemas con la falta de memoria.

Ahora vamos a tocar configuraciones propias del eclipse, seguramente cuando arrancamos el eclipse trada bastante en arranca, eso es debido a la gran cantidad de plugin que tenemos instalado en nuestro IDE. ¿Cómo podemos hacer que el arranque sea más rápido?

Solo tenemos que ir a la ventada:

windows-->Preferences

Una vez pinchamos en:

General-->Startup and Shutdown

Como podemos ver en esta caso yo tengo desactivados todos, pero cada uno puede elegir la configuración  que mas le interese.


Otra cosa que nos molesta es que cuando tenemos mucho proyectos abiertos esta todo el rato validando o compilando(si son proyectos pequeños no se nota, pero si son grande si se nota y mucho).
En la misma pantalla de Preferences, en arbol buscamos Validation, hay activamos o desactivamos las opciones que nos interese.

Esta es la configuración general pero luego para cada proyecto podemos sobreescribir la configuraciones:

Botón derecho sobre raiz del proyecto y Validation.

Puesta a punto

Por ultimo esta tarea hay que hacer cada cierto tiempo, es una puesta punto al eclipse. Cuando estamos trabajando con nuestro eclipse solemos utilizar atajos sobre todo:

CRTL+SHIFT+R, CRTL+SHIFT+T, CRTL+SHIFT+O

Para buscar un fichero en nuestros proyectos, esto lo que hace es que eclipse escriba en el carpeta de .metadata de nuestro workspace:

${WORKSPACE}/.metadata/.plugins/org.eclipse.jdt.core

Hay mucho ficheros los eliminamos y ya esta. Otra cosa que hay que eliminar el historia local que tiene eclipse con los ficheros que trabajamos (no es cvs, svn y git), es que eclipse te guardar las modificaiones que has hecho en un fichero durante un cierto tiempo, para borrar esos fichero tenemos que ir a:

${WORKSPACE}/.metadata/.plugins/org.eclipse.core.resources/.history

Hay eliminamos todos los ficheros y carpetas.

Con esto ya tenemos mas que tuneado nuestro eclipse para trabajar máximo rendimiento.

Saludos

Paginacion Mysql, Oracle y SQLServer

Hola

En esta entrada voy ha explicar como hacer paginación en la tres bases de datos más usadas en el mundo, es decir las que he usado yo hasta hoy, lo primero es decir que es paginación.

Paginación

La paginación consistente en traerse una cantidad de registros y de ser necesarios más saltar a una página posterior.

Cuando usamos ORM, Hibernate, Mybatis, etc..., Lo mejor es hacer sql nativas que van a ir muy rápidas. Lo malo es que cada base de datos tiene un forma distintas de hacerlo, no hay una query común que sirva para todas las bases de datos.

Mysql

Mysql tiene la clasula limit y offset, limit le indica el número máximo de registro y offset indica la posición del registro que se va empezar.

   

select columna_1, columna_2 
from tabla 
where columna_3 = 'algo' 
order by columna_1 
limit 10  
offset 0

Oracle

Oracle tiene la clasula rownum, rownum es una seudo columna que devuelme para cada registro del resultado de la consulta una poscion numerica.

SELECT * FROM ( 
SELECT a.*, rownum minimun FROM ( 
select columna_1, columna_2 from tabla
 where columna_3 = 'algo'
 order by columna_1
 ) a
 WHERE rownum <= 10
)WHERE minimun > 0

SQLServer

SQLServer tiene la clasula top, top se emplea para obtener sólo  una cantidad limitada de registros, los primeros n registros de una consulta.

select TOP 10 b.*
 FROM
 (
 SELECT ROW_NUMBER() OVER 
 (
 order by columna_1
 ) as row_number, *
 FROM
 (
 select columna_1, columna_2
 from tabla
 ) AS a
 where columna_3 = 'algo'
) AS b
 where b.row_number > 0

Autenticación http-basic spring y weblogic

Hola

En esta entrada voy hablar sobre como usar spring security con http-basic y weblogic.

Cuando usamos spring-security como método de autenticación http-basic y desplegamos en weblogic, sucede algo rar, que es que nos pregunta dos veces el usuario y password. ¿Porque sucede esto?

Lo que pasa es que cuando se lanza una petticion a nuestro servidor, salta primero el filtro de  spring pidendo el usario y password. Cuando aceptamos weblogic detecta que en la cabecera de la petición va una petición con autenticación http-basic entonces como no se encuentra ese usuario en su sistema de usarios. nos saca otra vez la peticion de usuario y password.¿Como solucionar este problema?

Fácil desactivando a weblogicla validación forzosa de http-basic. Lo que hay que hacer es tocar un fichero de weblogic. que se encuentra el la siguiente ruta:

MW_HOME/user_projects/domain/DOMAIN_NAME/config/config.xml

Buscar la linea y poner el valor false.

<enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credentials>

JAX-RS (Jersey y RestEasy)

Java API for RESTful Web Services es una la Api de Java que proporciona soporte para la creación de servicios web de acuerdo con la defición de Api Rest.

A partir de la versión 1.1 en adelante, JAX-RS forma parte de Java EE 6. Unas de las características de JAX-RS es la utilización de anotaciones para el
rápido desarrollo de los recursos del servicio web. A continuación un listado las anotaciones.

Lista de anotaciones de creación del recurso:

•     @Path especifica la ruta de acceso relativa para una clase recurso o método.
•     @GET, @PUT, @POST, @DELETE y @HEAD especifican el tipo de petición HTTP de un recurso.
•     @Produces especifica los tipos de medios MIME de respuesta.
•     @Consumes especifica los tipos de medios de petición aceptados.

   
Lista de anotaciones de obtención de  información de la solicitud:

•     @PathParam enlaza el parámetro a un segmento de ruta.
•     @QueryParam enlaza el parámetro al valor de un parámetro de consulta HTTP.
•     @MatrixParam enlaza el parámetro al valor de un parámetro de matriz de HTTP.
•     @HeaderParam enlaza el parámetro a un valor de cabecera HTTP.
•     @CookieParam enlaza el parámetro a un valor de cookie.
•     @FormParam enlaza el parámetro a un valor de formulario.
•     @DefaultValue especifica un valor por defecto para los enlaces anteriores cuando la clave no es encontrada.
•     @Context devuelve todo el contexto del objeto. (Por ejemplo: @Context HttpServletRequest request)   

Una vez vista las características JAX-RS como bien dice es una api de java ahora vamos a ver un listado de implementaciones de esta api:

•     Jersey (Oracle) Implementación de Referencia
•     RestEasy (Jboss)
•     ApacheCXF (Codigo Abierto)

Como siempre esto se ve mejor en un ejemplo actualemente tengo 2 ejemplos, usando Jersey y RestEasy, en ambos ejemplos hay un cliente para consumir los servicios rest, esto ejemplos estan probado en JBOSS 6.1 EAP, además estos ejemplos estan
 configurado para usar con Spring.

Acceso al ejemplo

Api Rest

En esta entra voy a explicar los que es un api Rest

¿Qué es REST?
REpresentational State Transfer, es una arquitectura de tipo SOA que esta basado en HTTP.

REST nos permite crear servicios que pueden ser comsumidos por cualquier dispositivo, cliente o otro servicio REST que conozca el protocolo HTTP,
como consecuencia esto los servios rest son mas simples que otras alternativas que se han usado en los últimos años como SOAP y XML-RPC.

REST se definió en el 2000 por Roy Fielding, coautor principal también de la especificación HTTP.

Existen tres niveles de calidad a la hora de aplicar REST en el desarrollo de una API
Estos niveles son:

•     Uso correcto de URIs
•     Uso correcto de HTTP.
•     Implementar Hypermedia.

   
Una de las caracteriscas de Rest es un servicio sin estado es decir toda la información que se necesaria para mostrar la
información que se solicita debe estar en la consulta por parte del cliente.

Nivel 1: Uso correcto de URIs

Denominamos recurso el acceso a la información del servicio rest.

Las URL, Uniform Resource Locator , son un tipo de URI, Uniform Resource Identifier, que nos permite de identificar de forma única el recurso,
nos permite localizarlo para poder acceder a él o compartir su ubicación.

Estructura de una URL:

{protocolo}://{dominio o hostname}[:puerto (opcional)]/{ruta del recurso}?{consulta}

Como siempre hay unas reglas para el nombrado de los recursos de nuestras Apis Rest:

•     Los nombres de URI no deben implicar una acción, por lo tanto debe evitarse usar verbos en ellos.
•     Deben ser únicas, no debemos tener más de una URI para identificar un mismo recurso.
•     Deben ser independiente de formato.
•     Deben mantener una jerarquía lógica.
•     Los filtrados de información de un recurso no se hacen en la URI.

Nivel 2: HTTP

Para desarrollar APIs REST se debe dominar y conocer los siguientes aspectos:

•     Métodos HTTP
•     Códigos de estado
•     Aceptación de tipos de contenido  

Métodos.

Como hemos nombrado anteriormente, en la url's no debemos poner la accion porque HTTP nos proporciona los siguientes métodos con los cuales debemos operar:

•     GET:  consultar recursos
•     POST:  crear recursos
•     PUT:  editar recursos
•     DELETE:  eliminar recursos.
•     PATCH: editar partes concretas de un recurso.   

Códigos de estado.

Uno de los errores más frecuentes a la hora de construir una API suele ser el desarrollo
de APIs con códigos de error propios.

Ejemplo

Petición
========
PUT /coches/123

Respuesta
=========
Status Code 200
Content:
{
  success: false,
  code:    734,
  error:   "datos insuficientes"
}

Como podemos ver en el ejemplo se devuelve un código de estado 200, que significa que la petición se ha realizado correctamente,
pero, estamos devolviendo en el cuerpo de la respuesta un error y no el recurso solicitado en la URL.

HTTP tiene un gran abanico muy amplio que cubre todas las posibles indicaciones que vamos a tener que añadir en nuestras respuestas cuando las operaciones han ido bien o mal.

Petición
========
PUT /caches/123

Respuesta
=========
Status Code 400
Content:
{
  message: "se debe especificar un id de coche"
}

Tipos y formatos de contenido.

Cuando hablamos sobre URLs, vimos también que no era correcto indicar el tipo de formato de un recurso al cual queremos acceder o manipular.

HTTP nos permite especificar en qué formato queremos recibir el recurso, pudiendo indicar varios en orden de preferencia, para ello utilizamos el header Accept.

Nuestra API devolverá el recurso en el primer formato disponible y, de no poder mostrar el recurso en ninguno de los formatos indicados por el cliente mediante el header Accept, devolverá el código de estado HTTP 406.

Nivel 3: Hypermedia.

Con Hypermedia básicamente añadimos información extra al recurso sobre su conexión a otros recursos relacionados con él.

Aquí tenemos un ejemplo:    

<pedido>
     <id>666</id>
     <estado>Procesado</estado>

     <links>

       <link rel="factura">

        http://example.com/api/pedido/666/factura 

           </link> 

    </links>   

 </pedido>

En este ejemplo vemos cómo indicar en un xml que representa un pedido, el enlace al recurso de la factura relacionada con el mismo.

Sin embargo, necesitamos que el cliente que accede a nuestra API entienda que esa información no es propia del recurso, sino que es información añadida que puede utilizar para enlazar el pedido con la factura.

Para ello conseguir esto, debemos utilizar las cabeceras Accept y Content-Type, para que tanto el cliente como la API, sepan que están hablando hypermedia.

Por ejemplo:

Petición
========
GET /pedido/666
Accept: application/nuestra_api+xml, text/xml

Respuesta
=========
Status Code: 200
Content-Type: application/nuestra_api+xml
Content:

<pedido>
 <id>666</id>
 <estado>Procesado</estado>
 <links>
   <link rel="factura">

http://example.com/api/pedido/666/factura

   </link>
 </links>
</pedido>

Como vemos, el cliente solicita el formato application/nuestra_api+xml de forma preferente al formato text/xml.
De esta forma, le indica al servicio web, que entiende su formato hypermedia y puede aprovecharlo.

El servicio web por lo tanto, como implementa hypermedia, le devuelve la información de recurso y la información de
hypermedia que puede utilizar el cliente.

Una vez ya ententido la teoría de Api Rest lo siguiente es implementar una Api Rest en Java.

JNDI

Hola

En esta entrada voy a hablar sobre JNDI, Jndi son las siglas de Java Naming and Directory Interface, es una interfaz de programación (API) que proporciona funcionalidades de nombrado y directorio a las aplicaciones escritas usando Java.

¿Para que sirve?

Sirve para configurar recursos compartidos para aplicaciones java organizándolos por directorio con nombres únicos.

Es un servicio de nombres que permite:

• Relacionar nombres con objetos.
• Permitir la búsqueda de un objeto por su nombre.

Por ejemplo:

• LDAP (Lightweight Directory Access Protocol)
• NDS (Novell Directory Service)
• NIS (Network Information Service) 

Cada servicio tiene una forma de acceso diferente, lo que implica que si se cambia de fabricante hay que reescribir los clientes. Es por eso que se usa JNDI como capa por encima pues ofrece un acceso común a los recursos configurados.

Ahora vamos habla de como es la arquitectura de JNDI:

La API JNDI  permite escribir código Java que realice operaciones sobre directorios. Es una API uniforme a todos los tipos de servicios de directorios. Es similar a JDBC.

Service Provider Interface (SPI) permite acceder al servicio de directorio específico de cada fabricante.
Mapea código JNDI en operaciones específicas de directorios. Es un driver JNDI.
 
Algunos conceptos de JNDI:

Vamos a ver un listado de conceptos básicos de JNDI

• Nombres Atómicos: es el componente indivisible de un nombre.
• Nombres Compuestos: es un conjunto de cero o más nombres atómicos
• Un binding es una asociación de un nombre con un objeto.
• Un contexto (context) es un objeto que contiene cero o más bindings. Cada binding tiene un nombre atómico.
• Un sistema de nombres es un conjunto de contextos.
• Un espacio de nombres (namespace) son todos los nombres contenidos en un sistema de nombres.
• Initial Context es el punto de entrada para comenzar a explorar un espacio de nombres. Es el primer contexto que se usa, es el punto de entrada para realizar las operaciones de nombres y de directorio.
• Para obtener el InitialContext se usa el InitialContextFactory y el providerURL.
• InitialContextFactory es el driver JNDI, es una clase Java. Conoce la semántica específica de una estructura de directorios particular.
• El providerURL es la URL que se usa como punto de entrada para empezar a navegar.

import javax.naming.Context;
import javax.naming.InitialContext;
public class InitCtx {

public static void main(String args[]) throws Exception {
// Definir el contexto inicial
Properties props = new Properties();
FileInputStream in = new FileInputStream(“archivo.properties”);
props.load(in);
Context ctx = new InitialContext(props);
System.err.println("Success!");
}
}

El contenido de archivo.properties es el siguiente:

 
Context.INITIAL_CONTEXT_FACTORY=com.sun.jndi.ldat.LdapCtxFactory 
Context.PROVIDER_URL=ldap://louvre:389 

Nombre de la clase del driver JNDI

Ubicación del arbol de JNDI

En el desarrolo de JEE, JNDI nos provee diferentes funciones, por ejemplo:

•  Obtener una referencia al API de transacciones (JTA)
•  Conectarse a fabricas de recursos (JDBC, JMS)
•  Localizar EJB

EJB

Hola

En esta nueva entraga voy a explicar como conectarnos remotamente a un EJB desplegado en Jboss 6.1 EAP, lo primero voy a explicar lo que es un EJB y JNDI.

Los EJB (Enterprise JavaBeans) es un componente que pertenece la JEE, los EJB se tiene que ejecutar en contenedor de EJB ´s,  por ejemplo JBOSS 6.1 EAP que implementa JEE 6.  que nos ofrece las siguientes caracteristicas:

• Comunicación remota
• Transacciones
• Control de concurrencia
• Seguridad
• etc.

Los EJB no se puede acceder directamente siempre tenemos que acceder a traves de un proxy,  Los EJB tiene dos tipos de proxy:

• LOCAL Nos permite el acceso al ejb desde la misma JVM.
• REMOTE Nos permite el acceso al ejb desde una JVM remota. 

Los proxy son los encargados de darnos todas las características que nos ofrece los EJB.  Cuando implementemos nuestro EJB tenemos que eligir entre 2 tipos:

• stateful: En un bean de sesión con estado, las variables de instancia del bean almacenan datos específicos obtenidos durante la conexión con el cliente.

• stateless: Los beans de sesión sin estado son objetos distribuidos que carecen de estado asociado permitiendo por tanto que se los acceda concurrentemente

Con esto es todo de los EJB, en la proxmia entrega os explicare JNDI. De todas formas os dejo el código para que le echeis un vistazo y lo analizes.

Código Fuente