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: | Naming | Assignee: | Brad Maxwell <bmaxwell> | |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | ||
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 6.2.0 | CC: | 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: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1024153, 1059837 | |||
|
Description
Brad Maxwell
2014-01-30 19:09:06 UTC
Brad Maxwell <bmaxwell> updated the status of jira WFLY-2839 to Resolved 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 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. Verified with EAP 6.3.0.ER1 / jboss-remote-naming 1.0.8.Final-redhat-1 |