Re: [ANN] New committer: Amit Gupta
On Thu, Nov 14, 2013 at 4:26 AM, Felix Meschberger fmesc...@adobe.com wrote: ...Based on his ongoing and valuable contributions to the project, the Sling PMC has elected Amit Gupta (amitgupt) as a Sling committer, and he has accepted the invitation... Welcome Amit! -Bertrand
Re: [VOTE] - Accept donation of replication module to Apache Sling
On Thu, Nov 14, 2013 at 8:37 AM, Tommaso Teofili tommaso.teof...@gmail.com wrote: as far as I know there's usually a vote on the dev@ list for first acceptance (and then it's referenced in the IP Clearance file), then the IP Clearance is done... That's how I see it as well, hence my +1 conditional on doing the IP clearance. -Bertrand
RE: [ANN] New committer: Amit Gupta
Hi, Thanks Felix, Chetan Bertrand for a warm welcome. Thanks to the team for this opportunity. Introduction: I work for Adobe Systems and have been using Sling for past couple of years. It is absolutely fantastic, and I look forward to make it even better. Thanks, Amit
Re: FYI: feature flags prototype
Rather I could imagine backing this into the ResourceResolver itself ... I think we should avoid going down this route. The ResourceResolver is a core feature of Sling, while feature-flags is (should be) an optional feature. Baking feature-flags into the RR would violate modularity IMO. One way to achieve the same integration without baking that functionality into the RR would be to create an extension hook that allows decorating the RR. Then the FF bundle could provide such a decorator and filter resources according to its needs. Regards Julian On Thu, Nov 14, 2013 at 1:30 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi I agree that it would be cool to also select resources based on features. But I think the access gate is the wrong mechanism: Access Control and Feature Selection are different beasts and should not be mixed. Rather I could imagine backing this into the ResourceResolver itself: before returning a Resource it is checked for a feature flag property (e.g. sling:feature ?) and this being checked against the Feature service. If not enabled, that resource is „hidden“ and not returned. WDYT ? Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 14.11.2013 um 02:21 schrieb Dominik Süß dominik.su...@gmail.com: Hi Ruben, the intention is to disable features that are not should not be globally available but might be activated under certain conditions. This reduces the need to branch non-production ready features away and merge them in later and opens the option to have something like a Friendly user Test or softlaunch of a feature. Therefore this can be something big or something small. I think a solution should be capable of dealing with both. The java API would allow to hook in at any granularity level of the application so this already fullfills the requirements I'd have. Adding a corresponding declarative logic to filter the resourcetree would give the same coarse and/or finegrained filtermechanism to the resolutionprocess. What still would be missing is controlling updates and not just additions. e.g. when a resource should be rendered by a new version of a resourceType - in such case it might be an option to extend the searchpath from /libs/../myresourcetype, /apps/../myresourcetype by featurespecific overlaypaths that would either be searched when a feature is activated or hidden if the feature is deactivated. This would require refactoring later on but would allow parallel existance of multiple versions of a resourceType. Best regards, Dominik On Wed, Nov 13, 2013 at 4:02 PM, Ruben Reusser r...@headwire.com wrote: Bertrand, Dominik, the feature flag may also have an impact on the nodes/properties that you need to render the feature. Being able to handle this in the resource tree directly without having to handle it in component code would be great. However, I am not sure if the intention of the feature flag was more to enable/change little features (code fragment) and not really change big things (leave that to testtarget or other products?) Ruben On 11/13/2013 6:32 AM, Dominik Süß wrote: Hi Bertrand, the UI of an application based on Sling are often composed of existing resourceTypes so you cannot just decide in the code to display or not to display so you have to annotate/flag the resources and then have some code deciding if this resource should be rendered or not. For sure you could add code to each resource to check if it is to be rendered but this is a lot of repetive code. Another option would be a Servlet filter to skip inclusion at that Point. But this all fails in some situations like whenyou consume an aggregated json dump and use this on client side. Therefore the only shared location that all code should act on when looking at the persistance is the resourcetree, and as already existing API the Access Gate API seems to be capable of doing exactly what is required - masking the resourcetree based on custom logic. Best regards Dominik On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Dominik, On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß dominik.su...@gmail.com wrote: ...as far as I can see the API is just covering the java aspect of this... Nothing prevents you from using the FeatureFlags service in scripted code. you could have a gate looking for a marker at a resource which indicates it to be part of a specific feature and therefore disables access to it Do we need any changes to Sling or to this new API to enable that? The problem IMO is that this makes the whole thing less transparent than using feature flags in the rendering code. OTOH if people can implement it themselves (and add the corresponding info to RequestProgressTracker) for transparency, I don't mind. -Bertrand
Re: FYI: feature flags prototype
+1 on extension hook in RR and adding this I had no closer look at Accessgate yet and thought it to behave that way from initial talks about this before implementation started. I just thought that Access Control is not just about permissions, it is about granting or denying access based on what ever logic you implement. Best regards Dominik On Thu, Nov 14, 2013 at 12:12 PM, Julian Sedding jsedd...@gmail.com wrote: Rather I could imagine backing this into the ResourceResolver itself ... I think we should avoid going down this route. The ResourceResolver is a core feature of Sling, while feature-flags is (should be) an optional feature. Baking feature-flags into the RR would violate modularity IMO. One way to achieve the same integration without baking that functionality into the RR would be to create an extension hook that allows decorating the RR. Then the FF bundle could provide such a decorator and filter resources according to its needs. Regards Julian On Thu, Nov 14, 2013 at 1:30 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi I agree that it would be cool to also select resources based on features. But I think the access gate is the wrong mechanism: Access Control and Feature Selection are different beasts and should not be mixed. Rather I could imagine backing this into the ResourceResolver itself: before returning a Resource it is checked for a feature flag property (e.g. sling:feature ?) and this being checked against the Feature service. If not enabled, that resource is „hidden“ and not returned. WDYT ? Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 14.11.2013 um 02:21 schrieb Dominik Süß dominik.su...@gmail.com: Hi Ruben, the intention is to disable features that are not should not be globally available but might be activated under certain conditions. This reduces the need to branch non-production ready features away and merge them in later and opens the option to have something like a Friendly user Test or softlaunch of a feature. Therefore this can be something big or something small. I think a solution should be capable of dealing with both. The java API would allow to hook in at any granularity level of the application so this already fullfills the requirements I'd have. Adding a corresponding declarative logic to filter the resourcetree would give the same coarse and/or finegrained filtermechanism to the resolutionprocess. What still would be missing is controlling updates and not just additions. e.g. when a resource should be rendered by a new version of a resourceType - in such case it might be an option to extend the searchpath from /libs/../myresourcetype, /apps/../myresourcetype by featurespecific overlaypaths that would either be searched when a feature is activated or hidden if the feature is deactivated. This would require refactoring later on but would allow parallel existance of multiple versions of a resourceType. Best regards, Dominik On Wed, Nov 13, 2013 at 4:02 PM, Ruben Reusser r...@headwire.com wrote: Bertrand, Dominik, the feature flag may also have an impact on the nodes/properties that you need to render the feature. Being able to handle this in the resource tree directly without having to handle it in component code would be great. However, I am not sure if the intention of the feature flag was more to enable/change little features (code fragment) and not really change big things (leave that to testtarget or other products?) Ruben On 11/13/2013 6:32 AM, Dominik Süß wrote: Hi Bertrand, the UI of an application based on Sling are often composed of existing resourceTypes so you cannot just decide in the code to display or not to display so you have to annotate/flag the resources and then have some code deciding if this resource should be rendered or not. For sure you could add code to each resource to check if it is to be rendered but this is a lot of repetive code. Another option would be a Servlet filter to skip inclusion at that Point. But this all fails in some situations like whenyou consume an aggregated json dump and use this on client side. Therefore the only shared location that all code should act on when looking at the persistance is the resourcetree, and as already existing API the Access Gate API seems to be capable of doing exactly what is required - masking the resourcetree based on custom logic. Best regards Dominik On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Dominik, On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß dominik.su...@gmail.com wrote: ...as far as I can see the API is just covering the java aspect of this... Nothing prevents you from using the FeatureFlags service in scripted code. you could have a gate looking for a marker at a
Re: FYI: feature flags prototype
On Thu, Nov 14, 2013 at 12:12 PM, Julian Sedding jsedd...@gmail.com wrote: ...One way to achieve the same integration without baking that functionality into the RR would be to create an extension hook that allows decorating the RR... I agree that we shouldn't bake feature flags deep into Sling, at least not right now until we see how people use them. If a ResourceResolver is generally useful, that might be a good option. -Bertrand
Re: FYI: feature flags prototype
On Wed, Nov 13, 2013 at 1:06 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Robert, On Tue, Nov 12, 2013 at 5:38 PM, Robert Munteanu rob...@lmn.ro wrote: ...1. I am typically wary of using Strings and am thinking that Enums would be a nice fit for feature flags... I see your point, what's the reason? Performance? Risk of typos? ...how about having a FeatureFlag marker interface and them enums can implement it?... The problem (and this isn't visible in my too contrived examples for now) is that the feature flag names will mostly be defined by configurations IMO. For example, if you have a feature flag set by a cookie with a specific value, the config would be: cookie name=foo value=bar feature flag name=foobar.cookie And another instance of the same service would have different config values and needs a unique feature flag ID. Do you see a way of generating enums with unique and discoverable values for such a case? Hm, no. Given this use cases I think that Strings are fine. Robert -- Sent from my (old) computer
RE: FYI: feature flags prototype
To confirm what Dominik mentioned: The existing ResourceAccessGate would allow to grant or deny access to resources. IMHO there's no need to implement another interface or hook to achieve what is requested in the perspective of granting or denying access to resources based on feature flag. Just implement a FeatureFlagResourceGate (or whatever name would make sense).. best regards Mike -Original Message- From: Dominik Süß [mailto:dominik.su...@gmail.com] Sent: Thursday, November 14, 2013 1:07 PM To: dev Subject: Re: FYI: feature flags prototype +1 on extension hook in RR and adding this I had no closer look at Accessgate yet and thought it to behave that way from initial talks about this before implementation started. I just thought that Access Control is not just about permissions, it is about granting or denying access based on what ever logic you implement. Best regards Dominik On Thu, Nov 14, 2013 at 12:12 PM, Julian Sedding jsedd...@gmail.com wrote: Rather I could imagine backing this into the ResourceResolver itself ... I think we should avoid going down this route. The ResourceResolver is a core feature of Sling, while feature-flags is (should be) an optional feature. Baking feature-flags into the RR would violate modularity IMO. One way to achieve the same integration without baking that functionality into the RR would be to create an extension hook that allows decorating the RR. Then the FF bundle could provide such a decorator and filter resources according to its needs. Regards Julian On Thu, Nov 14, 2013 at 1:30 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi I agree that it would be cool to also select resources based on features. But I think the access gate is the wrong mechanism: Access Control and Feature Selection are different beasts and should not be mixed. Rather I could imagine backing this into the ResourceResolver itself: before returning a Resource it is checked for a feature flag property (e.g. sling:feature ?) and this being checked against the Feature service. If not enabled, that resource is „hidden“ and not returned. WDYT ? Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 14.11.2013 um 02:21 schrieb Dominik Süß dominik.su...@gmail.com: Hi Ruben, the intention is to disable features that are not should not be globally available but might be activated under certain conditions. This reduces the need to branch non-production ready features away and merge them in later and opens the option to have something like a Friendly user Test or softlaunch of a feature. Therefore this can be something big or something small. I think a solution should be capable of dealing with both. The java API would allow to hook in at any granularity level of the application so this already fullfills the requirements I'd have. Adding a corresponding declarative logic to filter the resourcetree would give the same coarse and/or finegrained filtermechanism to the resolutionprocess. What still would be missing is controlling updates and not just additions. e.g. when a resource should be rendered by a new version of a resourceType - in such case it might be an option to extend the searchpath from /libs/../myresourcetype, /apps/../myresourcetype by featurespecific overlaypaths that would either be searched when a feature is activated or hidden if the feature is deactivated. This would require refactoring later on but would allow parallel existance of multiple versions of a resourceType. Best regards, Dominik On Wed, Nov 13, 2013 at 4:02 PM, Ruben Reusser r...@headwire.com wrote: Bertrand, Dominik, the feature flag may also have an impact on the nodes/properties that you need to render the feature. Being able to handle this in the resource tree directly without having to handle it in component code would be great. However, I am not sure if the intention of the feature flag was more to enable/change little features (code fragment) and not really change big things (leave that to testtarget or other products?) Ruben On 11/13/2013 6:32 AM, Dominik Süß wrote: Hi Bertrand, the UI of an application based on Sling are often composed of existing resourceTypes so you cannot just decide in the code to display or not to display so you have to annotate/flag the resources and then have some code deciding if this resource should be rendered or not. For sure you could add code to each resource to check if it is to be rendered but this is a lot of repetive code. Another option would be a Servlet filter to skip inclusion at that Point. But this all fails in some situations like whenyou consume an aggregated json dump and use this on client side. Therefore the only shared
Re: FYI: feature flags prototype
On Thu, Nov 14, 2013 at 1:56 PM, Mike Müller mike...@mysign.ch wrote: ...Just implement a FeatureFlagResourceGate (or whatever name would make sense).. My earlier question was, can one do this without any changes to Sling besides providing a way to find if a given feature is enabled, like in my prototype? I think the answer is yes, and if is is I wouldn't worry about it - let users implement that themselves to start with, but don't put anything in Sling for now besides the raw FeatureFlags (or Feature) service. Then, if common use cases emerge that need something in Sling, implement that - but cross that bridge once we get there. -Bertrand
Re: FYI: feature flags prototype
Hi Bertrand, I disagree on that one - maybe we should put it in contrib or so, but is is essential to disable most features to disable some parts of the resourcetree. This is just applying your api in a conventient api to resource resolving. There is no additional magic since developers would have to set the flag in the content anyways. As mentioned earlier the majority of features I have implemented yet do have a frontendpart that would get rendered and it would add additional complexity if I have to use custom resourceTypes (inherited ones through superType) just to disable them based on such rules. Best regards Dominik On Thu, Nov 14, 2013 at 2:03 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Nov 14, 2013 at 1:56 PM, Mike Müller mike...@mysign.ch wrote: ...Just implement a FeatureFlagResourceGate (or whatever name would make sense).. My earlier question was, can one do this without any changes to Sling besides providing a way to find if a given feature is enabled, like in my prototype? I think the answer is yes, and if is is I wouldn't worry about it - let users implement that themselves to start with, but don't put anything in Sling for now besides the raw FeatureFlags (or Feature) service. Then, if common use cases emerge that need something in Sling, implement that - but cross that bridge once we get there. -Bertrand
Re: FYI: feature flags prototype
Hi Sure you can do it, but it (a) doesn’t match the idea of an access gate (at least not in my little brain cells) and (b) it is not comprehensive since the JCR Resource Provider does not leverage that. (b) is IMHO the one reason breaking the idea. I like the idea of a decoration hook. Yet: it might have to be implemented somewhat differently because we don’t just want to have or have not a resource. In some cases we want to fall back to a resource with a lower „priority“ such as a resource furhter in the search path sequence. Just having a decorating hook would not solve this issue. Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 14.11.2013 um 23:56 schrieb Mike Müller mike...@mysign.ch: To confirm what Dominik mentioned: The existing ResourceAccessGate would allow to grant or deny access to resources. IMHO there's no need to implement another interface or hook to achieve what is requested in the perspective of granting or denying access to resources based on feature flag. Just implement a FeatureFlagResourceGate (or whatever name would make sense).. best regards Mike -Original Message- From: Dominik Süß [mailto:dominik.su...@gmail.com] Sent: Thursday, November 14, 2013 1:07 PM To: dev Subject: Re: FYI: feature flags prototype +1 on extension hook in RR and adding this I had no closer look at Accessgate yet and thought it to behave that way from initial talks about this before implementation started. I just thought that Access Control is not just about permissions, it is about granting or denying access based on what ever logic you implement. Best regards Dominik On Thu, Nov 14, 2013 at 12:12 PM, Julian Sedding jsedd...@gmail.com wrote: Rather I could imagine backing this into the ResourceResolver itself ... I think we should avoid going down this route. The ResourceResolver is a core feature of Sling, while feature-flags is (should be) an optional feature. Baking feature-flags into the RR would violate modularity IMO. One way to achieve the same integration without baking that functionality into the RR would be to create an extension hook that allows decorating the RR. Then the FF bundle could provide such a decorator and filter resources according to its needs. Regards Julian On Thu, Nov 14, 2013 at 1:30 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi I agree that it would be cool to also select resources based on features. But I think the access gate is the wrong mechanism: Access Control and Feature Selection are different beasts and should not be mixed. Rather I could imagine backing this into the ResourceResolver itself: before returning a Resource it is checked for a feature flag property (e.g. sling:feature ?) and this being checked against the Feature service. If not enabled, that resource is „hidden“ and not returned. WDYT ? Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 14.11.2013 um 02:21 schrieb Dominik Süß dominik.su...@gmail.com: Hi Ruben, the intention is to disable features that are not should not be globally available but might be activated under certain conditions. This reduces the need to branch non-production ready features away and merge them in later and opens the option to have something like a Friendly user Test or softlaunch of a feature. Therefore this can be something big or something small. I think a solution should be capable of dealing with both. The java API would allow to hook in at any granularity level of the application so this already fullfills the requirements I'd have. Adding a corresponding declarative logic to filter the resourcetree would give the same coarse and/or finegrained filtermechanism to the resolutionprocess. What still would be missing is controlling updates and not just additions. e.g. when a resource should be rendered by a new version of a resourceType - in such case it might be an option to extend the searchpath from /libs/../myresourcetype, /apps/../myresourcetype by featurespecific overlaypaths that would either be searched when a feature is activated or hidden if the feature is deactivated. This would require refactoring later on but would allow parallel existance of multiple versions of a resourceType. Best regards, Dominik On Wed, Nov 13, 2013 at 4:02 PM, Ruben Reusser r...@headwire.com wrote: Bertrand, Dominik, the feature flag may also have an impact on the nodes/properties that you need to render the feature. Being able to handle this in the resource tree directly without having to handle it in component code would be great. However, I am not sure if the intention of the feature flag was more to enable/change little features (code fragment) and not really change big things (leave that to testtarget or other products?) Ruben On 11/13/2013 6:32 AM, Dominik Süß wrote: Hi Bertrand, the UI of an application
Re: FYI: feature flags prototype
Hi Agreed: Sling should come with a support for Feature-based resource filtering (or however we call that mechanism) and it should be on the same level (contrib or bundles) as the Features feature itself. Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 15.11.2013 um 00:11 schrieb Dominik Süß dominik.su...@gmail.com: Hi Bertrand, I disagree on that one - maybe we should put it in contrib or so, but is is essential to disable most features to disable some parts of the resourcetree. This is just applying your api in a conventient api to resource resolving. There is no additional magic since developers would have to set the flag in the content anyways. As mentioned earlier the majority of features I have implemented yet do have a frontendpart that would get rendered and it would add additional complexity if I have to use custom resourceTypes (inherited ones through superType) just to disable them based on such rules. Best regards Dominik On Thu, Nov 14, 2013 at 2:03 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Nov 14, 2013 at 1:56 PM, Mike Müller mike...@mysign.ch wrote: ...Just implement a FeatureFlagResourceGate (or whatever name would make sense).. My earlier question was, can one do this without any changes to Sling besides providing a way to find if a given feature is enabled, like in my prototype? I think the answer is yes, and if is is I wouldn't worry about it - let users implement that themselves to start with, but don't put anything in Sling for now besides the raw FeatureFlags (or Feature) service. Then, if common use cases emerge that need something in Sling, implement that - but cross that bridge once we get there. -Bertrand
Re: FYI: feature flags prototype
On Thu, Nov 14, 2013 at 2:37 PM, Felix Meschberger fmesc...@adobe.com wrote: ...Agreed: Sling should come with a support for Feature-based resource filtering (or however we call that mechanism) and it should be on the same level (contrib or bundles) as the Features feature itself... ok, ok...makes sense ;-) -Bertrand
Re: FYI: feature flags prototype
Hi Felix, see my comments inline. Best regards Dominik On Thu, Nov 14, 2013 at 2:35 PM, Felix Meschberger fmesc...@adobe.comwrote: Hi Sure you can do it, but it (a) doesn’t match the idea of an access gate (at least not in my little brain cells) and (b) it is not comprehensive since the JCR Resource Provider does not leverage that. (b) is IMHO the one reason breaking the idea. Although I disagree on a (what else is this but restriction of access (don't mix it with permission by default) if b is the case (so it could not be granted to act on the global resource Tree I agree this would be a no go I like the idea of a decoration hook. Yet: it might have to be implemented somewhat differently because we don’t just want to have or have not a resource. In some cases we want to fall back to a resource with a lower „priority“ such as a resource furhter in the search path sequence. Just having a decorating hook would not solve this issue. Why is that? The searchpath isn't influenced at all, it is just that in one of the locations a specific verison is not there. What on the other hand could break is a superType chain, but This is something the developer should be aware when implementing. (given that decoration could be removal as well) Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 14.11.2013 um 23:56 schrieb Mike Müller mike...@mysign.ch: To confirm what Dominik mentioned: The existing ResourceAccessGate would allow to grant or deny access to resources. IMHO there's no need to implement another interface or hook to achieve what is requested in the perspective of granting or denying access to resources based on feature flag. Just implement a FeatureFlagResourceGate (or whatever name would make sense).. best regards Mike -Original Message- From: Dominik Süß [mailto:dominik.su...@gmail.com] Sent: Thursday, November 14, 2013 1:07 PM To: dev Subject: Re: FYI: feature flags prototype +1 on extension hook in RR and adding this I had no closer look at Accessgate yet and thought it to behave that way from initial talks about this before implementation started. I just thought that Access Control is not just about permissions, it is about granting or denying access based on what ever logic you implement. Best regards Dominik On Thu, Nov 14, 2013 at 12:12 PM, Julian Sedding jsedd...@gmail.com wrote: Rather I could imagine backing this into the ResourceResolver itself ... I think we should avoid going down this route. The ResourceResolver is a core feature of Sling, while feature-flags is (should be) an optional feature. Baking feature-flags into the RR would violate modularity IMO. One way to achieve the same integration without baking that functionality into the RR would be to create an extension hook that allows decorating the RR. Then the FF bundle could provide such a decorator and filter resources according to its needs. Regards Julian On Thu, Nov 14, 2013 at 1:30 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi I agree that it would be cool to also select resources based on features. But I think the access gate is the wrong mechanism: Access Control and Feature Selection are different beasts and should not be mixed. Rather I could imagine backing this into the ResourceResolver itself: before returning a Resource it is checked for a feature flag property (e.g. sling:feature ?) and this being checked against the Feature service. If not enabled, that resource is „hidden“ and not returned. WDYT ? Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 14.11.2013 um 02:21 schrieb Dominik Süß dominik.su...@gmail.com: Hi Ruben, the intention is to disable features that are not should not be globally available but might be activated under certain conditions. This reduces the need to branch non-production ready features away and merge them in later and opens the option to have something like a Friendly user Test or softlaunch of a feature. Therefore this can be something big or something small. I think a solution should be capable of dealing with both. The java API would allow to hook in at any granularity level of the application so this already fullfills the requirements I'd have. Adding a corresponding declarative logic to filter the resourcetree would give the same coarse and/or finegrained filtermechanism to the resolutionprocess. What still would be missing is controlling updates and not just additions. e.g. when a resource should be rendered by a new version of a resourceType - in such case it might be an option to extend the searchpath from /libs/../myresourcetype, /apps/../myresourcetype by featurespecific overlaypaths that would either be searched when a feature is activated or hidden if the feature is deactivated. This would require
RE: FYI: feature flags prototype
On Thu, Nov 14, 2013 at 2:35 PM, Felix Meschberger fmesc...@adobe.comwrote: Hi Sure you can do it, but it (a) doesn’t match the idea of an access gate (at least not in my little brain cells) and (b) it is not comprehensive since the JCR Resource Provider does not leverage that. (b) is IMHO the one reason breaking the idea. Although I disagree on a (what else is this but restriction of access (don't mix it with permission by default) if b is the case (so it could not be granted to act on the global resource Tree I agree this would be a no go The ResourceAccessGate could be used for every resource provider, it's only not configured for JCRResourceProvider (but could by just setting a flag in the OSGi configuration). The good reason for not enabling it is that ACLs of the JCR shouldn't be mixed up with custom ACLs. But in the use case of enabling features or not, ResourceAccessGate could be a lean solution to hide some resources and does not mix up with ACLs. best regards mike
[jira] [Commented] (SLING-3147) Oak: i18n dictionaries observation no longer works
[ https://issues.apache.org/jira/browse/SLING-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13822600#comment-13822600 ] Bertrand Delacretaz commented on SLING-3147: I have added some tests to the bundles/jcr/it-jackrabbit-oak module in http://svn.apache.org/r1541972 to try to reproduce the problem there, but observation works just fine in those tests. We'll need to dig deeper to find out what's different between both sets of tests. Oak: i18n dictionaries observation no longer works -- Key: SLING-3147 URL: https://issues.apache.org/jira/browse/SLING-3147 Project: Sling Issue Type: Bug Components: Extensions, Oak Affects Versions: i18n 2.2.6 Reporter: Alexander Klimetschek Labels: i18n When running Sling with Oak, the JcrResourceBundleProvider [0] in the i18n bundle apparently no longer gets the observation events for sling:message nodes in the JCR. This means that changing a string in the repo or installing a package with new translations won't have an effect if the resource bundle is already loaded in memory. Workaround is to restart the i18n bundle after every string change. [0] http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java -- This message was sent by Atlassian JIRA (v6.1#6144)
buildbot success in ASF Buildbot on sling-trunk
The Buildbot has detected a restored build on builder sling-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/sling-trunk/builds/7 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: forced: by IRC user bdelacretaz (privmsg): None Build Source Stamp: HEAD Blamelist: Build succeeded! sincerely, -The Buildbot
Re: FYI: feature flags prototype
On 14.11.2013, at 05:11, Dominik Süß dominik.su...@gmail.com wrote: As mentioned earlier the majority of features I have implemented yet do have a frontendpart that would get rendered and it would add additional complexity if I have to use custom resourceTypes (inherited ones through superType) just to disable them based on such rules. Wouldn't you just filter those requests out on a high level, e.g. using a servlet filter? Which can already be provided in a modular fashion by an optional featureflags module. Cheers, Alex
Re: FYI: feature flags prototype
Hi Alex, this is one way but just solves this partially since you completely rely on inclusions to happen, but sometimes you just walk the tree and collect the information of resources e.g. to draw the navigation - and for such situations it would then be required to add such logic to the rendering Code where you could just filter the ResourceTree beforehand. Best regards, Dominik On Thu, Nov 14, 2013 at 10:48 PM, Alexander Klimetschek aklim...@adobe.comwrote: On 14.11.2013, at 05:11, Dominik Süß dominik.su...@gmail.com wrote: As mentioned earlier the majority of features I have implemented yet do have a frontendpart that would get rendered and it would add additional complexity if I have to use custom resourceTypes (inherited ones through superType) just to disable them based on such rules. Wouldn't you just filter those requests out on a high level, e.g. using a servlet filter? Which can already be provided in a modular fashion by an optional featureflags module. Cheers, Alex
Re: FYI: feature flags prototype
Roy Fielding's presentation on the subject may also be interesting http://www.slideshare.net/royfielding/evolve13-keynote-scrambled-eggs page 36 to 45 Ruben On 11/14/2013 1:55 PM, Dominik Süß wrote: Hi Alex, this is one way but just solves this partially since you completely rely on inclusions to happen, but sometimes you just walk the tree and collect the information of resources e.g. to draw the navigation - and for such situations it would then be required to add such logic to the rendering Code where you could just filter the ResourceTree beforehand. Best regards, Dominik On Thu, Nov 14, 2013 at 10:48 PM, Alexander Klimetschek aklim...@adobe.comwrote: On 14.11.2013, at 05:11, Dominik Süß dominik.su...@gmail.com wrote: As mentioned earlier the majority of features I have implemented yet do have a frontendpart that would get rendered and it would add additional complexity if I have to use custom resourceTypes (inherited ones through superType) just to disable them based on such rules. Wouldn't you just filter those requests out on a high level, e.g. using a servlet filter? Which can already be provided in a modular fashion by an optional featureflags module. Cheers, Alex
Re: FYI: feature flags prototype
On 14.11.2013, at 13:55, Dominik Süß dominik.su...@gmail.com wrote: this is one way but just solves this partially since you completely rely on inclusions to happen, but sometimes you just walk the tree and collect the information of resources e.g. to draw the navigation - and for such situations it would then be required to add such logic to the rendering Code where you could just filter the ResourceTree beforehand. I see. And the ResourceDecorator can't filter out things? Cheers, Alex
[jira] [Commented] (SLING-3147) Oak: i18n dictionaries observation no longer works
[
https://issues.apache.org/jira/browse/SLING-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13823027#comment-13823027
]
Alexander Klimetschek commented on SLING-3147:
--
I guess it's a missing {{Session.refresh()}} that is [required in
Oak|http://jackrabbit.apache.org/oak/docs/differences.html]. The
[JcrResourceBundleProvider|http://svn.apache.org/viewvc/sling/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java?revision=1378151view=markuppathrev=1539396]
that registers the event listener uses the same long-running session/resource
resolver for the observation events and reading the actual bundles.
Oak: i18n dictionaries observation no longer works
--
Key: SLING-3147
URL: https://issues.apache.org/jira/browse/SLING-3147
Project: Sling
Issue Type: Bug
Components: Extensions, Oak
Affects Versions: i18n 2.2.6
Reporter: Alexander Klimetschek
Labels: i18n
When running Sling with Oak, the JcrResourceBundleProvider [0] in the i18n
bundle apparently no longer gets the observation events for sling:message
nodes in the JCR. This means that changing a string in the repo or installing
a package with new translations won't have an effect if the resource bundle
is already loaded in memory.
Workaround is to restart the i18n bundle after every string change.
[0]
http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java
--
This message was sent by Atlassian JIRA
(v6.1#6144)
Re: [VOTE] - Accept donation of replication module to Apache Sling
Hi Tommaso, thanks for the explanation - I didn't realize that you are in that early stage :-) I thought that the PMC already gave their OK to go forward with the donation. here's my non binding +1 then :-) Regards, Toby On Thu, Nov 14, 2013 at 1:48 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Nov 14, 2013 at 8:37 AM, Tommaso Teofili tommaso.teof...@gmail.com wrote: as far as I know there's usually a vote on the dev@ list for first acceptance (and then it's referenced in the IP Clearance file), then the IP Clearance is done... That's how I see it as well, hence my +1 conditional on doing the IP clearance. -Bertrand
[jira] [Commented] (SLING-3147) Oak: i18n dictionaries observation no longer works
[ https://issues.apache.org/jira/browse/SLING-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13823337#comment-13823337 ] Tobias Bocanegra commented on SLING-3147: - ...or create the session with auto-refresh. see OAK-803 Oak: i18n dictionaries observation no longer works -- Key: SLING-3147 URL: https://issues.apache.org/jira/browse/SLING-3147 Project: Sling Issue Type: Bug Components: Extensions, Oak Affects Versions: i18n 2.2.6 Reporter: Alexander Klimetschek Labels: i18n When running Sling with Oak, the JcrResourceBundleProvider [0] in the i18n bundle apparently no longer gets the observation events for sling:message nodes in the JCR. This means that changing a string in the repo or installing a package with new translations won't have an effect if the resource bundle is already loaded in memory. Workaround is to restart the i18n bundle after every string change. [0] http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: FYI: feature flags prototype
Am 14.11.2013 23:11 schrieb Alexander Klimetschek aklim...@adobe.com: On 14.11.2013, at 13:55, Dominik Süß dominik.su...@gmail.com wrote: this is one way but just solves this partially since you completely rely on inclusions to happen, but sometimes you just walk the tree and collect the information of resources e.g. to draw the navigation - and for such situations it would then be required to add such logic to the rendering Code where you could just filter the ResourceTree beforehand. I see. And the ResourceDecorator can't filter out things? No, returning null skips tehe decoration and returns the original resource. You could hide properties but you'd additionally have to handle such resources in applicationcode but having it really jidden. Best regards Dominik
[OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi TL;DR: Long discussion on why I think Feature flag support should currently be baked into the ResourceResolver implementation. I am forking of this discussion now to step back a bit and really look into what we expect from Feature flag support in the ResourceResolver. I go by the main resource access or methods there, so: * resolve() - Resource Calculates a virtual list of resource candidates and returns the first one. Applying feature flags, it might not return the first one. Another level of features could be applied to supporting feature flags in the /etc/map mappings leading to the list of candidate resources. * map - String The input path is first converted into a resource, which may have a feature flag applied. In addition to applying a feature flag to the resource which is finally mapped the /etc/map mappings can also be „filtered“ with feature flags. * getResource() - Resource For absolute path its a single yes/no question: Is the resource visible or not according to the feature flag. For relative paths its not as simple since the ResourceResolver iterates the search path looking for a resource. So each canidate is looked at and has to have its feature flag inspected. (feature flags of ancestors are ignored; only feature flags in the candidate resource itself are considered; so no feature flag inheritance down the tree) * getParentResource() - Resource This is not an interesting case because it accesses the parent resource using the absolute path and we would not expect to get null here (except if the argument resource is the root resource). * listChildren - IteratorResource * getChildren - IterableResource * queryResources - IteratorMapString,Object * findResources - IteratorResource Simple case here: We just exclude child resources whose feature flag refers to a disabled feature. What options do we have ? * ResourceResolverDecorator (to be specced/implemented): Will have to do extra work getResource to iterate the search path for relative resources to consider the feature flag — might optimize by only iterating if the actual getResource method returns a resource with a disabled feature flag. IteratorResource can simply be decorated, too. queryResources is harder again because this might contain results from queries which should not be included according to the feature flag (so each entry would have to be inspected, if at all possible). Also: A ResourceDecorator cannot properly handle feature flags in /etc/map mappings at all and also support feature flags on resolveResource is probably hard to implement because the list of canidate resources is influence by /etc/map mappings so a decorator would have to replicate that work. * ResourceAccessGate: This is not leveraged by all ResourceProviders and we expressely leave it to these services to indicate the use of a gate. Defining Feature flag support to have all ResourceProviders require to leverage ResourceAccessGate sounds contradictionary. Also, while a case can be made for the Feature flag to be some kind of an access gate, the actual idea of the ResourceAccessGate is actual access control as in secure access. Also we just want to apply the feature flag „gate“ to all Resourceproviders not a generic ACL gate which may also be defined. * Bake Feature support into the ResourceResolver implementation: This solves the ResourceResolverDecorator problems by being able to handle Feature flags early. But is bears the problem of overloading the implementation with the feature flag support. So, finally, I agree that baking the feature flag support directly into the ResourceResolver implementation is suboptimal, it is probably still the most comprehensive and complete solution to the requirements. And I cannot conceive plugin hooks (at this point) to define such that we can do feature flag plugins. Is the ServletResolver also affected by feature flags ? Probably not: The ResourceResolver does filter on resource feature flags and the SlingScriptAdapterFactory may apply feature flags for scripting languages and Servlet services may implement OptingServlet and query feature flags in the accepts method. Regards Felix
