Expand my Community achievements bar.

Get ready! An upgraded Experience League Community experience is coming in January.

Issue with OSGI components unsatisfied reference state in AMS

Avatar

Level 2

Hi All,

 

We are currently migrating our legacy AEM project to the new Maven archetype (version 54). In the old setup, we had around 35 separate backend bundles, each with its own pom.xml. In the new structure, we’ve merged all these bundles into a single core bundle (as per adobe recommendation)

 

Challenge:

  • After a full build and deployment on a fresh AEM instance, most OSGi components are active.
  • However, when we run mvn clean install -PautoInstallBundle, many components switch to an Unsatisfied state —even though the referenced services appear as active in /system/console/components.
  • We tried making references optional with cardinality, but that feels like a workaround rather than a proper solution.

Any pointers or guidance would be greatly appreciated.

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

3 Replies

Avatar

Community Advisor

Hi @AravindB1,

1. Missing or incorrect package exports after consolidation

Even though everything is now in one bundle, the OSGi classloader still relies on properly exported packages.

If some packages were implicitly exported in the old multi-bundle setup (because each bundle had its own exports), merging into a single core bundle may result in:

  • services not visible to each other

  • SCR not finding implementation classes

  • @Reference showing Unsatisfied even though provider is active

Check your core/pom.xml:

<Export-Package>
    com.myproj.api.*,
    com.myproj.services.*,
    !
</Export-Package>

If a package containing an OSGi service or its interface is not exported, the DS resolver cannot wire the reference.

2. Multiple service interfaces now in the same bundle, but DS resolver detects cycles

In a large consolidated bundle, circular service dependencies become more obvious:

Service A → Service B → Service A

Previously they lived in different bundles, so resolution timing differed.

Now they load together -> DS marks one as Unsatisfied.

Check /system/console/depfinder for cycles.

3. Auto-install bundle deploy overwrites only one bundle, but dependent bundles are stale

When using:

mvn clean install -PautoInstallBundle

only core gets installed.

If some services or interfaces were previously in other bundles and AEM still has old bundles cached:

  • DS resolves against the old bundle first

  • references become unsatisfied after refresh

Verify using:

/system/console/bundles?sl=1

You might see:

  • old bundles still installed

  • export conflicts

Solution -> uninstall old bundles completely.

4. Component activation order changes in a single bundle

35 bundles -> 1 bundle means DS activation timing shifts.

A reference like:

@Reference(cardinality = ReferenceCardinality.MANDATORY)
private MyService myService;

may temporarily be unavailable during activation, causing Unsatisfied -> Active -> Unsatisfied oscillation when hot-deployed.

AEMaaCS and newer AEM SDKs are more strict about DS timing.

5. Mixed annotations (Felix SCR + OSGi R6) after migration

If part of the legacy code still uses:

@SlingServlet
@Service
@Component

…and the new code uses:

@Component(service = MyService.class)

SCR vs DS annotation processors can conflict after consolidation.

Run:

mvn clean install -Panalysis

and check for:

  • missing DS metadata

  • old SCR tags

  • components not registered at all


Santosh Sai

AEM BlogsLinkedIn


Avatar

Level 4

Hello @AravindB1 ,

It appears that there is a sequential arrangement regarding how the bundles are organized within the single pom.xml file.

 

Could you kindly check the inter-dependencies of the bundles and work on arranging them in the correct sequence?

 

You can accomplish this by examining the unresolved dependencies in the unsatisfied bundles or by reviewing the error logs.

 

Hope this is helpful!

Thanks 

Avatar

Community Advisor

HI @AravindB1 ,


The "maven-bundle-plugin" in the core bundle's pom.xml needs to be updated to correctly export and import packages for the consolidated code.

Review the Export-Package and Import-Package instructions within the plugin configuration. Ensure that all necessary packages from the merged code are properly exported for other bundles to consume and that any required external packages are imported.

For example:

    <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <extensions>true</extensions>
        <configuration>
            <instructions>
                <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
                <Bundle-Name>${project.name}</Bundle-Name>
                <Export-Package>
                    com.yourproject.core.components.*,
                    com.yourproject.core.services.*,
                    <!-- Add other packages to export from the merged code -->
                </Export-Package>
                <Import-Package>
                    !org.apache.felix.scr.annotations, <!-- Avoid importing SCR annotations directly -->
                    *
                </Import-Package>
            </instructions>
        </configuration>
    </plugin>

 

 

Hope it helps!


-Tarun