Bug 1059836

Summary: [GSS] (6.3.0) Remote Naming communication exception should be thrown on ConnectException
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Brad Maxwell <bmaxwell>
Component: NamingAssignee: Brad Maxwell <bmaxwell>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.2.0CC: jmartisk, rsvoboda, smumford
Target Milestone: DR1   
Target Release: EAP 6.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
In previous versions of JBoss EAP, a generic `javax.naming.NamingException` was being thrown when a `java.net.ConnectException` occurred instead of the more specific `javax.naming.CommunicationException`. This release includes a change that ensures a `javax.naming.CommunicationException` is thrown when a connection exception occurs. `CommunicationException` is a subclass of `NamingException`, so any code that previously caught a `NamingException` will still work as expected.
Story Points: ---
Clone Of:
: 1059837 (view as bug list) Environment:
Last Closed: 2014-06-28 15:42:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1024153, 1059837    

Description Brad Maxwell 2014-01-30 19:09:06 UTC
Use right exception type for communication problem , javax.naming.CommunicationException should be thrown instead of javax.naming.NamingException

Comment 1 JBoss JIRA Server 2014-01-30 20:04:26 UTC
Brad Maxwell <bmaxwell@redhat.com> updated the status of jira WFLY-2839 to Resolved

Comment 2 Rostislav Svoboda 2014-02-04 11:30:22 UTC
http://docs.oracle.com/javase/7/docs/api/javax/naming/CommunicationException.html

Customers apps (try - catch blocks) won't be affected by throwing CommunicationException instead of NamingException

Comment 3 Brad Maxwell 2014-02-04 17:23:54 UTC
Yes, originally it was a generic NamingException, this change just uses sub classes of NamingException which are more specific, so any customer who was catching the NamingException will not be affected, they will still be caught, they will just provide information about the real issue.

Comment 5 Jan Martiska 2014-04-09 12:58:32 UTC
Verified with EAP 6.3.0.ER1 / jboss-remote-naming 1.0.8.Final-redhat-1