[jbosstools-issues] [JBoss JIRA] (JBIDE-16133) No indication that management authentication fails

Max Rydahl Andersen (JIRA) jira-events at lists.jboss.org
Thu Nov 28 03:00:06 EST 2013


    [ https://issues.jboss.org/browse/JBIDE-16133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12927266#comment-12927266 ] 

Max Rydahl Andersen commented on JBIDE-16133:
---------------------------------------------

Okey, had a chat with Rob about the issue here. There are two issues in play here:
 
A) lack of credentials dialog when authentication fails
 
B) mysterious logging of JBREM000200 connection reset by peer.
 
 
For A Rob found that in the past (JBDS 5) we had a dialog *always* show up, no matter if credentials was good or bad
before executing a management operation. This was fixed in https://issues.jboss.org/browse/JBIDE-10298 (2 years ago) so
the operation now just executes the operation. If the client api wants to execute this operation again you would need to
execute this operation again.
 
This is actually no different from the past - after the forced shown credentials dialog, if you put in wrong credentials
and exception would be thrown and you would need to handle that on the calling side anyway.
 
You can use PollThreadUtils.requestCredentialsSynchronous(server, props) to show this dialog and have it stored in the
server.
 
In case showing the dialog is not possible I suggest you at least log an warning or error even to the eclipse log stating 
credentials were not correct for Server X and that it can be fixed in the server editor/settings.
 
Unfortunately this API around authentation is not very clean so you have to do things like checking the content of the
exception message as Rob describes further above.
 
I recommend we do not change this in this release stream now, but have that as goal for the update/rewrite of AS tools
in next major release (JBDS 8/JBT 4.3). Mind you, this is an issue that as far as we can see have been present for 2+
years.
 
For #A - Teiid designer should always have catched the exception and report accordingly.
 
For B, this is still a mystery. We haven't seen this yet when using base server tools and stock EAP 6 thus we are
wondering if there are some differences in the server libaries in DV and EAP that could explain this ? Or that there is
some missing cleanup/early disconnect that Teiids usage of the server tools api that causes this error.
 
We would need more details/help to track down #B.
                
> No indication that management authentication fails
> --------------------------------------------------
>
>                 Key: JBIDE-16133
>                 URL: https://issues.jboss.org/browse/JBIDE-16133
>             Project: Tools (JBoss Tools)
>          Issue Type: Quality Risk
>          Components: server
>            Reporter: Steven Hawkins
>            Assignee: Rob Stryker
>            Priority: Critical
>             Fix For: 4.1.1.CR1
>
>
> Running Developer Studio 7.1.0.CR1 and using either the server auto-detection or manually defining a server and using an incorrect management password results in a console log entry:
> 14:00:54,966 ERROR [org.jboss.remoting.remote.connection] (Remoting "..." read-1) JBREM000200: Remote connection failed: java.io.IOException: Connection reset by peer
> On server startup without any indication of what it means.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the jbosstools-issues mailing list