https://bz.apache.org/bugzilla/show_bug.cgi?id=60597
--- Comment #6 from Christopher Schultz <ch...@christopherschultz.net> --- (In reply to Michael Orr from comment #5) > In general I'd much prefer the direct mutators approach as well. In this > case, however, the intent is to provide additional configuration > capabilities to the generic javax.websocket.* API classes that were missing > from that generic API. Understood. I think the system-property-based configuration is probably best, then. No need to build infrastructure only to remove it later when the public API improves. > Of course, the best thing would be if protocol/ciphers configurability were > to be added to the official java.websocket.* API spec, but I have no idea > when that's coming... After wrestling with several third-party APIs which didn't support various TLS configuration parameters, I've decided that the only sane way to accomplish it is to allow the caller to supply their own SSLSocketFactory. Otherwise, you end up re-inventing the wheel for everything: protocols, cipher suites, trust stores, key management, certificate revocation lists, hostname verifiers, certificate verifiers, etc. Apache HTTP Components (http-client) stepped on this landmine long ago and it took them several versions to climb out of the hole and remove all of the Apache-specific configuration in favor of the standard SSLSocketFactory. It didn't help that it took the Java API a while to standardize and expose that interface, too. Thanks for your patches! -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
