So these properties look to be essentially aliases for the standard jsse properties, plus a socket timeout notion. The main thing we have to address is externalizing all keystore, socket configuration information from the socket factory to allow for alternate ways to configure the socket factory instance.
This has to be outside of the javax.net.SocketFactory api. There are related classes in the common module under the org.jboss.util.net package. That should be the core java bean based impl with Properties, and SecurityDomain based subclasses outside of this dealing with how to populate the common java bean based impl with the necessary components (keystore, truststore, socket options, ...)
Have finished initial go at the implementation. Is checked into remoting project for now (http://viewcvs.labs.jboss.com/cgi-bin/viewcvs.cgi/JBossRemoting/src/main/org/jboss/remoting/util/socket/RemotingSSLSocketFactory.java)
There are still a few more configuration hooks that could be added (like setting the ciphers to be used, etc.), but think these will be fairly easy to add now. The basics are all there though (store path, password, type, alorigthm, etc.). Guess for anything that is *not* there that should be, needs to be entered as a jira issue and assigned to me (otherwise will loose them).
Now is the issue of where the permanent home for this should be. Originally I thought it should be in JBossAS common, but now think should be within remoting. The main reason is for versioning. Since remoting will need this class, will be an issue of getting a jboss-common.jar in released form to include in remoting. However, if lives in JBossAS 4.0 branch and HEAD, and they get out of sync, remoting will be hosed. Also, if put this into JBossAS 4.0 branch, and want to include in JBoss Remoting 1.4.1, how do I include a jboss-common.jar from JBossAS 4.0 branch and yet still use the JBoss Remoting 1.4.1 in JBossAS 4.0.4 (without first using a dev build of jboss-common.jar for remoting release)?
Makes perfect sense to have it in the remoting project, unless Scott thinks otherwise.
the common module is in the process of being broken up so its not going to be part of the jbossas in the future. The RemotingSSLSocketFactory still needs some work to be general enough as its always loading the KeyStore, KeyManager, TrustManager, etc from the classpath/filesystem. These should be injectable resources. For now I would leave the RemotingSSLSocketFactory in remoting think about a common implementation once the common module is broken out.