Habilitar Servicios Rest Genexus Evo2 en adelante

En el archivo web.xml que se ubica dentro del webapps\miaplicacion\WEB-INF.

Debe incluir lo siguiente:
Dentro dela parte de servlet
               
<servlet>
    <servlet-name>JerseyListener</servlet-name>
   <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
   <init-param>
           <param-name>javax.ws.rs.Application</param-name>
           <param-value>GXApplication</param-value>
    </init-param>
   <init-param>
      <param-name>com.sun.jersey.api.json.POJOMappingFeature</param-name>
      <param-value>true</param-value>
    </init-param>                           
    <init-param>
      <param-name>com.sun.jersey.spi.container.ContainerRequestFilters</param-name>
      <param-value>com.sun.jersey.api.container.filter.GZIPContentEncodingFilter</param-value>
   </init-param>
   <init-param>
     <param-name>com.sun.jersey.spi.container.ContainerResponseFilters</param-name>
     <param-value>com.sun.jersey.api.container.filter.GZIPContentEncodingFilter</param-value>
   </init-param>                                                          
</servlet>    

Seguidamente dentro de los mappings, se debe incluir lo siguiente:
       <servlet-mapping>
                 <servlet-name>JerseyListener</servlet-name>
                <url-pattern>/rest/*</url-pattern>
      </servlet-mapping>



Luego Reiniciar el servidor.
        

Códigos de Estado HTTP 1.1 y sus Significados

Códigos de Estado HTTP 1.1 y sus Significados

En esta lista de todas los códigos de estado disponibles en HTTP 1.1 junto con sus mensajes asociados y su interpretación. Deberíamos ser cuidadosos al utilizar los códigos de estado que están disponibles sólo en HTTP 1.1, ya que muchos navegadores sólo soportan HTTP 1.0. Si tenemos que usar códigos de estado específicos para HTTP 1.1, en la mayoría de los casos querremos chequear explícitamente la versión HTTP de la petición (mediante el método getProtocol de HttpServletRequest) o reservarlo para situaciones donde no importe el significado de la cabecera HTTP 1.0.

Código de Estado	Mensaje Asociado	Significado
100	Continue	Continúa con petición parcial (nuevo en HTTP 1.1)
101	Switching Protocols	El servidor cumplirá con la cabecera Upgrade y cambiará a un protocolo diferente. (Nuevo en HTTP 1.1)
200	OK	Todo está bien; los documentos seguidos por peticiones GET y POST. Esto es por defecto para los Servlets, si no usamos setStatus, obtendremos esto.
201	Created	El servidor creo un documento; la cabecera Location indica la URL.
202	Accepted	La petición se está realizando, el proceso no se ha completado.
203	Non-Authoritative Information	El documento está siendo devuelto normalmente, pero algunas cabeceras de respuesta podrían ser incorrectas porque se está usando una copia del documento (Nuevo en HTTP 1.1)
204	No Content	No hay un documento nuevo; el navegador contínua mostrando el documento anterior. Esto es útil si el usuario recarga periódicamente una página y podemos determinar que la página anterior ya está actualizada. Sin embargo, esto no funciona para páginas que se recargan automáticamente mediante cabeceras de respuesta Refresh o su equivalente <META HTTP-EQUIV="Refresh" ...>,ya que al devolver este código de estado se pararán futuras recargas.
205	Reset Content	No hay documento nuevo, pero el navegador debería resetear el documento. Usado para forzar al navegador a borrar los contenidos de los campos de un formulario CGI (Nuevo en HTTP 1.1)
206	Partial Content	El cliente envía una petición parcial con una cabecera Range, y el servidor la ha completado. (Nuevo en HTTP 1.1)
300	Multiple Choices	El documento pedido se puede encontrar en varios sitios; serán listados en el documento devuelto. Si el servidor tiene una opción preferida, debería listarse en la cabecera de respuesta Location .
301	Moved Permanently	El documento pedido está en algún lugar, y la URL se da en la cabecera de respuesta Location. Los navegadores deberían seguir automáticamente el enlace a la nueva URL.
302	Found	Similar a 301, excepto que la nueva URL debería ser interpretada como reemplazada temporalmente, no permanentemente. Observa: el mensaje era "Moved Temporarily" en HTTP 1.0, y la constante en HttpServletResponse es SC_MOVED_TEMPORARILY, no SC_FOUND. Cabecera muy útil, ya que los navegadores siguen automáticamente el enlace a la nueva URL. Este código de estado es tan útil que hay un método especial para ella, sendRedirect. Usar response.sendRedirect(url) tiene un par de ventajas sobre hacer response.setStatus(response.SC_MOVED_TEMPORARILY) y response.setHeader("Location", url). Primero, es más fácil. Segundo, con sendRedirect, el servlet automáticamente construye una página que contiene el enlace (para mostrar a los viejos navegadores que no siguen las redirecciones automáticamente). Finalmente, sendRedirect puede manejar URLs relativas, automáticamentes las traducen a absolutas. Observa que este código de estado es usado algunas veces de forma intercambiada con 301. Por ejemplo, si erróneamente pedimos http://host/~user (olvidando la última barra), algunos servidores enviarán 301 y otros 302. Técnicamente, se supone que los navegadores siguen automáticamente la redirección su la petición original era GET. Puedes ver la cabecera 307 para más detalles.
303	See Other	Igual que 301/302, excepto que si la petición original era POST, el documento redirigido (dado en la cabecera Location) debería ser recuperado mediante GET. (Nuevo en HTTP 1.1)
304	Not Modified	El cliente tiene un documento en el caché y realiza una petición condicional (normalmente suministrando una cabecera If-Modified-Since indicando que sólo quiere documentos más nuevos que la fecha especificada). El servidor quiere decirle al cliente que el viejo documento del caché todavía está en uso.
305	Use Proxy	El documento pedido debería recuperarse mediante el proxy listado en la cabecera Location. (Nuevo en HTTP 1.1)
307	Temporary Redirect	Es idéntica a 302 ("Found" o "Temporarily Moved"). Fue añádido a HTTP 1.1 ya que muchos navegadores siguen erróneamente la redirección de una respuesta 302 incluso si el mensaje original fue un POST, y sólo se debe seguir la redirección de una petición POST en respuestas 303. Esta respuesta es algo ambígua: sigue el redireccionamiento para peticiones GET y POST en el caso de respuestas 303, y en el caso de respuesta 307 sólo sigue la redirección de peticiones GET. Nota: por alguna razón no existe una constante en HttpServletResponse que corresponda con este código de estado. (Nuevo en HTTP 1.1)
400	Bad Request	Mala Síntaxis de la petición.
401	Unauthorized	El cliente intenta acceder a una página protegida por password sin las autorización apropiada. La respuesta debería incluir una cabecera WWW-Authenticate que el navegador debería usar para mostrar la caja de diálogo usuario/password, que viene de vuelta con la cabecera Authorization.
403	Forbidden	El recurso no está disponible, si importar la autorización. Normalmente indica la falta permisos de fichero o directorios en el servidor.
404	Not Found	No se pudo encontrar el recurso en esa dirección. Esta la respuesta estándard "no such page". Es tan cómún y útil esta respuesta que hay un método especial para ella en HttpServletResponse: sendError(message). La ventaja de sendError sobre setStatus es que, con sendErr, el servidor genera automáticamente una página que muestra un mensaje de error.
405	Method Not Allowed	El método de la petición (GET, POST, HEAD, DELETE, PUT, TRACE, etc.) no estaba permitido para este recurso particular. (Nuevo en HTTP 1.1)
406	Not Acceptable	El recurso indicado genera un tipo MIME incompatible con el especificado por el cliente mediante su cabecera Accept. (Nuevo en HTTP 1.1)
407	Proxy Authentication Required	Similar a 401, pero el servidor proxy debería devolver una cabecera Proxy-Authenticate. (Nuevo en HTTP 1.1)
408	Request Timeout	El cliente tarda demasiado en envíar la petición. (Nuevo en HTTP 1.1)
409	Conflict	Usualmente asociado con peticiones PUT; usado para situaciones como la carga de una versión incorrecta de un fichero. (Nuevo en HTTP 1.1)
410	Gone	El documento se ha ido; no se conoce la dirección de reenvio. Difiere de la 404 en que se sabe que el documento se ha ido permanentemente, no sólo está indisponible por alguna razón desconocida como con 404. (Nuevo en HTTP 1.1)
411	Length Required	El servidor no puede procesar la petición a menos que el cliente envíe una cabecera Content-Length. (Nuevo en HTTP 1.1)
412	Precondition Failed	Alguna condición prévia especificada en la petición era falsa (Nuevo en HTTP 1.1)
413	Request Entity Too Large	El documento pedido es mayor que lo que el servidor quiere manejar ahora. Si el servidor cree que puede manejarlo más tarde, debería incluir una cabecera Retry-After. (Nuevo en HTTP 1.1)
414	Request URI Too Long	La URI es demsiado larga. (Nuevo en HTTP 1.1)
415	Unsupported Media Type	La petición está en un formato desconocido. (Nuevo en HTTP 1.1)
416	Requested Range Not Satisfiable	El cliente incluyó una cabecera Range no satisfactoria en la petición. (Nuevo en HTTP 1.1)
417	Expectation Failed	No se puede conseguir el valor de la cabecera Expect. (Nuevo en HTTP 1.1)
500	Internal Server Error	Mensaje genérico "server is confused". Normalmente es el resultado de programas CGI o servlets que se quedan colgados o retornan cabeceras mal formateadas.
501	Not Implemented	El servidor no soporta la funcionalidad de rellenar peticiones. Usado, por ejemplo, cuando el cliente envía comandos como PUT que el cliente no soporta.
502	Bad Gateway	Usado por servidores que actúan como proxies o gateways; indica que el servidor inicial obtuvo una mala respuesta desde el servidor remoto.
503	Service Unavailable	El servidor no puede responder debido a mentenimiento o sobrecarga. Por ejemplo, un servlet podría devolver esta cabecera si algún almacen de threads o de conexiones con bases de datos están llenos. El servidor puede suministrar una cabecera Retry-After.
504	Gateway Timeout	Usado por servidores que actúan como proxies o gateways; indica que el servidor inicial no obtuvo una respuesta a tiempo del servidor remoto. (Nuevo en HTTP 1.1)
505	HTTP Version Not Supported	El servidor no soporta la versión de HTTP indicada en la línea de petición. (Nuevo en HTTP 1.1)

Manejo de Excepciones en Java - Eclipse.

Un tema relevante en la programación, es el manejo y monitoreo de excepciones, por suerte en el lenguaje Java existe muchas alternativas que nos proveen la facilidad de controlar este tema facilmente.

En este url existe mas información del tema.

Resumiendo:

Excepciones Predefinidas
Las excepciones predefinidas por la implementación actual del lenguaje Java y su jerarquía interna de clases son las que se representan en el esquema de la figura que aparece a continuación:

Los nombres de las excepciones indican la condición de error que representan. Las siguientes son las excepciones predefinidas más frecuentes que se pueden encontrar:
ArithmeticException
Las excepciones aritméticas son típicamente el resultado de división por 0:

int i = 12 / 0;

NullPointerException
Se produce cuando se intenta acceder a una variable o método antes de ser definido:

class Hola extends Applet {
    Image img;

    paint( Graphics g ) {
        g.drawImage( img,25,25,this );
        }
    }

IncompatibleClassChangeException
El intento de cambiar una clase afectada por referencias en otros objetos, específicamente cuando esos objetos todavía no han sido recompilados.
ClassCastException
El intento de convertir un objeto a otra clase que no es válida.

y = (Prueba)x;      // donde x no es de tipo Prueba

NegativeArraySizeException
Puede ocurrir si hay un error aritmético al cambiar el tamaño de un array.
OutOfMemoryException
¡No debería producirse nunca! El intento de crear un objeto con el operador new ha fallado por falta de memoria. Y siempre tendría que haber memoria suficiente porque el garbage collector se encarga de proporcionarla al ir liberando objetos que no se usan y devolviendo memoria al sistema.
NoClassDefFoundException
Se referenció una clase que el sistema es incapaz de encontrar.
ArrayIndexOutOfBoundsException <
Es la excepción que más frecuentemente se produce. Se genera al intentar acceder a un elemento de un array más allá de los límites definidos inicialmente para ese array.
UnsatisfiedLinkException
Se hizo el intento de acceder a un método nativo que no existe. Aquí no existe un método a.kk()

class A {
    native void kk();
    }

y se llama a a.kk(), cuando debería llamar a A.kk().
InternalException
Este error se reserva para eventos que no deberían ocurrir. Por definición, el usuario nunca debería ver este error y esta excepción no debería lanzarse.
El compilador Java obliga al programador a proporcionar el código de manejo o control de algunas de las excepciones predefinidas por el lenguaje. Por ejemplo, el siguiente programa java902.java, no compilará porque no se captura la excepción InterruptedException que puede lanzar el método sleep().

import java.lang.Thread;

class java902 {
    public static void main( String args[] ) {
        java902 obj = new java902();
        obj.miMetodo();
        }
  
    void miMetodo() {
        // Aqui se produce el error de compilacion, porque no se esta
        // declarando la excepcion que genera este metodo
        Thread.currentThread().sleep( 1000 ); // currentThread() genera
                                              // una excepcion
        }
    }

Este es un programa muy simple, que al intentar compilar, producirá el siguiente error de compilación que se visualizará en la pantalla tal como se reproduce a continuación:

% javac java902.java
java902.java:41: Exception java.lang.InterruptedException must be caught,
or it must be declared in the throws clause of this method.
    Thread.currentThread().sleep( 1000 ); // currentThread() genera
                                ^

Como no se ha previsto la captura de la excepción, el programa no compila. El error identifica la llamada al método sleep() como origen del problema. Así que, la siguiente versión del programa, java903.java, soluciona el problema generado por esta llamada.

import java.lang.Thread;

class java903 {
    public static void main( String args[] ) {
        // Se instancia un objeto 
        java903 obj = new java903();
        // Se crea la secuencia try/catch que llamara al metodo que
        // lanza la excepcion
        try { 
            // Llamada al metodo que genera la excepcion
            obj.miMetodo();
            }catch(InterruptedException e){} // Procesa la excepcion
        }
  
    // Este es el metodo que va a lanzar la excepcion
    void miMetodo() throws InterruptedException {
        Thread.currentThread().sleep( 1000 ); // currentThread() genera
                                              // una excepcion
        }
    }

Lo único que se ha hecho es indicar al compilador que el método miMetodo() puede lanzar excepciones de tipo InterruptedException. Con ello conseguimos propagar las excepción que genera el método sleep() al nivel siguiente de la jerarquía de clases. Es decir, en realidad no se resuelve el problema sino que se está pasando a otro método para que lo resuelva él.
En el método main() se proporciona la estructura que resuelve el problema de compilación, aunque no haga nada, por el momento. Esta estructura consta de un bloque try y un bloque catch, que se puede interpretar como que intentará ejecutar el código del bloque try y si hubiese una nueva excepción del tipo que indica el bloque catch, se ejecutaría el código de este bloque, si ejecutar nada del try.
La transferencia de control al bloque catch no es una llamada a un método, es una transferencia incondicional, es decir, no hay un retorno de un bloque catch.
Crear Excepciones Propias
También el programador puede lanzar sus propias excepciones, extendiendo la clase System.exception. Por ejemplo, considérese un programa cliente/servidor. El código cliente se intenta conectar al servidor, y durante 5 segundos se espera a que conteste el servidor. Si el servidor no responde, el servidor lanzaría la excepción de time-out:

class ServerTimeOutException extends Exception {}

public void conectame( String nombreServidor ) throws Exception {
    int exito;
    int puerto = 80;

    exito = open( nombreServidor,puerto );
    if( exito == -1 )
        throw ServerTimeOutException;
    }

Si se quieren capturar las propias excepciones, se deberá utilizar la sentencia try:

public void encuentraServidor() {
   ...
   try {
        conectame( servidorDefecto );
        catch( ServerTimeOutException e ) {
            g.drawString( 
                "Time-out del Servidor, intentando alternativa",5,5 );
            conectame( servidorAlterno );
            }
    ...
    }

Cualquier método que lance una excepción también debe capturarla, o declararla como parte del interfaz del método. Cabe preguntarse entonces, el porqué de lanzar una excepción si hay que capturarla en el mismo método. La respuesta es que las excepciones no simplifican el trabajo del control de errores. Tienen la ventaja de que se puede tener muy localizado el control de errores y no hay que controlar millones de valores de retorno, pero no van más allá.
Y todavía se puede plantear una pregunta más, al respecto de cuándo crear excepciones propias y no utilizar las múltiples que ya proporciona Java. Como guía, se pueden plantear las siguientes cuestiones, y si la respuesta es afirmativa, lo más adecuado será implementar una clase Exception nueva y, en caso contrario, utilizar una del sistema.

• ¿Se necesita un tipo de excepción no representado en las que proporciona el entorno de desarrollo Java?
• ¿Ayudaría a los usuarios si pudiesen diferenciar las excepciones propias de las que lanzan las clases de otros desarrolladores?
• ¿Si se lanzan las excepciones propias, los usuarios tendrán acceso a esas excepciones?
• ¿El package propio debe ser independiente y auto-contenido?

Genexus y ACTIVEMQ

Uno de los temas mas importante para el proceso de interoperabilidad se centra en tener a mano herramientas que nos ayuden a realizar esta tarea de la mejor forma posible.

ACTIVEMQ es una herramienta que focaliza el manejo de colas de mensajes, este concepto es muy antiguo los predecesores al sistema ISeries de IBM, como el S34 y el S38, fueron practicamente alla por la decada de los 80 que impulsaron mucho la forma de manejo de procesos.

En virtud de ello es importante recalcar que las soluciones informaticas deberian focalizar su desarrollo hacia la utilización de estas herramientas OpenSource.

A continuación algunos sitios blogs donde se toca el tema en muchos de los casos con ejemplos practicas y otros utilizan un tema conceptual.

01.- Consultor de Java y el ACTIVEMQ
02.- JBoss y ActiveMq
03.- Integrando Genexus y ActiveMq
04.- Conceptos de ACTIVEMQ
05.- Fundamentos de ACTIVEMQ (Ingles)
06.- Instalacion y Utilización de ACTIVEMQ (Ingles)
07.- Instalacion y Ejemplos de ACTIVEMQ - Adictos al trabajo
08.-ActiveMq sus vision general
09.- Que es ACTIVEMQ sus ventajas
10.- Información Adicional de ACTIVEMQ
11.- Integración de ACTIVEMQ y SPRING
12.- Instalacion de ACTIVEMQ
13.- Utilización de ActiveMQ - ejemplos
14.- Un BLOG de Java con mucha información de Herramientas OpenSource.
15.- Introduccion a ACTIVEMQ - Adictos al trabajo

Servicio Web - RESTful en java utilizando Eclipse Luna

Extensiones de Eclipse que necesitaremos son las requeridas:








De no existir alguna de ellas procedemos a instalar de la siguiente forma:



Tomado de: Generando Servicios Web REST-Full con Eclipse