Issue with OSGI components unsatisfied reference state in AMS

[AravindB1]

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.

[SantoshSai]

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