This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
In 6.9 CND introduced ssh public-key as a choice for remote authentication. SunStudio (glue) needs to track this as well, otherwise a user may choose this method of authentication and then be surprised when they are prompted for a password when they start to debug using dbx or enable ss_attach. The choice of authentication is stored in class Authentication and I should be able to utilize that information and pass it on to glue. Unfortunately class Authentication is not in an exported package. NOTE ... earlier we had talked about CND giving me a jsch session. That never made much sense to me, not to mention that it "leaks" jsch API's. class Authentication seems to have all the information I need.
What are the other usecases if such class is available in public part of API? If it can be used only for creation of external ssh sessions in other module? => it's hidden leak of jsch api through public interface of module anyway. + ssh has restrictions about number of sessions and channels per session which is preferable to be handled in one place. I do not agree to expose Authentication.
to #1: "it's hidden leak of jsch api" - no, it is not, as Authentication doesn't expose any jsch-specific stuff. This is all ssh-related things (not about specific implementation of the protocol). So, from the one hand it is only about providing info related to selected way of authentication (in case of ssh)... From the other hand, I would agree that we should try to find more generic way for this..
(In reply to comment #1) > What are the other usecases if such class is available in public part of API? Authentication is just another property of a host. Properties like ssh port, whether a password is remembered, pathmappings, toolchains etc. So I'm going to turn the question around. Why should _any_ property be hidden? Even passwords are available via PasswordManager. (In reply to comment #2) > From the other hand, I would agree that we should try to find more generic way > for this.. I don't know about generic, but it seems straightforward to me. You have a hosts database with hosts that have properties. This is all a logical design and each property has it's place. I've been able to put all these properties to good use so far. Authentiation seems to be an exception (?) If by "generic" you mean "hide the fact that ssh is used" I'd say that's not a good approach. ssh is complicated enough that hiding the fact that ssh is being used will just confuse users when things stop working.