On Wed, 2016-10-19 at 10:14 -0400, Pellerin, Clement wrote: > I agree with you this feature is strange and need not be added to the library. > As I said before, I need to preserve this feature for backwards compatibility. > It has something to do with delaying the emission of an MDN in an AS2 gateway > so it represents the status of the receiver instead of the man in the middle. > Again, please don't ask me to change the architecture of the solution. > We don't own the application and we can't change it. Nevertheless it must > continue to work after we port to HttpClient 4.5.2 > > As for the work-around, I have something working but it duplicates too much > code for my taste. I think this is a nice opportunity for HttpClient > to learn what it is like to try to subclass its engine. > > I am subclassing HttpClientBuilder to override createMainExec() > to return my own implementation of the ClientExecChain. > This is nice. > > Unfortunately, our subclass of ClientExecChain must be in the > org.apache.http.impl.execchain package because support classes > in that package are all package private. This is annoying. > > I modified the problematic code in ClientExecChain.execute() > but that was not enough. I need to trap the EofSensorWatcher > of the response HttpEntity. That requires duplicating > HttpResponseProxy and ResponseEntityProxy. > Again this must be done in the apache package. > > The release should go through the ConnectionHolder since that's > where the "AtomicBoolean released" field is stored. > I thought of providing my own implementation of ConnectionHolder > with an empty releaseConnection() method, but that does not work > when ResponseEntityProxy calls cleanup(), this becomes > releaseConnection(false) which closes the connection completely. >
Those classes are package private so we would not keep them API compatible between minor releases. I intend to re-evaluate the execution pipeline code in 5.0 and attempt to provide a public API based on the chain of responsibility pattern. > I would appreciate if you have better suggestions for the work-around. > It would be nice to make subclassing easier too. > > By the way, should ResponseEntityProxy.enchance() > be called enhance() instead? > Compare this to RequestEntityProxy.enhance() > Yes, it should be. Please fork HttpClient on Github and raise a PR with changes you are proposing. We can add methods to MainClientExec as long as they remain package private. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
