[
https://jira.jboss.org/jira/browse/JBESB-2493?page=com.atlassian.jira.plu...
]
Kevin Conner commented on JBESB-2493:
-------------------------------------
So the issue here is that the *caller* of this is swallowing the naming exception.
That code makes a second attempt to retrieve the JNDI context/factory connections and any
permanent errors will result in an exception being thrown from the attempt within the
catch.
In this case that would be ServiceInvoker which is at fault.
In fact, the SI code which logs the debug is not even checking to see whether debug is
enabled or not.
JmsConnectionPool swallows NamingException
------------------------------------------
Key: JBESB-2493
URL:
https://jira.jboss.org/jira/browse/JBESB-2493
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.4 CP2
Reporter: Jiri Pechanec
Assignee: Kevin Conner
See the following code
try
{
factoryConnection = jndiContext.lookup(connectionFactoryString);
} catch (NamingException ne) {
logger.info("Received NamingException, refreshing
context.");
jndiContext = NamingContextPool.replaceNamingContext(jndiContext,
JmsConnectionPoolContainer.getJndiEnvironment(poolKey));
factoryConnection = jndiContext.lookup(connectionFactoryString);
}
If the exception is thrown it is not logged and there is no way to identify the reason of
error
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira