Se obtenia la excepcion de JMS 2005 la cual no nos daba mucha información al descompilar el codigo se vio que la excepcion era manejeada de la siguiente forma:
try
{
props = new Hashtable();
props.put("java.naming.provider.url", Messages.getString("PROVIDER_URL"));
props.put("java.naming.factory.initial", "com.ibm.websphere.naming.WsnInitialContextFactory");
context = new InitialContext(props);
..
props.put("java.naming.provider.url", Messages.getString("PROVIDER_URL"));
props.put("java.naming.factory.initial", "com.ibm.websphere.naming.WsnInitialContextFactory");
context = new InitialContext(props);
..
}
catch(Exception e)
{
Log.fatal("[Servicio]Error al inicializar servicio:", e);
System.exit(-1);
}
Ese catch de exception hummmm.. no me gusta mucho.
Lo que necesitamos para poder solucionar el problema no es la excepcion generica de jms sino la excepcion propia del provider (mq en este caso) pero como la obtenemos ?
Pues simplemente cambiemos el bloque catch a la siguiente forma:
catch(JMSException e)
{
Log.fatal("[Servicio][run]Error JMSException: " + e.getLinkedException());
e.printStackTrace();
Log.fatal("[Servicio][run]Error" + e.getMessage());
}
Gracias al getLinkedException podemos ver las excepcion lanzada por el provider y ver el verdadero rostro de la excepción.
1 comentario:
Buen dato, chicho. Felicitaciones por tu blog!
Publicar un comentario