Bug 1059836 - [GSS] (6.3.0) Remote Naming communication exception should be thrown on ConnectException
Summary: [GSS] (6.3.0) Remote Naming communication exception should be thrown on Conne...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Naming
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: DR1
: EAP 6.3.0
Assignee: Brad Maxwell
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 1024153 1059837
TreeView+ depends on / blocked
 
Reported: 2014-01-30 19:09 UTC by Brad Maxwell
Modified: 2018-12-04 17:15 UTC (History)
3 users (show)

(edit)
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.
Clone Of:
: 1059837 (view as bug list)
(edit)
Last Closed: 2014-06-28 15:42:53 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker WFLY-2839 Major Closed Remote Naming communication exception should be thrown on ConnectException 2017-12-19 02:23 UTC

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


Note You need to log in before you can comment on or make changes to this bug.