[jboss-jira] [JBoss JIRA] Commented: (JBREM-1014) Support injection of socket factory class name into AbstractInvoker

[ https://jira.jboss.org/jira/browse/JBREM-1014?page=com.atlassian.jira.plu... ] Ron Sigal commented on JBREM-1014: ---------------------------------- I think I see the underlying problem. Originally, *all* parameters were configured through the InvokerLocator, and then we added configuration maps. However, there's an anomaly in org.jboss.remoting.RemoteClientInvoker(), which passes both the InvokerLocator and configuration map to the AbstractInvoker constructor (which combines them to create a single configuration map), but it then calls AbstractInvoker.createSocketFactory() passing just the original configuration map, instead of the combined map. Changing RemoteClientInvoker() to use the combined map doesn't seem like a good idea in a minor release, but I've got a compromise. It looks for the parameter "socketFactoryClassName" in the InvokerLocator and adds it (if it exists) to the configuration map. This change shouldn't affect any existing code since "socketFactoryClassName" is a new parameter. Unit tests: * org.jboss.test.remoting.transport.bisocket.SocketFactoryClassNameTestCase * org.jboss.test.remoting.transport.http.SocketFactoryClassNameTestCase * org.jboss.test.remoting.transport.rmi.SocketFactoryClassNameTestCase * org.jboss.test.remoting.transport.socket.SocketFactoryClassNameTestCase * org.jboss.test.remoting.transport.bisocket.ssl.SSLSocketFactoryClassNameTestCase * org.jboss.test.remoting.transport.http.ssl.SSLSocketFactoryClassNameTestCase * org.jboss.test.remoting.transport.rmi.ssl.SSLSocketFactoryClassNameTestCase * org.jboss.test.remoting.transport.socket.ssl.SSLSocketFactoryClassNameTestCase -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira