If we are still going to support the old style API because we still need it as an escape hatch to implement complex solutions, those APIs should not become deprecated IMO.
Gary On Tue, Nov 9, 2021, 14:01 Oleg Kalnichevski <[email protected]> wrote: > > > On 11/9/2021 10:07 AM, Michael Osipov wrote: > > Am 2021-11-08 um 17:52 schrieb Oleg Kalnichevski: > >> > >> > >> On 11/8/2021 5:03 PM, Michael Osipov wrote: > >>> Am 2021-11-08 um 16:56 schrieb Oleg Kalnichevski: > >>>> > >> > >> ... > >> > >>> I need to setup a small project next week. Give me a bit of time. > >>> The above won't work because DataHandler is > >>> javax.activation.DataHandler used with SOAP MTOM directly in the > >>> generated clients. I see no way to return that input stream with a > >>> closure because it contrdicts the closure concept. > >>> I don't know how familiar you are with JAX-WS and MTOM, but those > >>> DataHandlers are core concepts with are passed around with a readable > >>> source either as input or output. > >>> See also > >>> > https://docs.oracle.com/middleware/1212/wls/WSGET/jax-ws-mtom.htm#WSGET3485. > > >>> > >>> > >>> As of now, I am afraid that a closure will not be able to cover all > >>> possible usecases. > >>> > >>> Michael > >>> > >> > >> I must recant my previous statement. Not everything can be turned into > >> a closure without some (sometimes major) refactoring, and some APIs > >> are just given and cannot be refactored. > > > > Does this mean that deprecating it does not work out at the end and it > > has to remain as an alternative? > > Yes, it does. We will have to keep supporting CloseableHttpResponse. > > Oleg > > > > >> Still I want to put more emphasis on the usage of > >> HttpClientResponseHandler going forward and steer users toward using > >> it as closures in their application code. Starting with our sample > >> code and the migration guide. > > > > > > I agree that we should favorize the closure since it is less headache. > > > > M > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
