0 Replies Latest reply on May 16, 2006 1:54 AM by tom.elrod

    remoting configuration semantics

      Currently the rules for configuration the Client and Connector is fairly loose. The problem is that the projects is getting too big to not have better constraints on when/where configurations can be set. Therefore, would like to break out configuration into two categories; connection and conversation.

      The connection configuration settings would be directly related to setting up the connection between the client and the server. These would all need to be set before and actual connection is established (before connect() is called on the Client and create() is called on the Connector). For example, setServerSocketFactory() would need to be called *before* the create() method is called on the Connector (otherwise will get an exception thrown).

      Since the Client and the Connector delegate much of their work to the transport layer (represented by the client/server invokers), configuration involving these can not be done until after the invokers have been created (which occurs as part of the Client.connect() and Connector.create() call). These types of configurations would be considered conversation configurations. For example, adding a callback listener or a server invoker handler can not occur until after Client.connect() or Connector.create() is called. If these are called before in the conversation state, an exception will be thrown.

      Please provide any feedback you may have on this view for configuration as would like to document all configuration as being wither connection or conversation so will be easy to identify at what point in the life cycle they should be set.