AEM6.5: Adding custom projects as external dependency and extending custom sling models

[AkankshaPratihar]

I have a Project A which has got certain features and associated sling models. As per the requirement, I have to add the core and ui.apps of this Project A as a dependency to Project B.
So Project A core.jar added as dependency to Project B core module
& Project A ui.apps.zip added as dependency to Project B ui.apps module.

Also I have to extend Sling Models from Project A into Project B and override some of their getters where additional logic is implemented. (typical requirement and needs to be done). The sling models in Project A are actually composed of multiple other sling models as sub elements.

Example.

@Model(adaptables = Resource.class, defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL)
public class Content extends abc.core.models.Content {
@inject
private TextSlingModel text;

@Override
public TextSlingModel getText() {
return text;
}
}

All the build time dependencies are resolved and this is deployed to AEM. Now, when I'm trying to access fields of Project A Sling Models via Project B Sling Models, it works fine if the extended sling model just has new fields and none of the SDM getters(getText in above example) from parent SDM are overriddren in child SDM.

However, when the child SDM has overridden getters I get error as below:

java.lang.LinkageError: loader constraint violation for class projectA.core.models.Content: when selecting overriding method projectA.core.models.Content.getText()LprojectB/core/models/context/TextSlingModel; the class loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader @4f50a54b (instance of org.apache.felix.framework.BundleWiringImpl$BundleClassLoader, child of org.apache.sling.launchpad.base.shared.LauncherClassLoader @147a5d08 org.apache.sling.launchpad.base.shared.LauncherClassLoader) of the selected method's type projectA.core.models.Content, and the class loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader @4f9211d8 (instance of org.apache.felix.framework.BundleWiringImpl$BundleClassLoader, child of org.apache.sling.launchpad.base.shared.LauncherClassLoader @147a5d08 org.apache.sling.launchpad.base.shared.LauncherClassLoader) for its super type projectB.core.models.Content have different Class objects for the type projectB.core.models.context.TextSlingModel used in the signature

Please note that thing was working fine when the Parent Project was included in the ui.apps and core module as sibling folders even in this case SDMs were extended.

[B_Sravan]

Hi @AkankshaPratihar 

It seems like you're encountering a classloader issue when trying to extend Sling Models from Project A into Project B and override their getters. The error message indicates a "loader constraint violation," which typically occurs when classes loaded by different class loaders try to interact with each other.

In your case, the issue arises because the Sling Models from Project A and Project B are loaded by different class loaders. This can happen when the two projects are deployed separately or have different OSGi bundles managing their dependencies.

To resolve this issue, you need to ensure that the Sling Models from Project A and Project B are loaded by the same class loader. Here are some steps you can take:

1. Bundle Structure: Ensure that both Project A and Project B are structured as OSGi bundles and are deployed within the same OSGi container (e.g., Apache Felix or Adobe Experience Manager).

2. Dependency Management: Check the dependency management setup in both projects. Make sure that Project B explicitly depends on Project A and that the dependency is properly resolved during deployment. This ensures that both projects are loaded within the same OSGi container and, therefore, by the same class loader.

3. Class Loading Policies: If you're using a custom class loading mechanism or have control over class loading policies, ensure that both projects are configured to use the same class loader or class loading strategy. This can involve tweaking OSGi bundle configurations or class loading settings in your application server.

4. Bundle Versions: Ensure that there are no conflicting versions of the same classes or dependencies between Project A and Project B. Conflicting versions can lead to classloading issues.

5. OSGi Configuration: If you're using Apache Felix or a similar OSGi framework, review the configuration files (e.g., config.properties, config.xml) to ensure that the class loading behavior is consistent across both projects.

6. Debugging: If the issue persists, enable debug logging for class loading or OSGi framework operations. This can provide more insights into how classes are being loaded and help identify any discrepancies between Project A and Project B.

By ensuring that both projects are loaded by the same class loader and have consistent dependency management, you should be able to resolve the classloader constraint violation and successfully extend Sling Models from Project A into Project B.

Thank you.
Sravan