Hi Nicolas Do you think it would be possible to "apply" a Sling pipes execution only via a decorator until after the blue/green deployment is completed. And only after that lazily "apply" the pipes execution to the persisted content?
That's what I read into your initial email, and that would IMHO be more desirable than re-defining the same changes in a different way. Or maybe my misunderstanding is on a more fundamental level? Regards Julian On Mon, Mar 28, 2022 at 5:23 PM Nicolas Peltier <[email protected]> wrote: > > Hi, > > so there are two levels to it: > > 1. how ultimately we decorate things up given a configured set of content > hacks. I guess that decorator [2] plus yes something like [1] can help. Not > sure how bad impact on performances would be though > 2. how we configure those content hacks. I was initially thinking about > annotations & headers, but i wonder if some tree of CA configurations would > not be better, as it would fix already a lot of context specific questions. > It would also allow to add/remove the hack by changing something more > contentish than java code. > > Throwing this here to see if there is any more reaction from the community, > and will soon start to work on a whiteboard draft. > > [2] > https://sling.apache.org/documentation/the-sling-engine/wrap-or-decorate-resources.html > > > Le jeu. 10 mars 2022 à 14:33, Julian Sedding <[email protected]> a écrit : > > > Hi Nicolas > > > > If you want to go with a decoration approach (whether it is via a > > resource provider or decorator), a few classes I put into the > > whiteboard a while ago might help [1]. I once used them to "mount" > > repetitive and/or dynamic parts of AEM dialog definitions into a > > static AEM dialog definition. > > > > Regards > > Julian > > > > [1] > > https://github.com/apache/sling-whiteboard/tree/feature/sling-resource-graft > > > > On Thu, Mar 10, 2022 at 10:55 AM Konrad Windszus <[email protected]> wrote: > > > > > > Hi Nicolas, anything which eases the process of content migration for > > blue/green deployments will be highly appreciated. Hiding the differences > > on the resource level sounds like a good idea although you probably have to > > distinguish between read/write access. Looking forward to your proposal. > > > Konrad > > > > > > > Am 10.03.2022 um 10:51 schrieb Nicolas Peltier < > > [email protected]>: > > > > > > > > Hey, > > > > > > > > i've been discussing here & there several times about having sling > > pipes in > > > > a CI/CD pipeline as part of a new application deployment where content > > > > handling changed substantially and application v(n+1) can't work with > > > > content v(n). > > > > pipes responsibility would be to handle the switch of content to > > v(n+1). > > > > > > > > thinking/discussing about it, it does not sound right to me if there > > is no > > > > possibility to serve 2 versions of the content at the same time and to > > > > quickly validate that everything is correct, as it ends up being non > > > > validated code (pipe on specific prod content is new). > > > > > > > > The other alternative is to have code handling both versions of the > > > > content, when no occurrence of the v(n) content is there anymore > > (which can > > > > be done by code, or accelerated eventually sling pipe execution), > > switch to > > > > a simpler version. To make that approach less expensive, i was thinking > > > > about something at sling level (resource provider and decorator) that > > would > > > > help doing those things quicker, through some annotations. > > > > > > > > Any thoughts / feedbacks / concerns before i dig deeper ? > > > > > > > > Nicolas > > > > >
