[jira] Updated: (QPID-1506) Auto Negotiate connections for JMX Management Console

["Robert Gemmell (JIRA)" <qp...@incubator.apache.org>]

     [ https://issues.apache.org/jira/browse/QPID-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Gemmell updated QPID-1506:
---------------------------------

    Attachment: QPID-1506_11dec2008.patch

I have created a patch (QPID-1506_11dec2008.patch) that allows the console to automatically determine which type of connection it needs. It does so by attempting an RMI based connection and monitoring for an IOException indicating a there is no RMI-JRMP server at the remote end (as mentioned in QPID-1504), then attempting to establish a JMXMP connection instead. At this stage it uses any IOExceptions to determine the correct SASL profile to use.

> Auto Negotiate connections for JMX Management Console
> -----------------------------------------------------
>
>                 Key: QPID-1506
>                 URL: https://issues.apache.org/jira/browse/QPID-1506
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Management : JMX Console
>    Affects Versions: M3, M4
>            Reporter: Martin Ritchie
>         Attachments: QPID-1506_11dec2008.patch
>
>
> Summary:
> Currently there are number of options that must be configured for the JMX Console to correctly connect, if these values are not set or correct then the connection will fail.
> However, the broker will provide the console with sufficient detail to auto-negotiate the connection.
> QPID-1504 highlights that if we connect using the RMI connector but the server is configured for JMXMP then we can tell.
> If we connect using JMXMP using SASL/CRAM-MD5 but the server wants SASL/PLAIN  then we can tell as the exception is:
>     java.io.IOException: The server supported profiles [SASL/PLAIN] do not match the client required profiles [SASL/CRAM-MD5].
> We can use this information to swap Sasl mechanism in the console and try again.
> This would mean that the end user would not have to reconfigure or have multiple start scripts lying about so they could connect to a number of difference brokers using different mechanisms.
> Looking at the private class ConnectorThread in JMXServerRegistry along with the createSASLConnector  and the constructor show that the security mechanism is hard coded but could using the above method be derived from the broker's response and handled appropriately if the ConnectorThread and createSASLConnector where better architected to take advantaged of the exceptions returned from the JMXConnectorFactory.connect method

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.