Bug 1014413

Summary:	Remote Naming throws the same exception for different causes
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Brad Maxwell <bmaxwell>
Component:	Naming	Assignee:	Brad Maxwell <bmaxwell>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	urgent
Version:	6.1.1	CC:	kkhan, mnovak
Target Milestone:	---
Target Release:	EAP 6.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-11-05 20:52:29 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:
Embargoed:

Description Brad Maxwell 2013-10-01 23:25:08 UTC

A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported.

We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception.

If all the the servers specified are not not running:
--------------------------------------------------------------------------------------------
javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)

If one of the servers is running, but the client's username/password are incorrect
--------------------------------------------------------------------------------------------
javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)

Comment 1 Brad Maxwell 2014-11-05 20:52:29 UTC

This was already resolved in EAP 6.3.0 and 6.2.2.

*** This bug has been marked as a duplicate of bug 1014414 ***