[jira] [Created] (SLING-3267) ResourceDecorator returning null should cause Resources to be ignored
Bertrand Delacretaz created SLING-3267: -- Summary: ResourceDecorator returning null should cause Resources to be ignored Key: SLING-3267 URL: https://issues.apache.org/jira/browse/SLING-3267 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.0.6 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor The ResourceDecorator API's decorate(...) method javadocs currently specify that it can return null, but I don't think that's supported in a consistent way in the resource resolving process - returning null causes the resource resolver to supply a null Resource in some cases, which will probably cause NPEs downstream. The javadocs also say If the service does not want to decorate the resource, it should return the original resource which is consistent with how the resource resolver currently operates: returning null is clearly not a way of saying do not decorate this resource. As we're discussing feature flags in Sling, we could clarify this behavior by specifying that a ResourceDecorator returning null causes the resource to be considered as non-existent, and making the corresponding (rather small) changes in the resource resolver code. As every Resource needs to go through the available ResourceDecorators, this is a simple way of making resources hideable based on feature flags. One then just needs to implement a ResourceDecorator that returns null when a Resource must be ignored. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi, On Fri, Nov 15, 2013 at 8:40 AM, Felix Meschberger fmesc...@adobe.com wrote: 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... I had another look at this, and the existing ResourceDecorator already plays a similar role as an extension point to do something to each Resource while it's being resolved. That's already baked in the resource resolver, so we can leverage it without requiring much code changes. ResourceDecorator.decorate(Resource r) returning null is currently only vaguely specified and certainly not used, as that causes NPEs in places - I think we just need to clarify that decorate returning null causes a Resource to be ignored, fix the code so that it's true and we're good. I have created SLING-3267 to track that, I'll create a patch for review there. -Bertrand
[jira] [Commented] (SLING-3267) ResourceDecorator returning null should cause Resources to be ignored
[ https://issues.apache.org/jira/browse/SLING-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841192#comment-13841192 ] Bertrand Delacretaz commented on SLING-3267: I have added tests that clarify the current behavior, in http://svn.apache.org/r1548491 ResourceDecorator returning null should cause Resources to be ignored - Key: SLING-3267 URL: https://issues.apache.org/jira/browse/SLING-3267 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.0.6 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor The ResourceDecorator API's decorate(...) method javadocs currently specify that it can return null, but I don't think that's supported in a consistent way in the resource resolving process - returning null causes the resource resolver to supply a null Resource in some cases, which will probably cause NPEs downstream. The javadocs also say If the service does not want to decorate the resource, it should return the original resource which is consistent with how the resource resolver currently operates: returning null is clearly not a way of saying do not decorate this resource. As we're discussing feature flags in Sling, we could clarify this behavior by specifying that a ResourceDecorator returning null causes the resource to be considered as non-existent, and making the corresponding (rather small) changes in the resource resolver code. As every Resource needs to go through the available ResourceDecorators, this is a simple way of making resources hideable based on feature flags. One then just needs to implement a ResourceDecorator that returns null when a Resource must be ignored. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3265) Implement suggestions from SLING-3223 in Sling replication
[ https://issues.apache.org/jira/browse/SLING-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841206#comment-13841206 ] Tommaso Teofili commented on SLING-3265: I'll create a new patch in a short while, as I've noticed there's some old stuff that shouldn't be there. Implement suggestions from SLING-3223 in Sling replication -- Key: SLING-3265 URL: https://issues.apache.org/jira/browse/SLING-3265 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Tommaso Teofili Attachments: SLING-3265.patch Umbrella issue to track implementation of improvements for Sling Replication as suggested in SLING-3223 comments. Main ones refer to: - more tests - fix javadoc / typos - avoid AdapterFactory for installing packages - fix action names - refactor AuthenticationHandlers -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3267) ResourceDecorator returning null should cause Resources to be ignored
[ https://issues.apache.org/jira/browse/SLING-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841233#comment-13841233 ] Justin Edelson commented on SLING-3267: --- Agreed - a ResourceDecorator returning null shouldn't cause the ResourceResolver contract to be violated. Specifically: * getResource() - returns null when no resource * listChildren() - returns an interator of non-null resources (which should not include NonExistingResources, although this may need to be clarified in the docs) * findResource() - returns an interator of non-null resources (which should not include NonExistingResources as by definition, those did not match the query) * queryResources() - returns an interator of maps (which should not include NonExistingResources as by definition, those did not match the query) * resolve() - returns NonExistingResource when no resource ResourceDecorator returning null should cause Resources to be ignored - Key: SLING-3267 URL: https://issues.apache.org/jira/browse/SLING-3267 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.0.6 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor The ResourceDecorator API's decorate(...) method javadocs currently specify that it can return null, but I don't think that's supported in a consistent way in the resource resolving process - returning null causes the resource resolver to supply a null Resource in some cases, which will probably cause NPEs downstream. The javadocs also say If the service does not want to decorate the resource, it should return the original resource which is consistent with how the resource resolver currently operates: returning null is clearly not a way of saying do not decorate this resource. As we're discussing feature flags in Sling, we could clarify this behavior by specifying that a ResourceDecorator returning null causes the resource to be considered as non-existent, and making the corresponding (rather small) changes in the resource resolver code. As every Resource needs to go through the available ResourceDecorators, this is a simple way of making resources hideable based on feature flags. One then just needs to implement a ResourceDecorator that returns null when a Resource must be ignored. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3267) ResourceDecorator returning null should cause Resources to be ignored
[
https://issues.apache.org/jira/browse/SLING-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841238#comment-13841238
]
Simone Tripodi commented on SLING-3267:
---
{quote}
* listChildren() - returns an interator of non-null resources (which should
not include NonExistingResources, although this may need to be clarified in the
docs)
* findResource() - returns an interator of non-null resources (which should
not include NonExistingResources as by definition, those did not match the
query)
* queryResources() - returns an interator of maps (which should not include
NonExistingResources as by definition, those did not match the query)
{quote}
+1 :)
As a side note, it would be useful to make the {{NonExistingResource}} as
non-final, since users can extend it for other use-cases such as _Feature
Flags_ :P
ResourceDecorator returning null should cause Resources to be ignored
-
Key: SLING-3267
URL: https://issues.apache.org/jira/browse/SLING-3267
Project: Sling
Issue Type: Improvement
Components: ResourceResolver
Affects Versions: Resource Resolver 1.0.6
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
Priority: Minor
The ResourceDecorator API's decorate(...) method javadocs currently specify
that it can return null, but I don't think that's supported in a consistent
way in the resource resolving process - returning null causes the resource
resolver to supply a null Resource in some cases, which will probably cause
NPEs downstream.
The javadocs also say If the service does not want to decorate the resource,
it should return the original resource which is consistent with how the
resource resolver currently operates: returning null is clearly not a way of
saying do not decorate this resource.
As we're discussing feature flags in Sling, we could clarify this behavior by
specifying that a ResourceDecorator returning null causes the resource to be
considered as non-existent, and making the corresponding (rather small)
changes in the resource resolver code.
As every Resource needs to go through the available ResourceDecorators, this
is a simple way of making resources hideable based on feature flags. One then
just needs to implement a ResourceDecorator that returns null when a Resource
must be ignored.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (SLING-3267) ResourceDecorator returning null should cause Resources to be ignored
[ https://issues.apache.org/jira/browse/SLING-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841242#comment-13841242 ] Felix Meschberger commented on SLING-3267: -- Please don't apply this change. Rather we should properly document what happens when a ResourceDecorator returns null: That the resource is not decorated by the ResourceDecorator. A ResourceDecorator is not here to hide a resource but to decorate a found resource. We should not bend this feature for the feature flag support (which cannot be properly handled by a ResourceDecorator anyway). ResourceDecorator returning null should cause Resources to be ignored - Key: SLING-3267 URL: https://issues.apache.org/jira/browse/SLING-3267 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.0.6 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor The ResourceDecorator API's decorate(...) method javadocs currently specify that it can return null, but I don't think that's supported in a consistent way in the resource resolving process - returning null causes the resource resolver to supply a null Resource in some cases, which will probably cause NPEs downstream. The javadocs also say If the service does not want to decorate the resource, it should return the original resource which is consistent with how the resource resolver currently operates: returning null is clearly not a way of saying do not decorate this resource. As we're discussing feature flags in Sling, we could clarify this behavior by specifying that a ResourceDecorator returning null causes the resource to be considered as non-existent, and making the corresponding (rather small) changes in the resource resolver code. As every Resource needs to go through the available ResourceDecorators, this is a simple way of making resources hideable based on feature flags. One then just needs to implement a ResourceDecorator that returns null when a Resource must be ignored. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3267) ResourceDecorator returning null should cause Resources to be ignored
[ https://issues.apache.org/jira/browse/SLING-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841259#comment-13841259 ] Bertrand Delacretaz commented on SLING-3267: My http://svn.apache.org/r1548491 changes just clarify the current behavior - no changes under src/main, only new tests, so there's no reason to remove them. Also, IgnoredResourcesTest demonstrates that ResourceDecorator returning null does cause null Resources to appear in places, so if we clarify that returning null means don't decorate we'll need to fix that. ResourceDecorator returning null should cause Resources to be ignored - Key: SLING-3267 URL: https://issues.apache.org/jira/browse/SLING-3267 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.0.6 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor The ResourceDecorator API's decorate(...) method javadocs currently specify that it can return null, but I don't think that's supported in a consistent way in the resource resolving process - returning null causes the resource resolver to supply a null Resource in some cases, which will probably cause NPEs downstream. The javadocs also say If the service does not want to decorate the resource, it should return the original resource which is consistent with how the resource resolver currently operates: returning null is clearly not a way of saying do not decorate this resource. As we're discussing feature flags in Sling, we could clarify this behavior by specifying that a ResourceDecorator returning null causes the resource to be considered as non-existent, and making the corresponding (rather small) changes in the resource resolver code. As every Resource needs to go through the available ResourceDecorators, this is a simple way of making resources hideable based on feature flags. One then just needs to implement a ResourceDecorator that returns null when a Resource must be ignored. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (SLING-3267) ResourceDecorator returning null should cause Resources to be ignored
[ https://issues.apache.org/jira/browse/SLING-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-3267: --- Attachment: SLING-3267.patch Here's my suggested patch where a null ResourceDecorator.decorate() return value causes a Resource to be ignored. All tests including the launchpad/testing tests pass with this patch. I think the IgnoredResourcesTest and ResourceIteratorDecoratorTest in the patch demonstrate the behavior described by [~justinedelson], a review of that is welcome. We can discuss on list whether using the ResourceDecorator to handle feature flags is appropriate, but in any case it might be good to clarify what ResourceDecorator.decorate returning null means, and fix our code so that it actually does what it should. ResourceDecorator returning null should cause Resources to be ignored - Key: SLING-3267 URL: https://issues.apache.org/jira/browse/SLING-3267 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.0.6 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Attachments: SLING-3267.patch The ResourceDecorator API's decorate(...) method javadocs currently specify that it can return null, but I don't think that's supported in a consistent way in the resource resolving process - returning null causes the resource resolver to supply a null Resource in some cases, which will probably cause NPEs downstream. The javadocs also say If the service does not want to decorate the resource, it should return the original resource which is consistent with how the resource resolver currently operates: returning null is clearly not a way of saying do not decorate this resource. As we're discussing feature flags in Sling, we could clarify this behavior by specifying that a ResourceDecorator returning null causes the resource to be considered as non-existent, and making the corresponding (rather small) changes in the resource resolver code. As every Resource needs to go through the available ResourceDecorators, this is a simple way of making resources hideable based on feature flags. One then just needs to implement a ResourceDecorator that returns null when a Resource must be ignored. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (SLING-3267) ResourceDecorator returning null should cause Resources to be ignored
[ https://issues.apache.org/jira/browse/SLING-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841272#comment-13841272 ] Bertrand Delacretaz edited comment on SLING-3267 at 12/6/13 1:45 PM: - Here's my suggested patch where a null ResourceDecorator.decorate() return value causes a Resource to be ignored. All tests including the launchpad/testing tests pass with this patch. I think the IgnoredResourcesTest and ResourceIteratorDecoratorTest in the patch demonstrate the behavior described by [~justinedelson], a review of that is welcome. We can discuss on list whether using the ResourceDecorator to handle feature flags is appropriate, but in any case it might be good to clarify what ResourceDecorator.decorate returning null means, and fix our code so that it actually does what it should. One downside of the patch is that it breaks ResourceIteratorDecorator.remove - that method is not used in our full build and test suite, and that class is not exported so that's probably acceptable. was (Author: bdelacretaz): Here's my suggested patch where a null ResourceDecorator.decorate() return value causes a Resource to be ignored. All tests including the launchpad/testing tests pass with this patch. I think the IgnoredResourcesTest and ResourceIteratorDecoratorTest in the patch demonstrate the behavior described by [~justinedelson], a review of that is welcome. We can discuss on list whether using the ResourceDecorator to handle feature flags is appropriate, but in any case it might be good to clarify what ResourceDecorator.decorate returning null means, and fix our code so that it actually does what it should. ResourceDecorator returning null should cause Resources to be ignored - Key: SLING-3267 URL: https://issues.apache.org/jira/browse/SLING-3267 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.0.6 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Attachments: SLING-3267.patch The ResourceDecorator API's decorate(...) method javadocs currently specify that it can return null, but I don't think that's supported in a consistent way in the resource resolving process - returning null causes the resource resolver to supply a null Resource in some cases, which will probably cause NPEs downstream. The javadocs also say If the service does not want to decorate the resource, it should return the original resource which is consistent with how the resource resolver currently operates: returning null is clearly not a way of saying do not decorate this resource. As we're discussing feature flags in Sling, we could clarify this behavior by specifying that a ResourceDecorator returning null causes the resource to be considered as non-existent, and making the corresponding (rather small) changes in the resource resolver code. As every Resource needs to go through the available ResourceDecorators, this is a simple way of making resources hideable based on feature flags. One then just needs to implement a ResourceDecorator that returns null when a Resource must be ignored. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3267) ResourceDecorator returning null should cause Resources to be ignored
[ https://issues.apache.org/jira/browse/SLING-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841276#comment-13841276 ] Justin Edelson commented on SLING-3267: --- To be clear, my comment above was not about feature flags -- it was about the contract of ResourceDecorator and ResourceResolver. IIUC, the key point of this issue is that right now, the contract of ResourceDecorator is not met (returning a null resource is not interpreted the same as returning the original resource). ResourceDecorator returning null should cause Resources to be ignored - Key: SLING-3267 URL: https://issues.apache.org/jira/browse/SLING-3267 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.0.6 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Attachments: SLING-3267.patch The ResourceDecorator API's decorate(...) method javadocs currently specify that it can return null, but I don't think that's supported in a consistent way in the resource resolving process - returning null causes the resource resolver to supply a null Resource in some cases, which will probably cause NPEs downstream. The javadocs also say If the service does not want to decorate the resource, it should return the original resource which is consistent with how the resource resolver currently operates: returning null is clearly not a way of saying do not decorate this resource. As we're discussing feature flags in Sling, we could clarify this behavior by specifying that a ResourceDecorator returning null causes the resource to be considered as non-existent, and making the corresponding (rather small) changes in the resource resolver code. As every Resource needs to go through the available ResourceDecorators, this is a simple way of making resources hideable based on feature flags. One then just needs to implement a ResourceDecorator that returns null when a Resource must be ignored. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3267) ResourceDecorator returning null should cause Resources to be ignored
[
https://issues.apache.org/jira/browse/SLING-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841281#comment-13841281
]
Simone Tripodi commented on SLING-3267:
---
just my 0.002 cents: rather than changing the {{null}} semantic, it would
be easier if the {{ResourceIteratorDecorator}} could just skip Resources
which {{sling:resourceType}} is {{sling:nonexisting}}.
This should have less impact to all the existing stuff - WDYT?
ResourceDecorator returning null should cause Resources to be ignored
-
Key: SLING-3267
URL: https://issues.apache.org/jira/browse/SLING-3267
Project: Sling
Issue Type: Improvement
Components: ResourceResolver
Affects Versions: Resource Resolver 1.0.6
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
Priority: Minor
Attachments: SLING-3267.patch
The ResourceDecorator API's decorate(...) method javadocs currently specify
that it can return null, but I don't think that's supported in a consistent
way in the resource resolving process - returning null causes the resource
resolver to supply a null Resource in some cases, which will probably cause
NPEs downstream.
The javadocs also say If the service does not want to decorate the resource,
it should return the original resource which is consistent with how the
resource resolver currently operates: returning null is clearly not a way of
saying do not decorate this resource.
As we're discussing feature flags in Sling, we could clarify this behavior by
specifying that a ResourceDecorator returning null causes the resource to be
considered as non-existent, and making the corresponding (rather small)
changes in the resource resolver code.
As every Resource needs to go through the available ResourceDecorators, this
is a simple way of making resources hideable based on feature flags. One then
just needs to implement a ResourceDecorator that returns null when a Resource
must be ignored.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi Please don't mingle resource decoration with the feature flag. The use cases are different and returning null from the ResourceDecorator is clearly defined to be same as returning the same resource, i.e. no decoration at all. If this results in NPEs the calling code must be fixed. Feature flag is about optional hiding (or showing) resources. Decoration is about making the Resource appear differently. Also a ResourceDecorator does not solve the problem: Resource resolution effectively generates a (virtual) list of candidate resources and picks the first of this list to return. Adding feature flags to this actually may influence the selection from the list in that the first (or second or …) is ignored and the second (or third or …) is actually returned. Think back and forth I really think that we should put feature flag support into the ResourceResolver proper. I am opposed to changing API to implement a feature flag solution, which is not complete. Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 06.12.2013 um 11:48 schrieb Bertrand Delacretaz bdelacre...@apache.org: Hi, On Fri, Nov 15, 2013 at 8:40 AM, Felix Meschberger fmesc...@adobe.com wrote: 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... I had another look at this, and the existing ResourceDecorator already plays a similar role as an extension point to do something to each Resource while it's being resolved. That's already baked in the resource resolver, so we can leverage it without requiring much code changes. ResourceDecorator.decorate(Resource r) returning null is currently only vaguely specified and certainly not used, as that causes NPEs in places - I think we just need to clarify that decorate returning null causes a Resource to be ignored, fix the code so that it's true and we're good. I have created SLING-3267 to track that, I'll create a patch for review there. -Bertrand
RE: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
Hi I'm not sure if it is a good idea that a ResourceDecorator could return null. IMHO it's not what someone would expect from a Decorator. All the more that decorator is the name of a well known pattern, which would never be a null object (only a null object could be decorated but not vice versa). best regards mike -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] Sent: Friday, December 06, 2013 11:49 AM To: dev Subject: Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype) Hi, On Fri, Nov 15, 2013 at 8:40 AM, Felix Meschberger fmesc...@adobe.com wrote: 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... I had another look at this, and the existing ResourceDecorator already plays a similar role as an extension point to do something to each Resource while it's being resolved. That's already baked in the resource resolver, so we can leverage it without requiring much code changes. ResourceDecorator.decorate(Resource r) returning null is currently only vaguely specified and certainly not used, as that causes NPEs in places - I think we just need to clarify that decorate returning null causes a Resource to be ignored, fix the code so that it's true and we're good. I have created SLING-3267 to track that, I'll create a patch for review there. -Bertrand
FYI, request setup script prototype
Hi, From the funky prototypes department: I was talking to a colleague this week about how to minimize the amount of code in presentation templates, and we came up with the idea of having a setup script run at the beginning of the request processing, to prepare values, functions, iterators etc. for rendering scripts. I have created a prototype at https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/request-context - to play with it, install it, request http://localhost:8080/apps/requestcontext.html and see the commented scripts under /apps/requestcontext [2] Here's how this works: A Filter finds and executes the script that would process the same request as the current one if it had the setup extension, before the actual request processing takes place. In our example that's /apps/requestcontext/setup.ecma which contains things like rc.u.title = Here's the title for + rc.path + , computed at + new Date(); The rc object is our request context, that provides easy access to standard (rc.name) and freely defined user values (rc.u.name). You can then use the rc object in the rendering script, which in this case would contain just h1%= rc.u.title %/h1 but the title building logic is neatly separated in its own script, reusable, doesn't pollute rendering etc. This might be especially useful in the context of templating languages like Sightly [1] that want to avoid code in rendering templates. The setup script can also play the role of a mini-controller, as it can redirect, fail or forward the current request. My prototype doesn't require any changes to the Sling code, so we can very keep that as an experimental extension for now, if we want to move it out of the whiteboard. Feedback is welcome as usual. -Bertrand [1] http://www.pro-vision.de/content/medialib/pro-vision/production/adaptto/2013/adaptto2013-sightly-gabriel-walt-honwai-wong-senol-tas-pdf/_jcr_content/renditions/rendition.file/adaptto2013-sightly-gabriel-walt-honwai-wong-senol-tas.pdf [2] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/request-context/src/main/resources/SLING-CONTENT/apps/requestcontext
[jira] [Commented] (SLING-3267) ResourceDecorator returning null should cause Resources to be ignored
[ https://issues.apache.org/jira/browse/SLING-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841404#comment-13841404 ] Simone Tripodi commented on SLING-3267: --- bq, NonExistingResources are still Resources. Sounds a little philosophical - but since I've missed some years of Sling history, I'll let up to you decide which is the best design. But please take in consideration that ATM I cannot correctly implement my extension because of that limitation :) ResourceDecorator returning null should cause Resources to be ignored - Key: SLING-3267 URL: https://issues.apache.org/jira/browse/SLING-3267 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.0.6 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Attachments: SLING-3267.patch The ResourceDecorator API's decorate(...) method javadocs currently specify that it can return null, but I don't think that's supported in a consistent way in the resource resolving process - returning null causes the resource resolver to supply a null Resource in some cases, which will probably cause NPEs downstream. The javadocs also say If the service does not want to decorate the resource, it should return the original resource which is consistent with how the resource resolver currently operates: returning null is clearly not a way of saying do not decorate this resource. As we're discussing feature flags in Sling, we could clarify this behavior by specifying that a ResourceDecorator returning null causes the resource to be considered as non-existent, and making the corresponding (rather small) changes in the resource resolver code. As every Resource needs to go through the available ResourceDecorators, this is a simple way of making resources hideable based on feature flags. One then just needs to implement a ResourceDecorator that returns null when a Resource must be ignored. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (SLING-3267) ResourceDecorator returning null should cause Resources to be ignored
[ https://issues.apache.org/jira/browse/SLING-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841404#comment-13841404 ] Simone Tripodi edited comment on SLING-3267 at 12/6/13 4:46 PM: bq. NonExistingResources are still Resources. Sounds a little philosophical - but since I've missed some years of Sling history, I'll let up to you decide which is the best design. But please take in consideration that ATM I cannot correctly implement my extension because of that limitation :) was (Author: simone.tripodi): bq, NonExistingResources are still Resources. Sounds a little philosophical - but since I've missed some years of Sling history, I'll let up to you decide which is the best design. But please take in consideration that ATM I cannot correctly implement my extension because of that limitation :) ResourceDecorator returning null should cause Resources to be ignored - Key: SLING-3267 URL: https://issues.apache.org/jira/browse/SLING-3267 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.0.6 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Attachments: SLING-3267.patch The ResourceDecorator API's decorate(...) method javadocs currently specify that it can return null, but I don't think that's supported in a consistent way in the resource resolving process - returning null causes the resource resolver to supply a null Resource in some cases, which will probably cause NPEs downstream. The javadocs also say If the service does not want to decorate the resource, it should return the original resource which is consistent with how the resource resolver currently operates: returning null is clearly not a way of saying do not decorate this resource. As we're discussing feature flags in Sling, we could clarify this behavior by specifying that a ResourceDecorator returning null causes the resource to be considered as non-existent, and making the corresponding (rather small) changes in the resource resolver code. As every Resource needs to go through the available ResourceDecorators, this is a simple way of making resources hideable based on feature flags. One then just needs to implement a ResourceDecorator that returns null when a Resource must be ignored. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: FYI, request setup script prototype
Hi Bertrand, This looks a bit too magical to me :) All you're avoiding is a single include line, right? Or am I missing something? You could also do the same thing (more or less) with a BindingsValuesProvider. Justin On Fri, Dec 6, 2013 at 11:40 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, From the funky prototypes department: I was talking to a colleague this week about how to minimize the amount of code in presentation templates, and we came up with the idea of having a setup script run at the beginning of the request processing, to prepare values, functions, iterators etc. for rendering scripts. I have created a prototype at https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/request-context - to play with it, install it, request http://localhost:8080/apps/requestcontext.html and see the commented scripts under /apps/requestcontext [2] Here's how this works: A Filter finds and executes the script that would process the same request as the current one if it had the setup extension, before the actual request processing takes place. In our example that's /apps/requestcontext/setup.ecma which contains things like rc.u.title = Here's the title for + rc.path + , computed at + new Date(); The rc object is our request context, that provides easy access to standard (rc.name) and freely defined user values (rc.u.name). You can then use the rc object in the rendering script, which in this case would contain just h1%= rc.u.title %/h1 but the title building logic is neatly separated in its own script, reusable, doesn't pollute rendering etc. This might be especially useful in the context of templating languages like Sightly [1] that want to avoid code in rendering templates. The setup script can also play the role of a mini-controller, as it can redirect, fail or forward the current request. My prototype doesn't require any changes to the Sling code, so we can very keep that as an experimental extension for now, if we want to move it out of the whiteboard. Feedback is welcome as usual. -Bertrand [1] http://www.pro-vision.de/content/medialib/pro-vision/production/adaptto/2013/adaptto2013-sightly-gabriel-walt-honwai-wong-senol-tas-pdf/_jcr_content/renditions/rendition.file/adaptto2013-sightly-gabriel-walt-honwai-wong-senol-tas.pdf [2] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/request-context/src/main/resources/SLING-CONTENT/apps/requestcontext
[jira] [Commented] (SLING-3267) ResourceDecorator returning null should cause Resources to be ignored
[ https://issues.apache.org/jira/browse/SLING-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841435#comment-13841435 ] Justin Edelson commented on SLING-3267: --- bq. But please take in consideration that ATM I cannot correctly implement my extension because of that limitation Assuming your extension is feature flags, I think this is a non-issue. I agree with Felix that ResourceDecorators are not the right way to implement those. But that's not really the point of this issue. FWIW, it would make sense to do the filtering you describe for findResources() and queryResources() (as I said above, a NonExistingResource by definition cannot match a query). But it doesn't sound right to implement this as a general rule. ResourceDecorator returning null should cause Resources to be ignored - Key: SLING-3267 URL: https://issues.apache.org/jira/browse/SLING-3267 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.0.6 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Attachments: SLING-3267.patch The ResourceDecorator API's decorate(...) method javadocs currently specify that it can return null, but I don't think that's supported in a consistent way in the resource resolving process - returning null causes the resource resolver to supply a null Resource in some cases, which will probably cause NPEs downstream. The javadocs also say If the service does not want to decorate the resource, it should return the original resource which is consistent with how the resource resolver currently operates: returning null is clearly not a way of saying do not decorate this resource. As we're discussing feature flags in Sling, we could clarify this behavior by specifying that a ResourceDecorator returning null causes the resource to be considered as non-existent, and making the corresponding (rather small) changes in the resource resolver code. As every Resource needs to go through the available ResourceDecorators, this is a simple way of making resources hideable based on feature flags. One then just needs to implement a ResourceDecorator that returns null when a Resource must be ignored. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
On 06.12.2013, at 08:08, Felix Meschberger fmesc...@adobe.com wrote: Think back and forth I really think that we should put feature flag support into the ResourceResolver proper. I agree. Another completely open question is: the resource resolver is not tied to a request, backend services use it as well. So if the feature flag is driven by the request, how do you handle that for those service resolvers? AFAIU, the two major cases for feature flags are a) user dependent and b) global on/off. But in both cases it can depend on the application whether those services have to fall under the flags or not. For example, you might have an observation going on that does something advanced (*). Should it run even if it's feature is off (as nobody will use the results as long as the feature is off)? Or should it be totally disabled? This is a question often only the application can decide. Say the service resolvers are using admin sessions or some service users, then you could turn it on/off based on them - to be in line with user-based request resolvers in case a). But it could also be that you have flag a where you must handle it in application code and don't want it handled in the resolver already. Thus you either make it configurable on the flag itself what impact it has or you actually ask for a resource resolver with special feature flags in the first place (or not, getting a standard one). Also, I mentioned observation: it's a JCR level thing that wouldn't be affected by Sling resource resolver feature flags. Just thinking out loud here, not sure what the cleanest approach would be... Cheers, Alex
Re: FYI, request setup script prototype
Actually, I've been batting this around in my head for awhile. Make it possible to create BindingsValuesProviders which are constrained by resource type. And a simple service for getting the various default Sling properties from the existing bindings. Does that make sense? Then you could just bind one of these providers to any number of resource types and retrieve the bound objects in your scripts as per usual. -Dan On Fri, Dec 6, 2013 at 11:48 AM, Justin Edelson jus...@justinedelson.comwrote: Hi Bertrand, This looks a bit too magical to me :) All you're avoiding is a single include line, right? Or am I missing something? You could also do the same thing (more or less) with a BindingsValuesProvider. Justin On Fri, Dec 6, 2013 at 11:40 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, From the funky prototypes department: I was talking to a colleague this week about how to minimize the amount of code in presentation templates, and we came up with the idea of having a setup script run at the beginning of the request processing, to prepare values, functions, iterators etc. for rendering scripts. I have created a prototype at https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/request-context - to play with it, install it, request http://localhost:8080/apps/requestcontext.html and see the commented scripts under /apps/requestcontext [2] Here's how this works: A Filter finds and executes the script that would process the same request as the current one if it had the setup extension, before the actual request processing takes place. In our example that's /apps/requestcontext/setup.ecma which contains things like rc.u.title = Here's the title for + rc.path + , computed at + new Date(); The rc object is our request context, that provides easy access to standard (rc.name) and freely defined user values (rc.u.name). You can then use the rc object in the rendering script, which in this case would contain just h1%= rc.u.title %/h1 but the title building logic is neatly separated in its own script, reusable, doesn't pollute rendering etc. This might be especially useful in the context of templating languages like Sightly [1] that want to avoid code in rendering templates. The setup script can also play the role of a mini-controller, as it can redirect, fail or forward the current request. My prototype doesn't require any changes to the Sling code, so we can very keep that as an experimental extension for now, if we want to move it out of the whiteboard. Feedback is welcome as usual. -Bertrand [1] http://www.pro-vision.de/content/medialib/pro-vision/production/adaptto/2013/adaptto2013-sightly-gabriel-walt-honwai-wong-senol-tas-pdf/_jcr_content/renditions/rendition.file/adaptto2013-sightly-gabriel-walt-honwai-wong-senol-tas.pdf [2] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/request-context/src/main/resources/SLING-CONTENT/apps/requestcontext
[jira] [Commented] (SLING-3267) ResourceDecorator returning null should cause Resources to be ignored
[ https://issues.apache.org/jira/browse/SLING-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841445#comment-13841445 ] Simone Tripodi commented on SLING-3267: --- bq. ResourceDecorators are not the right way to implement those. ok, it is clear now how to NOT doing it, my main issue now is (that'\s anyway another story): how to correctly do it just touching Sling APIs without the need to modify the Sling core? :) ResourceDecorator returning null should cause Resources to be ignored - Key: SLING-3267 URL: https://issues.apache.org/jira/browse/SLING-3267 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.0.6 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Attachments: SLING-3267.patch The ResourceDecorator API's decorate(...) method javadocs currently specify that it can return null, but I don't think that's supported in a consistent way in the resource resolving process - returning null causes the resource resolver to supply a null Resource in some cases, which will probably cause NPEs downstream. The javadocs also say If the service does not want to decorate the resource, it should return the original resource which is consistent with how the resource resolver currently operates: returning null is clearly not a way of saying do not decorate this resource. As we're discussing feature flags in Sling, we could clarify this behavior by specifying that a ResourceDecorator returning null causes the resource to be considered as non-existent, and making the corresponding (rather small) changes in the resource resolver code. As every Resource needs to go through the available ResourceDecorators, this is a simple way of making resources hideable based on feature flags. One then just needs to implement a ResourceDecorator that returns null when a Resource must be ignored. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: FYI, request setup script prototype
Right. Sightly has the concept of a Use class (*). It is triggered from the template using a certain command/include. This use class can be either a) next to the script in the resource type folder (using the Java script engine if it's in Java, I think it could also be written in Javascript, in which case it uses the Javascript scrip engine) b) or it can be in a osgi bundle with the right package name (based on the rt) c) or it can be in a osgi bundle at any place (when addressed by fully qualified class name) It has to extend a base class that will get the basic sling request information. But this can also be an extended base class that includes more: say in a CMS on top of Sling, there would be CMS specific base class that provides more context than the plain Sling stuff. The important part in this excercise is that it can be resource type based a) (specific logic just for the templates of that rt), but also easily shared among multiple resource types (c). Also, with super resource types things you want to be sure the correct use class is being used. So while I think it could be nice to have this happen more generically as part of the resource type execution, you need some place to specify that use class or request context helper. If we take it out of the template, where should it go? You could put it into the rt folder as e.g. jcr property - but what if different templates in the same rt want to use a different one? (Maybe that's something to avoid and we force it to be shared among all the templates within one rt). (*) like a bean, but wanted to avoid confusion of that name, so because the templates uses it, it's called that way) Cheers, Alex On 06.12.2013, at 08:48, Justin Edelson jus...@justinedelson.com wrote: Hi Bertrand, This looks a bit too magical to me :) All you're avoiding is a single include line, right? Or am I missing something? You could also do the same thing (more or less) with a BindingsValuesProvider. Justin On Fri, Dec 6, 2013 at 11:40 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, From the funky prototypes department: I was talking to a colleague this week about how to minimize the amount of code in presentation templates, and we came up with the idea of having a setup script run at the beginning of the request processing, to prepare values, functions, iterators etc. for rendering scripts. I have created a prototype at https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/request-context - to play with it, install it, request http://localhost:8080/apps/requestcontext.html and see the commented scripts under /apps/requestcontext [2] Here's how this works: A Filter finds and executes the script that would process the same request as the current one if it had the setup extension, before the actual request processing takes place. In our example that's /apps/requestcontext/setup.ecma which contains things like rc.u.title = Here's the title for + rc.path + , computed at + new Date(); The rc object is our request context, that provides easy access to standard (rc.name) and freely defined user values (rc.u.name). You can then use the rc object in the rendering script, which in this case would contain just h1%= rc.u.title %/h1 but the title building logic is neatly separated in its own script, reusable, doesn't pollute rendering etc. This might be especially useful in the context of templating languages like Sightly [1] that want to avoid code in rendering templates. The setup script can also play the role of a mini-controller, as it can redirect, fail or forward the current request. My prototype doesn't require any changes to the Sling code, so we can very keep that as an experimental extension for now, if we want to move it out of the whiteboard. Feedback is welcome as usual. -Bertrand [1] http://www.pro-vision.de/content/medialib/pro-vision/production/adaptto/2013/adaptto2013-sightly-gabriel-walt-honwai-wong-senol-tas-pdf/_jcr_content/renditions/rendition.file/adaptto2013-sightly-gabriel-walt-honwai-wong-senol-tas.pdf [2] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/request-context/src/main/resources/SLING-CONTENT/apps/requestcontext
Re: FYI, request setup script prototype
Hi Dan, Conceptually this makes sense to me. Obviously you can do that check inside the BVP, but moving it to a more declarative model would I'm sure be useful. One thing to think about is resource type inhiertance. I assume we would want BVPs to be inherited. Justin On Fri, Dec 6, 2013 at 12:11 PM, Daniel Klco daniel.k...@gmail.com wrote: Actually, I've been batting this around in my head for awhile. Make it possible to create BindingsValuesProviders which are constrained by resource type. And a simple service for getting the various default Sling properties from the existing bindings. Does that make sense? Then you could just bind one of these providers to any number of resource types and retrieve the bound objects in your scripts as per usual. -Dan On Fri, Dec 6, 2013 at 11:48 AM, Justin Edelson jus...@justinedelson.comwrote: Hi Bertrand, This looks a bit too magical to me :) All you're avoiding is a single include line, right? Or am I missing something? You could also do the same thing (more or less) with a BindingsValuesProvider. Justin On Fri, Dec 6, 2013 at 11:40 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, From the funky prototypes department: I was talking to a colleague this week about how to minimize the amount of code in presentation templates, and we came up with the idea of having a setup script run at the beginning of the request processing, to prepare values, functions, iterators etc. for rendering scripts. I have created a prototype at https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/request-context - to play with it, install it, request http://localhost:8080/apps/requestcontext.html and see the commented scripts under /apps/requestcontext [2] Here's how this works: A Filter finds and executes the script that would process the same request as the current one if it had the setup extension, before the actual request processing takes place. In our example that's /apps/requestcontext/setup.ecma which contains things like rc.u.title = Here's the title for + rc.path + , computed at + new Date(); The rc object is our request context, that provides easy access to standard (rc.name) and freely defined user values (rc.u.name). You can then use the rc object in the rendering script, which in this case would contain just h1%= rc.u.title %/h1 but the title building logic is neatly separated in its own script, reusable, doesn't pollute rendering etc. This might be especially useful in the context of templating languages like Sightly [1] that want to avoid code in rendering templates. The setup script can also play the role of a mini-controller, as it can redirect, fail or forward the current request. My prototype doesn't require any changes to the Sling code, so we can very keep that as an experimental extension for now, if we want to move it out of the whiteboard. Feedback is welcome as usual. -Bertrand [1] http://www.pro-vision.de/content/medialib/pro-vision/production/adaptto/2013/adaptto2013-sightly-gabriel-walt-honwai-wong-senol-tas-pdf/_jcr_content/renditions/rendition.file/adaptto2013-sightly-gabriel-walt-honwai-wong-senol-tas.pdf [2] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/request-context/src/main/resources/SLING-CONTENT/apps/requestcontext
Re: FYI, request setup script prototype
Hi Alex, One minor point - IIUC, the Use directive defines have a specific scope *within* a Sightly template. In this regard, they are slightly different than what Bertrand is doing or what a BVP does which operate around the template as a whole. To me, a Use class is more like an AngularJS controller, the 'with' keyword in JavaScript, the 'use' keyword in Groovy, or Droplet oparams. Regards, Justin On Fri, Dec 6, 2013 at 12:25 PM, Alexander Klimetschek aklim...@adobe.com wrote: Right. Sightly has the concept of a Use class (*). It is triggered from the template using a certain command/include. This use class can be either a) next to the script in the resource type folder (using the Java script engine if it's in Java, I think it could also be written in Javascript, in which case it uses the Javascript scrip engine) b) or it can be in a osgi bundle with the right package name (based on the rt) c) or it can be in a osgi bundle at any place (when addressed by fully qualified class name) It has to extend a base class that will get the basic sling request information. But this can also be an extended base class that includes more: say in a CMS on top of Sling, there would be CMS specific base class that provides more context than the plain Sling stuff. The important part in this excercise is that it can be resource type based a) (specific logic just for the templates of that rt), but also easily shared among multiple resource types (c). Also, with super resource types things you want to be sure the correct use class is being used. So while I think it could be nice to have this happen more generically as part of the resource type execution, you need some place to specify that use class or request context helper. If we take it out of the template, where should it go? You could put it into the rt folder as e.g. jcr property - but what if different templates in the same rt want to use a different one? (Maybe that's something to avoid and we force it to be shared among all the templates within one rt). (*) like a bean, but wanted to avoid confusion of that name, so because the templates uses it, it's called that way) Cheers, Alex On 06.12.2013, at 08:48, Justin Edelson jus...@justinedelson.com wrote: Hi Bertrand, This looks a bit too magical to me :) All you're avoiding is a single include line, right? Or am I missing something? You could also do the same thing (more or less) with a BindingsValuesProvider. Justin On Fri, Dec 6, 2013 at 11:40 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, From the funky prototypes department: I was talking to a colleague this week about how to minimize the amount of code in presentation templates, and we came up with the idea of having a setup script run at the beginning of the request processing, to prepare values, functions, iterators etc. for rendering scripts. I have created a prototype at https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/request-context - to play with it, install it, request http://localhost:8080/apps/requestcontext.html and see the commented scripts under /apps/requestcontext [2] Here's how this works: A Filter finds and executes the script that would process the same request as the current one if it had the setup extension, before the actual request processing takes place. In our example that's /apps/requestcontext/setup.ecma which contains things like rc.u.title = Here's the title for + rc.path + , computed at + new Date(); The rc object is our request context, that provides easy access to standard (rc.name) and freely defined user values (rc.u.name). You can then use the rc object in the rendering script, which in this case would contain just h1%= rc.u.title %/h1 but the title building logic is neatly separated in its own script, reusable, doesn't pollute rendering etc. This might be especially useful in the context of templating languages like Sightly [1] that want to avoid code in rendering templates. The setup script can also play the role of a mini-controller, as it can redirect, fail or forward the current request. My prototype doesn't require any changes to the Sling code, so we can very keep that as an experimental extension for now, if we want to move it out of the whiteboard. Feedback is welcome as usual. -Bertrand [1] http://www.pro-vision.de/content/medialib/pro-vision/production/adaptto/2013/adaptto2013-sightly-gabriel-walt-honwai-wong-senol-tas-pdf/_jcr_content/renditions/rendition.file/adaptto2013-sightly-gabriel-walt-honwai-wong-senol-tas.pdf [2] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/request-context/src/main/resources/SLING-CONTENT/apps/requestcontext
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
On Fri, Dec 6, 2013 at 12:10 PM, Alexander Klimetschek aklim...@adobe.com wrote: On 06.12.2013, at 08:08, Felix Meschberger fmesc...@adobe.com wrote: Think back and forth I really think that we should put feature flag support into the ResourceResolver proper. I agree. +1 Henry wrote it well: So, fundamentally all that the framework can do is provide a way to define flags, provide a switch panel and a way to extend it, and API to check flags in condition statements. How and where each flag is used is up to the developer of a specific application feature. The ResourceResolver is such an application feature which needs to be enhanced to support feature flags. We probably have some others in Sling as well. Regards, Justin Another completely open question is: the resource resolver is not tied to a request, backend services use it as well. So if the feature flag is driven by the request, how do you handle that for those service resolvers? AFAIU, the two major cases for feature flags are a) user dependent and b) global on/off. But in both cases it can depend on the application whether those services have to fall under the flags or not. For example, you might have an observation going on that does something advanced (*). Should it run even if it's feature is off (as nobody will use the results as long as the feature is off)? Or should it be totally disabled? This is a question often only the application can decide. Say the service resolvers are using admin sessions or some service users, then you could turn it on/off based on them - to be in line with user-based request resolvers in case a). But it could also be that you have flag a where you must handle it in application code and don't want it handled in the resolver already. Thus you either make it configurable on the flag itself what impact it has or you actually ask for a resource resolver with special feature flags in the first place (or not, getting a standard one). Also, I mentioned observation: it's a JCR level thing that wouldn't be affected by Sling resource resolver feature flags. Just thinking out loud here, not sure what the cleanest approach would be... Cheers, Alex
Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)
it may be worth it revisiting the tenant api in regards to feature flags as well and have some sort of way to have feature flag dependent osgi properties. Ruben On 12/6/2013 12:51 PM, Justin Edelson wrote: On Fri, Dec 6, 2013 at 12:10 PM, Alexander Klimetschek aklim...@adobe.com wrote: On 06.12.2013, at 08:08, Felix Meschberger fmesc...@adobe.com wrote: Think back and forth I really think that we should put feature flag support into the ResourceResolver proper. I agree. +1 Henry wrote it well: So, fundamentally all that the framework can do is provide a way to define flags, provide a switch panel and a way to extend it, and API to check flags in condition statements. How and where each flag is used is up to the developer of a specific application feature. The ResourceResolver is such an application feature which needs to be enhanced to support feature flags. We probably have some others in Sling as well. Regards, Justin Another completely open question is: the resource resolver is not tied to a request, backend services use it as well. So if the feature flag is driven by the request, how do you handle that for those service resolvers? AFAIU, the two major cases for feature flags are a) user dependent and b) global on/off. But in both cases it can depend on the application whether those services have to fall under the flags or not. For example, you might have an observation going on that does something advanced (*). Should it run even if it's feature is off (as nobody will use the results as long as the feature is off)? Or should it be totally disabled? This is a question often only the application can decide. Say the service resolvers are using admin sessions or some service users, then you could turn it on/off based on them - to be in line with user-based request resolvers in case a). But it could also be that you have flag a where you must handle it in application code and don't want it handled in the resolver already. Thus you either make it configurable on the flag itself what impact it has or you actually ask for a resource resolver with special feature flags in the first place (or not, getting a standard one). Also, I mentioned observation: it's a JCR level thing that wouldn't be affected by Sling resource resolver feature flags. Just thinking out loud here, not sure what the cleanest approach would be... Cheers, Alex
Build failed in Jenkins: sling-trunk-1.6 #2052
See https://builds.apache.org/job/sling-trunk-1.6/2052/changes Changes: [bdelacretaz] SLING-3267 - add tests that clarify the current behavior -- [...truncated 6428 lines...] [INFO] Compiling 53 source files to https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/engine/target/classes [INFO] [INFO] --- maven-scr-plugin:1.14.0:scr (generate-scr-scrdescriptor) @ org.apache.sling.engine --- [WARNING] https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/debug/RequestProgressTrackerLogFilter.java [0:0]: Property filter.scope in class org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter is set as private. This is redundant as no metatype will be generated. [INFO] Generating 1 MetaType Descriptors in https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/engine/target/scr-plugin-generated/OSGI-INF/metatype/org.apache.sling.engine.impl.log.RequestLoggerService.xml [INFO] Generating 1 MetaType Descriptors in https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/engine/target/scr-plugin-generated/OSGI-INF/metatype/org.apache.sling.engine.impl.log.RequestLogger.xml [INFO] Generating 1 MetaType Descriptors in https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/engine/target/scr-plugin-generated/OSGI-INF/metatype/org.apache.sling.engine.impl.SlingMainServlet.xml [INFO] Writing 1 Service Component Descriptors to https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/engine/target/scr-plugin-generated/OSGI-INF/org.apache.sling.engine.impl.log.RequestLoggerService.xml [INFO] Writing 1 Service Component Descriptors to https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/engine/target/scr-plugin-generated/OSGI-INF/org.apache.sling.engine.impl.log.RequestLogger.xml [INFO] Writing 1 Service Component Descriptors to https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/engine/target/scr-plugin-generated/OSGI-INF/org.apache.sling.engine.impl.log.RequestLoggerFilter.xml [INFO] Writing 1 Service Component Descriptors to https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/engine/target/scr-plugin-generated/OSGI-INF/org.apache.sling.engine.impl.SlingSettingsServiceImpl.xml [INFO] Writing 1 Service Component Descriptors to https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/engine/target/scr-plugin-generated/OSGI-INF/org.apache.sling.engine.impl.SlingMainServlet.xml [INFO] Writing 1 Service Component Descriptors to https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/engine/target/scr-plugin-generated/OSGI-INF/org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.xml [INFO] [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ org.apache.sling.engine --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 3 resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ org.apache.sling.engine --- [INFO] Compiling 10 source files to https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/engine/target/test-classes [INFO] [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ org.apache.sling.engine --- [INFO] Surefire report directory: https://builds.apache.org/job/sling-trunk-1.6/ws/trunk/bundles/engine/target/surefire-reports --- T E S T S --- Running org.apache.sling.engine.ResponseUtilTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec Running org.apache.sling.engine.impl.RequestProcessorMBeanImplTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.243 sec Running org.apache.sling.engine.impl.helper.ExternalServletContextWrapperTest Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.082 sec Running org.apache.sling.engine.impl.log.CustomLogFormatTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec Running org.apache.sling.engine.impl.request.SlingRequestPathInfoTest Tests run: 24, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec Running org.apache.sling.engine.impl.parameters.UtilTest Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.067 sec Running org.apache.sling.engine.impl.parameters.ContainerRequestParameterTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec Results : Tests run: 50, Failures: 0, Errors: 0, Skipped: 0 [JENKINS] Recording test results [INFO] [INFO] --- animal-sniffer-maven-plugin:1.9:check (default) @ org.apache.sling.engine --- [INFO] Checking unresolved references to org.codehaus.mojo.signature:java15:1.0 [INFO] [INFO] --- maven-bundle-plugin:2.4.0:bundle (default-bundle) @ org.apache.sling.engine --- [WARNING] Bundle org.apache.sling:org.apache.sling.engine:bundle:2.2.11-SNAPSHOT : Unused
