+1 for closing the issue
2014-01-28 Felix Meschberger
> Hi
>
> Am 28.01.2014 um 11:44 schrieb Bertrand Delacretaz >:
>
> > Hi,
> >
> > On Tue, Jan 28, 2014 at 11:36 AM, Felix Meschberger
> wrote:
> >> ...I tracked all those changes in SLING-3148 [1]
> >> I would think we can now resolve this
Hi
Am 28.01.2014 um 11:44 schrieb Bertrand Delacretaz :
> Hi,
>
> On Tue, Jan 28, 2014 at 11:36 AM, Felix Meschberger
> wrote:
>> ...I tracked all those changes in SLING-3148 [1]
>> I would think we can now resolve this issue...
>
> Doc nitpick: I see that you have staged some docs at
> conte
Hi,
On Tue, Jan 28, 2014 at 11:36 AM, Felix Meschberger wrote:
> ...I tracked all those changes in SLING-3148 [1]
> I would think we can now resolve this issue...
Doc nitpick: I see that you have staged some docs at
content/documentation/the-sling-engine/featureflags.mdtext, shouldn't
that rathe
Ok, so I finally merged back my whiteboard into trunk and also fixed a few
glitches after the merge.
Now, the ResourceResolver implementation may support feature flags if the
Features service is available. Yet the bundle does only have a dynamic and
optional dependency on the API. So in setups
Hi
Am 27.01.2014 um 15:24 schrieb Carsten Ziegeler :
>>
>> The global one basically just provides access to the raw request while the
>> Sling-embedded one also provides access to the SlingHttpServletRequest as
>> well as the request's ResourceResolver.
>>
>>
> Ah right, because you don't have
>
> The global one basically just provides access to the raw request while the
> Sling-embedded one also provides access to the SlingHttpServletRequest as
> well as the request's ResourceResolver.
>
>
Ah right, because you don't have the resolver in the global filter...but
this means that all flags
Hi
Am 27.01.2014 um 14:58 schrieb Carsten Ziegeler :
> Thanks for the work, Felix - changes look good to me.
Thanks :-)
>
> I'm not sure if we should register two filters, the global one should be
> enough I think.
The global one basically just provides access to the raw request while the
Sl
Thanks for the work, Felix - changes look good to me.
I'm not sure if we should register two filters, the global one should be
enough I think.
Carsten
2014-01-27 Felix Meschberger
> Hi
>
> It took me a bit longer and caused me a few more changes to the
> FeatureFlags stuff ….
>
> So instead o
Hi
It took me a bit longer and caused me a few more changes to the FeatureFlags
stuff ….
So instead of immediately merging back to trunk, lets have another round of
discussions.
The most important changes (off the top of my mind):
* Support HttpServletRequest instead of requiring SlingHttpSer
On Mon, Jan 20, 2014 at 4:25 AM, Carsten Ziegeler wrote:
> ...So I think we should really replace the current implemenation with the new
> one
+1, I also like the whiteboard/fmeschbe/featureflags/feature-flags
implementation.
It will need tests and more debug log messages to be ready for pri
Yes, I can — Probably tomorrow, works ?
Regards
Felix
Am 20.01.2014 um 04:25 schrieb Carsten Ziegeler :
> So I think we should really replace the current implemenation with the new
> one.
>
> @Felix can you do the move please?
>
> Carsten
>
>
> 2014/1/17 Justin Edelson
>
>> Hi Carsten,
>>
So I think we should really replace the current implemenation with the new
one.
@Felix can you do the move please?
Carsten
2014/1/17 Justin Edelson
> Hi Carsten,
> FWIW, what you are describing looks like what I would expect to happen
> - features are applied at the thread level, so any activ
Hi Carsten,
FWIW, what you are describing looks like what I would expect to happen
- features are applied at the thread level, so any activity within
that thread would have the same features.
Regards,
Justin
On Fri, Jan 17, 2014 at 11:10 AM, Carsten Ziegeler wrote:
> Hi Felix,
>
> thanks for tak
Hi Felix,
thanks for taking this up - as briefly discussed offline I like this new
approach. It's less API and better covers our use cases.
The only thing I'm not 100% sure is the evaluation of the features within
the resource resolver. It gets the current client context from the features
service
Hi
As I repeatedly said, I think the Feature Flags support should be implemented
without the ResourceAccessGate mechanism because it is not an access control
thing but a purely operational visibility thing. Also as opposed to access
control, feature flag enabled can and should be controllable b
15 matches
Mail list logo
