Hi, Agreed. We should have the deprecation conversation in a separate thread. No rush.
Here is a gist[1] of what is being proposed. It has had some input already from Carsten and Robert. On reflection we changed the signature of the provider to pass in an implementation of a class (RedirectResponse). I also changed that from an interface to a class to be extended by implementations, so that when new methods are added to the RedirectResponse in the future, no past implementation has to change. If it was an interface, then all past implementations on the caller side would have to change to avoid class cast issues. Best Regards Ian 1 https://gist.github.com/ieb/5f217e2c160afb7bb4098bca99896621 On Thu, 30 Jan 2020 at 14:17, Carsten Ziegeler <cziege...@apache.org> wrote: > We need a way for a resource provider to provide this object based on a > resource. And adaptTo is exactly the mechanism for this. As this > adaption is implemented by a provider, there is no startup ordering > problem etc as some experience with more custom adaptions. > So in this case, on the same resource a call to adaptTo will most likely > always give the same result, either null or the object. > Sounds perfectly valid to me. > > Carsten > > On 30.01.2020 00:52, Radu Cotescu wrote: > > Could we, at least for new APIs, stop using adaptTo? (I started running > away from any physical location known by Sling committers) > > > >> On 29 Jan 2020, at 21:40, Carsten Ziegeler <cziege...@apache.org> > wrote: > >> > >> A resource might be adaptable to RedirectProvider. > > > > > > -- > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
