Level 3

Solved

Custom component renders on author but not publish

Forum|Forum|1 year ago
June 4, 2024
5 replies
2763 views

Hello,

I am having an issue with a custom component that is not rendering on the publish server but renders fine on the author server. Here are the different combinations that I have tried to get it to work.

It always renders on the Author instance no matter what. We have different portals set up in our site structure, let's call them portal A and B. If I put the component on a site in Portal A, it also always renders correctly. However, when I put the component in Portal B's site pages, it does not work on the Publish instance.

This behavior makes me think it could be a config but I have looked and it seems like both portals have the same configuration.

Is there another possibility? Or is there a way that I can debug?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

Best answer by rkody

This was caused by an issue with shared and global component properties.

Through debugging I figured out that the problem was some properties injected like this:

@SharedValueMapValue(injectionStrategy = InjectionStrategy.OPTIONAL)
private String str;

They were always null on Portal B on the publish instance. Our setup had @SharedValueMapValue properties get added to the root path in our site structure, and the issue was that root page did not get published. So that's why it worked on Portal A, because the root page was published as well as the page that had the component in question.

EstebanBustamante

Community Advisor and Adobe Champion

Hi,

It seems to me that your component relies on some content that may not be available in the publish instance. That's why it could be breaking. If you have the code, the best thing to do is to check what this component is doing, if it is reading some content or needs extra configurations, additionally, you should check the logs to see if there is any additional information.

Hope this helps

Esteban Bustamante

rkodyAuthor

Level 3

Hey Esteban,

I have some more information that I just figured out. I am getting this error in the logs:

12.06.2024 15:50:24.465 *INFO* [qtp2098876788-2488723] org.apache.sling.auth.core.impl.SlingAuthenticator getAnonymousResolver: Anonymous access not allowed by configuration - requesting credentials
12.06.2024 15:50:24.470 *WARN* [qtp2098876788-2488723] org.apache.sling.auth.core.AuthUtil isRedirectValid: Redirect target must not be empty or null

I am getting this on the publish instance only. Could this be a clue as to what the problem could be? It seems like whatever the component is doing it doesn't have access to get the Resolver object.

EstebanBustamante

Community Advisor and Adobe Champion

Hey @rkody, I don't think that is related to your issue. The best thing to do is to understand what your component is doing. Check if this has a Sling model, if this depends upon OSGi services, if there are any JavaScript that may be failing, etc. etc. It is hard to advise without knowing what your component does, but I am sure if you can debug and understand what pieces are joining together within your component you will know which one is failing. Please check this tutorial in case you don't know how to debug:

https://jimfrenette.com/2019/12/aem-app-debug-visual-studio-code/

https://aemgeeks.com/aem-debugging/how-to-start-aem-in-debug-mode/

If debugging is not an option because the issue is not reproducible locally, you could increase the logging statements wherever you feel suspicious the issue may be occurring and then check the logs once more.

Hope this helps!

Esteban Bustamante

P

priyak-1

Level 3

Hi @rkody ,

Can you please check on the following:

1) If there are any logs related to your component on publish server

2) Try to replicate same on local publish server.

3) If it works fine in local publish, and if there are no errors, please flush the dispatcher cache and check.

HrishikeshKagne

Community Advisor

Hi @rkody ,

The issue you're experiencing, where a custom component renders on the author instance but not on the publish instance (particularly in one specific portal), can be caused by several factors. Here are steps to help you debug and potentially resolve this issue:

1. Check Dispatcher Configuration

The dispatcher configuration can sometimes block specific resources or requests. Ensure that the dispatcher is not blocking the custom component's resources:

Check the dispatcher logs for any blocked requests.
Verify the dispatcher filter rules to ensure the component's resources are allowed.
Ensure the cache is cleared on the dispatcher after deploying changes.

2. Compare Configurations

Ensure that both portals (A and B) have identical configurations in terms of client libraries, OSGi configurations, and permissions:

Compare the OSGi configurations on both portals in the author and publish instances.
Verify the client libraries (JS and CSS) required for the component are correctly included and loaded on the publish instance.

3. Check Permissions and Access Control

Ensure that the component and its dependencies have the correct permissions:

Verify that the content under /apps, /etc, and /libs required by the component is accessible on the publish instance.
Ensure that there are no permissions or access control restrictions on Portal B that might be causing the component not to render.

4. Inspect Error Logs

Check the error logs on the publish instance for any clues:

Look at the error.log file under the logs directory of the publish instance.
Check for any errors or warnings related to the component or its dependencies.

5. Client-Side Debugging

Use browser developer tools to inspect the network requests and console logs:

Open the browser's developer console (F12).
Check the Network tab to see if any resources (JavaScript, CSS, etc.) are failing to load.
Look for JavaScript errors or warnings in the Console tab that might indicate issues.

6. Content and Configuration Synchronization

Ensure that the content and configurations are correctly synchronized between the author and publish instances:

Use the AEM Package Manager to create a package of the component and its dependencies from the author instance and deploy it to the publish instance.
Use the "Activate" feature in AEM to publish the component and its configurations to the publish instance.

7. Use Query Debugging Tools

AEM provides tools for debugging query-related issues:

Use the CRXDE Lite tool (http://<publish-instance>:4502/crx/de) to inspect the content structure and ensure all necessary nodes and properties are present on the publish instance.
Ensure that the component's Sling model or script paths are correctly resolved on the publish instance.

8. Component and Template Paths

Ensure the component and its template paths are correctly resolved on the publish instance:

Check the component's resource type and ensure it is correctly registered in /apps/<your-app>/components.
Verify the component's script (.jsp, .html, or .java) is correctly placed and accessible in the publish instance.

Example Debugging Steps

Verify Dispatcher Configuration

/your-dispatcher-path/logs/dispatcher.log

Inspect Error Logs on Publish Instance

<your-publish-instance>/crx-quickstart/logs/error.log

Network and Console Logs in Browser

Open Developer Tools (F12).
Navigate to the Network tab and refresh the page.
Check for any failed requests (404, 403, etc.).
Go to the Console tab and look for any errors.

Compare Configurations

Use AEM's Web Console Configuration to compare OSGi configurations:

http://<publish-instance>:4502/system/console/configMgr

By systematically going through these steps, you should be able to identify and resolve the issue preventing your custom component from rendering on the publish instance.

Hrishikesh Kagane

rkodyAuthor

Level 3

Thank you for your reply.

I have looked into these steps and the only issue that I have found was by putting more logs into the component and then deploying locally, because the issue is replicated on my local instance as well.

I have an init function in the component code that has this line:

String[] selectors = slingRequest.getRequestPathInfo().getSelectors();
//Added logger line
LOGGER.info(String.valueOf(slingRequest.getRequestPathInfo()));

Based on the logs I have this on Author and publish respectively:

2024-06-05 10:57:25.688 INFO [component] SlingRequestPathInfo: path='/content/.../jcr:content/root/main-par/section-wrapper/article-list', selectorString='load.1', extension='html', suffix='null'

2024-06-05 11:08:58.382 INFO [component] SlingRequestPathInfo: path='/content/.../jcr:content/root/main-par/section-wrapper/article-list', selectorString='null', extension='html', suffix='null'

So for some reason the selectorString is different and based on the component code it depends on the selector values.

kautuk_sahni

Community Manager

@rkody Did you find the suggestions from users helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!

Kautuk Sahni

rkodyAuthor

Level 3

I did not find the answers to be useful in solving my issue yet. I provided a couple follow ups to the replies but have not received a response. This is still open but i will be updating when I figure it out.

rkodyAuthorAccepted solution

Level 3

This was caused by an issue with shared and global component properties.

Through debugging I figured out that the problem was some properties injected like this:

@SharedValueMapValue(injectionStrategy = InjectionStrategy.OPTIONAL)
private String str;

They were always null on Portal B on the publish instance. Our setup had @SharedValueMapValue properties get added to the root path in our site structure, and the issue was that root page did not get published. So that's why it worked on Portal A, because the root page was published as well as the page that had the component in question.

EstebanBustamante

Community Advisor and Adobe Champion

That's exactly what my first comment mentioned, you probably missed some content in the publish instance, I'm glad you figured it out.

Esteban Bustamante

1. Check Dispatcher Configuration

2. Compare Configurations

3. Check Permissions and Access Control

4. Inspect Error Logs

5. Client-Side Debugging

6. Content and Configuration Synchronization

7. Use Query Debugging Tools

8. Component and Template Paths

Example Debugging Steps

Verify Dispatcher Configuration

Network and Console Logs in Browser

Compare Configurations

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded