Hi Oleg, > I may not have fully grasped the concept but I felt the proposed > solution would not work well with NIO where the process of establishing > a connection was non-blocking.
I'm not sure how that works. The connection factory in your previous patch would also return a connection object, right? > And yes, it is kinda complex ;-) Sorry, I couldn't think of an easier way :-) > So, my > intention was to remove all methods from HttpClientConnection interface > that have to do with connection initialization, provide a simple > mechanism to bind the default HttpClientConnection impl to an arbitrary > socket and then deal with HTTPCORE-8 The idea of the patch in HTTPCORE-8 was to keep all connection init methods in the connection interface, but route them to the operator which gets exclusive internal access to the container object. I was really just trying to refactor the code for opening and closing sockets out of the connection. > But the operator is nonetheless exposed through the HttpClientConnection > interface, right? It is exposed as getter and setter, yes. But there are currently no methods in the operator that could be called directly. The getter/setter is intended mainly to change the operator while the connection is closed. And of course to initialize the container object after creation. I think Spring relies on getters and setters? ;-) > So, every HTTP client connection would have to > implement it even though not every kind of connection is capable of > "re-opening" itself? It is only _suggested_ that reopening _tries_ to re-use the socket. It is perfectly acceptable that the operator simply closes the socket and creates a new one in response to the re-open call. That much should be supported by every container for a socket :-) Connections don't implement an operator, they are provided with one. It's supposed to be a mix-and-match relation between the two, unless somebody implements an operator that needs additional attributes in the connection. That operator would need to provide an extended connection implementation. Still, I don't know what implications that has regarding NIO. Maybe you can write a paragraph or two how a connection will be openend asynchronously, and how that will be synchronized with the operation of the application thread? cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
