upgrade CQ5.4 to AEM

[Former Community Member]

In process of upgrading to AEM from CQ5.4, facing few challenges.

Deleted custom code in CQ 5.4 and upgraded to AEM and was able to access WCM and other AEM console pages.

After upgrading to AEM, the installation of custom or project code is bringing down (services are turned unregistered) most of the felix framework and custom services. Please give the hints and share the details if any configurations need to be done for  custom authentication handlers or any changes need to be done for filters. Got to know filters were made strict in AEM.

Note: All of these custom OSGi bundles are perfectly working fine in CQ 5.4

[Paul_McMahon]

Have you tried to recompile your OSGI services against the 5.6.1 dependencies. There have been significant API changes since 5.4 - my guess is some of your bundles may not be able to find required dependencies. You will likely need to change either dependency names or versions, and some case you may need to refactor your code.  

[Jörg_Hoh]

Can you share the logfiles (or at least the relevant parts of it)? Without logfiles it's really hard to debug such problems.

Jörg

[Former Community Member]

Nice and Thanks for your reply. Can you point us to the CQ 5.6.1 dependencies 

[Paul_McMahon · Accepted solution]

You can also take a look at the bundles console in Felix and look for bundles that have not started. If you drill down to the details screen it should show where you have problem/missing dependencies. In addition as Jörg said your log files from the startup phase will have informative messages. 

In addition if you are using maven you can find all the correct dependencies here - http://repo.adobe.com/nexus/content/groups/public/com/day/cq/cq-quickstart-product-dependencies/ - there are POMs which list all the product dependencies for 5.5, 5.6, and 5.6.1. This is useful in updating your project's POM. 

[Former Community Member]

Thanks Jörg and Orotas for your reply.

Posted the error observed in another link - We are getting this after deploying our custom authentication handler as fragment bundle in AEM..

[Jörg_Hoh]

In CQ 5.4 the connection between the 2 webapps (sling launchpad and crx) was done using JNDI. This is not required anymore since CQ 5.5 since CRX now also runs within the OSGI container. Probably this kind of internal API has been dropped, not sure about it. At least the dependency finder does not list any package exporting this class.

I woudl recommend that you adjust your authentication code to this new situation. Since CQ 5.4 a lot has been done on the CQ side also, especially regarding SAML support and other SSO featuers.

Jörg