I like this idea a lot. Not only does it resolve the keystore problem, but I like the thread pool consistency, I would love to be able to multiplex protocols over one socket, and I also think OpenEJB would benefit from this kind of network pluggability (though I am supposed to talk to David B to get a better understanding of the current OpenEJB network layer).
Aaron On Sat, 13 Aug 2005, Jeremy Boynes wrote: > Aaron's recent thread on SSL has made we wonder if we should consider > providing our own socket listeners for HTTP(S) and other protocols > rather than using the ones supplied by the containers we are embedding. > > Reasons for doing it include: > * ability to integrate with custom work managers (thread pools) and > SSL infrastructure > * consistency across all embedded containers > * potential for multi-protocol support on one end-point > (i.e. multiplexing everything over one port like WebLogic does which > can make life easier when firewalls are involved) > * potential for integrating with custom QoS frameworks e.g. allowing > custom negotiation with load-balancers in a clustered environment > * potential for hi-av version upgrades where we can version in a > upgraded component and hand off the physical socket resulting in > no loss of availability > > Note that none of those features are HTTP specific. > > The downside of course is that it may weaken integration between the > listener and the container being embedded; for some containers they may > be so closely coupled that doing this will actually make things > difficult. For example, I think doing this would be fairly easy for > Jetty, I don't know how easy it would be for Tomcat, OpenEJB, JMX, > ActiveMQ etc. > > -- > Jeremy >
