We are experiencing issues with Sightly components in a custom solution after upgrading to AEM 6.2. We can reproduce the issue on a clean AEM 6.2 server (not upgraded). Unfortunately there are no error messages so we do not have much to go on... I am describing here in case someone has encountered this previously and has some tips to resolve or debug.
I'll describe the non-upgraded path to reproduce...
We installed AEM 6.2 quickstart (author). Then deployed the we.retail sample package. Everything is working correctly and the sightly components can be configured and new ones added from the TouchUI author environment.
Then we install our custom solution which includes 25-30 sightly components. This breaks ALL sightly components in AEM. Not only do they not work in the custom package but the components from we.retail sample cease to appear in the components selection widget and it seems components cannot be reliably configured.
Through trial and error we identified 7 components that if removed from our package allow the remaining sightly components to work correctly. However, it is difficult to identify the common ground between these 7 components at a glance.
I was thinking maybe a client-lib or overlay of a base component might be the root cause but that doesn't seem to be clearly the case.
We are continuing to debug (difficult with sightly components) but I wanted to ask this in case someone has information which might help.
For starters -- the class WCMUse Java class is deprecated, You need to rebuild with WCMUSePojo. There are also new dependencies on AEM 6.2. Notably this dependency is required in AEM 6.2:
To learn how to build an AEM 6.2 HTL (Sightly renamed to HTL) - see this article:
Hope this helps point you in the correct direction.
Thanks for the response.
I had already corrected dependency issues, replaced deprecated WCMUse class, etc. That all went well.
The issue was finally resolved after root cause was traced to TooManyCallsExceptions...
The TooManyCallsException is thrown by the Sling implementation if too many inclusions have been called for during a single request.
This setting can be configured from the Sling Main Servlet configuration under Felix console. http://<host>:<port>/system/console/configMgr/org.apache.sling.engine.impl.SlingMainServlet
The property "Number of Calls per Request (sling.max.calls)", by default has 1000 value.
We increased this value to 2000 and the issue goes away.
Since this seems to only happen during authoring when AEM is trying to load the available sling components into the component widget I'm not sure there is actually anything wrong with the components. Perhaps something changed between AEM 6.0 and 6.2 with respect to how AEM renders the list of available components?
This is excellent information- i have never heard of this.
I am going to see if we have a KB that talks about this issue - thank you for the information!!! Power of the community.