Expand my Community achievements bar.

Enhance your AEM Assets & Boost Your Development: [AEM Gems | June 19, 2024] Improving the Developer Experience with New APIs and Events
SOLVED

Binding issue with osgi.component not being resolved

Avatar

Level 4

I am working on an update from a very old archetype to a newer AEM Archetype version 41 and I am having a binding issue after the bundle is deployed to the localhost instance.

The error I'm seeing when I attempt to start the bundle is as follows:

29.11.2023 09:19:09.646 *ERROR* [qtp693971857-5631] org.apache.felix.http.jetty Bundles: Cannot start (org.osgi.framework.BundleException: Unable to resolve wcm-service-facade-core [1348](R 1348.27): missing requirement [wcm-service-facade-core [1348](R 1348.27)] osgi.extender; (&(osgi.extender=osgi.component)(version>=1.5.0)(!(version>=2.0.0))) Unresolved requirements: [[wcm-service-facade-core [1348](R 1348.27)] osgi.extender; (&(osgi.extender=osgi.component)(version>=1.5.0)(!(version>=2.0.0)))])
org.osgi.framework.BundleException: Unable to resolve wcm-service-facade-core [1348](R 1348.27): missing requirement [wcm-service-facade-core [1348](R 1348.27)] osgi.extender; (&(osgi.extender=osgi.component)(version>=1.5.0)(!(version>=2.0.0))) Unresolved requirements: [[wcm-service-facade-core [1348](R 1348.27)] osgi.extender; (&(osgi.extender=osgi.component)(version>=1.5.0)(!(version>=2.0.0)))]

 

What should I be doing to resolve this or what might I have added that requires this so I might see what happens if I remove a dependency that is causing this.

1 Accepted Solution

Avatar

Correct answer by
Level 4

I resolved this by removing dependencies and changing some servlet annotations so they did not use the 

@component

annotation from the osgi packages.

View solution in original post

21 Replies

Avatar

Community Advisor

@RobertHarperFS ,

Which version of AEM are you on? Here is the supported versions information for the latest archetypes.

System Requirements

Archetype AEM as a Cloud Service AEM 6.5 Java SE Maven

46Continual6.5.7.0+8, 113.3.9+

 

Avatar

Community Advisor

 A you check if aem core components are installed on your local aem? Is this maven build is your custom code or you just created a maven arch type project from 41 version and deployed it?

Avatar

Level 4

This maven project is for building our customizations. It is a port from 6.2 and we haven't converted the classic UI components over to touch UI yet. That may happen next year. I'm trying to simplify the build/deploy process so that fewer mistakes are made when developers try to build and deploy the current archetype. 

Updates and patches have been installed to my local instance. I'm just getting down to cleaning up the dependencies and resolving binding issues. All of the code builds and deploys as expected, I am now stuck on resolving this binding issue.

Avatar

Community Advisor

Aem version you are trying to install the code and the core-component version installed on your aem?

Avatar

Community Advisor

 What version of aem core-components you are using it?

Avatar

Level 4

acs-aem-commons-all.6.0.10, aem-service-pkg.6.5.15 have been applied.

Avatar

Community Advisor

core components are different then the acs-commons.

https://experienceleague.adobe.com/docs/experience-manager-learn/sites/components/core-components-fe...
note that Aem doesn’t support the classic ui components anymore so that might not work in aem 6.5.15

Avatar

Level 4

Actually, AEM 6.5 does support the classic UI components. However they are deprecated and not being supported but they do still work. I have seen it in action and know this for a fact.

 

I don't think the core components would really have any effect on this because they are now all touch UI and our components are based on classic UI.

 

We have a different, probably eight year old maven project that does successfully deploy and run in 6.5 with some dependency changes.

I am stuck on this binding issue with my version 41 aem-archetype project.

Avatar

Level 4

I've noticed this line in the bundle manifest header when looking at the details in the OSGI bundle page.

Require-Capability: osgi.extender; filter:="(&(osgi.extender=osgi.component)(version>=1.5.0)(!(version>=2.0.0)))", osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=1.8))"

This is not in my pom.xml file. Where would it be coming from and what would I do to fix this?

Avatar

Community Advisor

@RobertHarperFS ,

Try running the maven build using mvn -e -U -X clean install to run the build process in debug mode. That way you can find out which dependency is try to download that file.

Avatar

Community Advisor

For troubleshooting can you try by installing the aem code components packages and then doing your maven build and deploy?

you can also add core components as the dependency. 
https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/core-components-not-resolv...

I believe you had already aem Uber jar as dependency and you are deploying with new maven archetype and adding your project dependencies jar/package in archetype 41 maven project 

Avatar

Level 4

I think people are a little confused. Our code uses none of the core components in AEM 6.5. They are all classic UI based so I see no point in chasing down core component dependencies. There are none.

I am fully aware that the classic UI is deprecated and not supported. That being said, if you really look at release notes for 6.5, it clearly states that the classic UI is still available and supported. There is even a setting where you can easily toggle between the touch UI editor and the classic UI editor.

osgi.component is not a file. It is an osgi.extension. I need help resolving an issue where, after the deploy, AEM cannot resolve this extension. The build and deployment of the bundle is successful. It is the binding within AEM when the bundle is being bound and loaded in AEM that the problem occurs.

Avatar

Community Advisor

Well I understand that you are not using touch ui components the issue you are facing is not the compile time issue it’s related to runtime binding or you can say resolving the bundle dependencies for which I think your code package is still looking for some old versions of the added jar or dependencies which further leads to conclusion that either you need to update those versions in your Pom.xml and since you mentioned that it’s not part of your Pom.xml that means those packages are deployed on aem ootb with different versions. 
so above suggestions to looks for aem-Uber.jar and core components to check if any one of those updates the installed package versions.

it’s up to you to decide if you wants to give it a try or figure it out by your self. I can only recommend something based on my experiences with those issues and information shared.

Avatar

Level 4

Some dependencies are older versions because of the back end code. Which dependency should I be looking at to resolve this? If you have an idea which dependencies I need to look at, that would help. The problem I'm having is that I don't know which one is causing the issue.

Avatar

Community Advisor

Go on /system/console/dep finder and search for the package that expects the different version to be installed on your aem. This will give you the maven dependency which is adding those files make sure you have same versions of aem-Uber.jar installed on your aem with your code aem-Uber jar version should match with the service pack installed on your local. Confirm if you have same aem-Uber.jar version installed as your service pack version number

Avatar

Level 4

Last I looked, there wasn't a 6.5.15 uber-jar. We are using the 6.5.0 version. The dependency viewer is no help. There isn't a package named osgi.component. This has something to do with the ogsi.extender somehow. 

Avatar

Administrator

@RobertHarperFS  Did you find the suggestions from users helpful? Please let us know if more information is required. Otherwise, please mark the answer as correct for posterity. If you have found out solution yourself, please share it with the community.



Kautuk Sahni

Avatar

Level 4

No I did not find any of the responses as all that helpful. Many were goose chases that wasted my time.