Hi all,
Our company is developing the first AEM project with the AEM 6.3 version of Adobe Experience Manager. We created our project based on the Maven archetype version 12.
We encounter a problem on our test machine. We deploy the project on both author and publish instances via a Jenkins job (that just calls maven mvn -PautoInstallPackage clean install (on author) and mvn -PautoInstallPackagePublish clean install on the publish instance.
In the author instance everything looks fine, content can be configured, visualised in preview mode correctly.
On the publish instance the header component which is part of an editable template disappears, and content is not correctly displayed.
Is there an additional step, like clearing some caches or similar that we have to execute after a deploy, so that the content on the publish instance is displayed correctly?
What we found till now after a small research is just to recompile the jsps on the publish instance:
http://<HOSTNAME>:4503/system/console/slingjsp?reset and there 'Recompile all JSPs' option is used.
This solves the problem in the browser where it is executed, but it needs a login in the backend of AEM and it does not fix it for every browser.
So this is not a viable solution. This problem currently complicates a lot the testing of the project on many physical devices, (as we are still in the development phase of the project).
Could you please advise what can we do in order to visualise correctly the content in all browsers / devices also on the publish instance?
Thank you,
Sergiu
Solved! Go to Solution.
Views
Replies
Total Likes
I assume that you messed up the permissions on your publish instance. By default anonymous should be able to see some more paths.
Jörg
If you are at an early stage in your project, I suggest to you to switch to AEM 6.4; that is not likely to fix your problem, but help you to be more up-to-date.
As the next step you should really think about your deployment pipeline; this maven plugin it good for local development, but I don't consider it a good choice to deploy a larger amount of machines (how do you determine errors during deployment? The error handling of the plugin is quite poor, and it also doesn't check the results of the installation, like validating that bundles are up etc).
And finally regarding your problem: Recompiling all scripts is rarely a solution, but only a workaround. I would expect that there are messages in the log indicating a problem, either during deployment time or while requesting a page.
Jörg
Views
Replies
Total Likes
WHen you manually publish your pages - are you seeing issues?
Views
Replies
Total Likes
We are not in an early phase of the project so a switch now to AEM 6.4 is not an immediate option. Of course we want to migrate it also to 6.4 but we want to do with without the time pressure that we currently have for the implementation.
I had a look to the logs of the publish instance, and I see following error messages when the header of the page is not displayed:
24.07.2018 20:04:07.759 *INFO* [10.240.10.8 [1532451847749] GET /content/serviceplan/en/test-page.html HTTP/1.1] com.day.cq.wcm.foundation.TemplatedContainer page has no template assigned
24.07.2018 20:04:07.759 *WARN* [10.240.10.8 [1532451847749] GET /content/serviceplan/en/test-page.html HTTP/1.1] com.day.cq.wcm.foundation.TemplatedContainer template has no structure support
Regarding deployment, could you please advice for better options than the maven deploy? Could you eventually point me to some documentation for best practices related to deployment for test and live environments?
Views
Replies
Total Likes
After the deployment the problem appears, and it does not get fixed with a publish of a page.
If I do a recompile JSP in that browser the site works correctly. If I do some changes to the content and publish them, the header is again not visible, and in the logs again the *INFO* and *WARN* messages from above appear again.
Views
Replies
Total Likes
I am debugging for the source of the problem using 2 browsers. In one I run the recompile all JSPs and everything is fine, in the other one not, and header is not displayed.
A strange thing I realised is when I log in CRX with both browsers. The one when everything is running looks fine and has all the required folders apps, content, libs, etc.
In the browser where the problem can be reproduced, I see a very reduced version in CRX containing only bin, content and crx folders.
Views
Replies
Total Likes
What user are you using to perform this actions? Are they the same on both browsers? Have you double-checked that you are actually visiting the same instance with both browsers?
Jörg
Views
Replies
Total Likes
I am using the admin user. And definitely I am accessing the same address in both browsers (I use copy paste for both the address and for CRX). I still can see the same differences in CRX.
Views
Replies
Total Likes
That means, that you are are being logged in into the very same system, with the very same user, but with 2 different browsers, and you get different views?
Assuming, that you access the same system makes me think, that you are not using the same user. The screenshot looks like the system an anonymous user would see when logging in into CRXDE Lite on a publish instance.
Jörg
Views
Replies
Total Likes
Hi Jörg,
Thank you for your answer. You are right, I am not logged in in CRX on the system where I see the problem. So what I realise now is that I do not even need to recompile JSPs. As soon as I log in into CRX the site looks fine. If I log out of it, the header of the page is gone.
So I am with admin when it works and anonymous when it does not work. It looks like a rights management problem somehow. Do you have a hint where to start looking?
Views
Replies
Total Likes
I assume that you messed up the permissions on your publish instance. By default anonymous should be able to see some more paths.
Jörg
hi Jörg,
Thank you for the help and for pointing me in the correct direction. I found the problem and it is what you have mentioned related to having the right permissions. The group everyone was not having the read permissions for the editable templates, and this is the reason why the page looked good as soon as we logged in the backend.
Now this works properly also for anonymous users. Thanks a lot for your help.
One last thing related to your comment:
Would you be so kind and point me to some documentation where I can read more about the best practices related to deployment. Or could you sketch a recommendation of how to change the deployment pipeline to be a better one that the current maven based one?
Views
Replies
Total Likes
Hi,
glad that you were able to find the issue on your own.
Regarding the deployment: you should establish a way, which gives you better control over the deployment process. Starting everything via maven is a nice way, but requires to have a lot of different pom files for the different stages. Also you don't have a retry capability in case something goes wrong in the first place (maybe due to bad timing, some seconds later the system would have settled and the request would have been successful). I was told that there are some plugins for Jenkins would allow you to deploy to AEM more smoothly.
Views
Replies
Total Likes
Thank you. I will have a look at this AEM Jenkins plugin.
Views
Replies
Total Likes