The JnlpAgentReceiver API contract is too heavily tied to the NioChannelHub abstraction (which is fundamentally incompatible with SSLEngine)
As such for JNLP4-connect a.k.a. JENKINS-36871 I basically have to rip it out. Now this should not be *too* big a deal as there is only one Open Source implementation of JnlpAgentReceiver - the one in Jenkins core - and I know of one other closed source implementation (but that's a CloudBees one so I can fix that) So I am calling for to see if there are other implementations. If there are other implementations then I will see if there is a way to maintain binary compatibility with those implementations (unlikely, but I can try again... I may be able to get it if there are some methods I can throw out on JnlpServerHandshake... though I should note that JNLP3-connect broke the API binary compatibility as well as the API contract, so it is actually highly unlikely that anyone has a working implementation) If you have or know of an additional implementation, please contact me ASAP, otherwise I will be removing the code to replace with a nicer API that does not make as many assumptions about the I/O and how that should be wired up. -Stephen P.S. it will probably be end of this week before I start to consider merging -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMz0ReO3gJvWdokcHOMU8-UrKujpczUDbE9bgJCMg%3D%2BKAA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
