Re: Redirect Provider

Hi, After discussing internally I have updated the patch to use and interface, that hopefully will unblock the -1. The PR and issue has been reopened. Best Regards Ian On Fri, 14 Feb 2020 at 15:06, Ian Boston wrote: > Hi, > The API PR attracted a -1 which I understand and respect. > > I cant see

Re: Redirect Provider

Hi, The API PR attracted a -1 which I understand and respect. I cant see of a way or revolving the -1 without making the API unsupportable long term, hence I have closed the PRs and closed SLING-9060 as a Wont fix and will look for alternative ways of solving the problem. Best Regards Ian On Mon,

Re: Redirect Provider

> Let me know whether that is enough or it needs expansions. +1, works. Interestingly it did need all occurrences of bundles pointing to SNAPSHOT Sling API bundles to be updated, and for those bundles to depend on the latest snapshot of the API. scripting.core and servlets.resolver had to be fixe

Re: Redirect Provider

Hi Ian, On Sat, 2020-02-08 at 09:48 +, Ian Boston wrote: > Hi, > The PRs have been opened, see the issue. > I will do complete implementations to verify it works as required in > AEM. > I would also like to insure no disruption to Sling, and since it's > been a > long time since I did this, ho

Re: Redirect Provider

Hi, The PRs have been opened, see the issue. I will do complete implementations to verify it works as required in AEM. I would also like to insure no disruption to Sling, and since it's been a long time since I did this, how do run full CI/CD and integrate a new API in Sling ? (a pointer would be g

Re: Redirect Provider

Hi, Opened [1] to track the work. Best Regards Ian 1 https://issues.apache.org/jira/browse/SLING-9060 On Wed, 5 Feb 2020 at 22:12, Ian Boston wrote: > Hi, > Ok. > > o.a.s.api.redirect for the API, and a patch to the Get servlet to use the > API. > Will do PRs shortly. > > Best Regards > Ian > >

Re: Redirect Provider

Hi, Ok. o.a.s.api.redirect for the API, and a patch to the Get servlet to use the API. Will do PRs shortly. Best Regards Ian On Tue, 4 Feb 2020 at 14:13, Bertrand Delacretaz wrote: > On Tue, Feb 4, 2020 at 1:58 PM Ian Boston wrote: > > ...New package, agreed, no ripples. > > o.a.s.api.respon

Re: Redirect Provider

On Tue, Feb 4, 2020 at 1:58 PM Ian Boston wrote: > ...New package, agreed, no ripples. > o.a.s.api.response ? ... o.a.s.api.redirect is more specific and I think having packages with few interfaces is fine? The existing api.auth and api.security packages for example only have 3 items each. It h

Re: Redirect Provider

Hi, New package, agreed, no ripples. o.a.s.api.response ? request & resource already exist, but no response. Best Regards Ian On Tue, 4 Feb 2020 at 10:14, Bertrand Delacretaz wrote: > On Tue, Feb 4, 2020 at 9:54 AM Radu Cotescu wrote: > > ...After Carsten’s detailed reasoning I guess it mak

Re: Redirect Provider

On Tue, 2020-02-04 at 10:14 +0100, Bertrand Delacretaz wrote: > On Tue, Feb 4, 2020 at 9:54 AM Radu Cotescu wrote: > > ...After Carsten’s detailed reasoning I guess it makes the most > > sense to put this new > > API in o.a.s.api, where the Resource and ResourceProvider APIs are > > also defined..

Re: Redirect Provider

On Tue, Feb 4, 2020 at 9:54 AM Radu Cotescu wrote: > ...After Carsten’s detailed reasoning I guess it makes the most sense to put > this new > API in o.a.s.api, where the Resource and ResourceProvider APIs are also > defined... But ideally in a new package? To avoid bumping up versions of exist

Re: Redirect Provider

Hi Ian, > On 4 Feb 2020, at 09:24, Ian Boston wrote: > > Hi, > Which bundle/package should the API be in ? > Sling API ? > Best Regards > Ian > After Carsten’s detailed reasoning I guess it makes the most sense to put this new API in o.a.s.api, where the Resource and ResourceProvider APIs are

Re: Redirect Provider

Hi, Which bundle/package should the API be in ? Sling API ? Best Regards Ian On Fri, 31 Jan 2020 at 17:50, Carsten Ziegeler wrote: > A general service does imho not sense. That service has no knowledge > about where resources are coming from and how binaries a stored. > A resource provider does

Re: Redirect Provider

A general service does imho not sense. That service has no knowledge about where resources are coming from and how binaries a stored. A resource provider does know these things. This leaves us with two options: we allow multiple services to be registered. Each service than has to check if it kn

Re: Redirect Provider

Casting is bad, but as RedirectResolver is the result of adapting a resource, the implementation has access to the resource already. So no need for SlingHttpServletRequest or casting etc. Regards Carsten On 31.01.2020 01:59, Ian Boston wrote: Hi, NO_REDIRECT, good point, added. I think HttpS

Re: Redirect Provider

Hi, I started with that service pattern, as you have suggested, but Carsten asked we used a provider with the adaptTo pattern. He can explain. He does that better. It made sense to me when he did. Best Regards Ian On Fri, 31 Jan 2020 at 12:02, Radu Cotescu wrote: > Hi Ian, > > I posted a comment

Re: Redirect Provider

Hi Ian, I posted a comment to your gist [2] where I just changed the pattern to not use adaptTo. WDYT? Thanks, Radu [2] - https://gist.github.com/ieb/5f217e2c160afb7bb4098bca99896621#gistcomment-3162233

Re: Redirect Provider

Hi, On Fri, Jan 31, 2020 at 11:00 AM Ian Boston wrote: > ...If an implementation of a RedirectResolver requires SlingHttpServletRequest > it can check for that and cast to it, returning NO_REDIRECT if the context > isn't what it required... Makes sense and that's probably going to be an infreque

Re: Redirect Provider

Hi, Good observations. > Why not return RedirectResponse from RedirectResolver#resolve(SlingHttpServletRequest)? This would obviate the need for the magic NO_REDIRECT status code. Instead null could be returned if no redirect should be performed. Initially an interface was used, and hence passed

Re: Redirect Provider

Hi, Why not return RedirectResponse from RedirectResolver#resolve(SlingHttpServletRequest)? This would obviate the need for the magic NO_REDIRECT status code. Instead null could be returned if no redirect should be performed. I am also wondering if it is sensible to encode the word "redirect" int

Re: Redirect Provider

Hi, NO_REDIRECT, good point, added. I think HttpServletRequest is better as it is wider. If an implementation of a RedirectResolver requires SlingHttpServletRequest it can check for that and cast to it, returning NO_REDIRECT if the context isn't what it required. Best Regards Ian On Fri, 31 Jan

Re: Redirect Provider

Hi, On Fri, Jan 31, 2020 at 9:11 AM Ian Boston wrote: .. > 1 https://gist.github.com/ieb/5f217e2c160afb7bb4098bca99896621 ... The RedirectResolver gets an HttpServletRequest, shouldn't that be a SlingHttpServletRequest to be able to get at the Resource, selectors etc? I understand the Resource

Re: Redirect Provider

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 (RedirectRespon

Re: Redirect Provider

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 res

Re: Redirect Provider

On Thu, 2020-01-30 at 09:52 +0100, 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) I think that requires a separate discussion, as I don't see consensus on that. Thanks, Robert

Re: Redirect Provider

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 wrote: > > A resource might be adaptable to RedirectProvider.

Re: Redirect Provider

I think we should create two interfaces (names are not final): RedirectProvider and RedirectResponse. A resource might be adaptable to RedirectProvider. If it is the stream get servlet uses it to do the redirect. RedirectResponse is a stripped down version of the HttpServletResponse just allow

Redirect Provider

Hi, I have been talking with Carsten and Robert offline about a better solution to replace the URIProvider which to be frank, isn't really working for us. For those that don't know, its used inside the Slng Default Get servlet to allow that servlet to return a redirect instead of sending a stream o