How do you debug annotation injectors when they just appear null?

Question!

I am currently working with CQ5/AEM, and we have an @Reference annotation that seems to act in a similar fashion to an injector annotation.

Our problem was that we had a misconfiguration in our POM file, which caused the injection to just fail.

We had to brute force change the POM file section by section to identify what was causing the problem. Brute force is obviously never the best approach.

What are the different methods in other frameworks such as spring, to debug annotative injectors when they fail?

Any advice would be greatly appreciated, as we are finding it a common enough problem.

Best regards,

Bayani


           <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <version>2.3.7</version>
                <configuration>
                    <instructions>
                        <Embed-Dependency>*;scope=compile|runtime</Embed-Dependency>
                        <Embed-Directory>OSGI-INF/lib</Embed-Directory>
                        <Embed-Transitive>true</Embed-Transitive>
                    </instructions>
                </configuration>
           </plugin>

We fixed it after removing configuration.

However by setting the replicator dependency with scope of provided also solved it.

          <dependency>
                 <groupId>com.day.cq</groupId>
                 <artifactId>cq-replication</artifactId>
                 <version>5.4.24</version>
                 <scope>provided</scope>
          </dependency>

My core question is still, given that we only have @Reference being null to start with, would you have any suggestions for how to attack this problem given just a null on a reference?



Answers

@Reference is not specific to CQ, it's handled by the Apache Felix maven-scr-plugin to generate metadata for OSGi Declarative Services (DS).

You're not saying how the "injection just failed" in your case.

If your problem happens at build time, it's probably due to a misconfiguration of the maven-scr-plugin, in which case the DS metadata won't be generated correctly. That metadata is generated under target/scr-plugin-generated/OSGI-INF, you could check the files that are in there against the DS spec to check that they're correct. The syntax of the XML metadata files generated there is fairly simple and documented in the DS specs. Note also mvn -X which outputs debug information at build time, that might help troubleshoot such issues.

If on the other hand the build and DS metadata are ok but the reference isn't satisfied at build time, you can check via the OSGi console (under /system/console in Sling and CQ5) if the required OSGi services are present, and if not check the system logs for possible reasons or debug the service modules at the Java level.



This video can help you solving your question :)
By: admin