If have a (reasonably ) finite number of inputs producing a (reasonably) finite number of permutations of JSON - you could also look at using HTTP Cache [1] to cache the entire JSON output in AEM memory and serve it from there. [1] https://adobe-consulting-services.github.io/acs-aem-commons/features...

Did you add those paths to your filter.xml? and make sur that the merge modes make sense based on what content you might have at those filter paths?

Well - they are, theyre just in the wrong package (for AEM as a Cloud Service) .. theyre in the ui.apps package.I assume you have your own ui.content package (thats a sibling to your all pacakge)? Just add them in there...  You can copy them from here:https://github.com/Adobe-Marketing-Cloud/asset-s...

Make a package of those from local and install on Cloud and see if it works. I dont think that should break the functionality you said it broken though. After packaging them up - you could also try to removing them from SDK to see if you can reproduce the breaking behavior that way.

SDI expects the output to be HTML.Sling Model Exporter implies the output is JSON. What exactly are you trying to do? Are you trying to stitch together a JSON response, where parts are static and other parts dynamic? If that's the case SDI doesn't support this - and TBH, I'm not sure if Apache webse...

Sorry - what pages do you mean exactly? Also, do you mean JavaScript or HTL/JSP scripts?

UPDATE: i misread this error (thought you were referencing the impl class, but really it looks like the HTL cannot instantiate the Sling Model via the interface reference (which is bound to that Impl). See Arun's answer below. You are trying to access an INTERNAL class as denoted by the "internal" p...

@Adilmo i dont recommend trying to surface anything other dam:Asset nodes with Asset Share Commons. There is *alot* of plumbing of that assumes results themselves as well as the "target" of results (when you click on a result, what you're taken to) is a dam:Asset. Many, many, many things will break ...

This looks correct (though i'd probably scope the /apps/<MY-APP>-packages/application/install and /apps/<MY-APP>-packages/content/install just to align w/ common convention. Assuming the search itself actually works, that means the Bundle is active, etc. - which is a great sign. If search doesnt wor...

Have you tried using AEM Mock's AemContext to create mock sling request context? I highly, highly recommend using AEM Mocks when possible rather than mocking out everything yourself. These sorts of problems should go away, and also lets you write more natural tests. https://wcm.io/testing/aem-mock/u...