I'm working on an upgrade from 6.2 to 6.5. We will not be switching to Touch UI any time soon because they have not budgeted for it. We are only working to get the old Classic UI and JSP pages to run in 6.5.
I am also trying to update the project to the latest Adobe archetype. I have everything building and deploying now but when the JSP runs, I am getting a ClassNotFoundException for the com.day.cq.wcm.api.Page class.
What do I need to do so that the class can be found by the JSP?
Views
Replies
Total Likes
Hey @RobertHarperFS
First, the warning you don't want to hear but you will keep reading everywhere, yeah, you should not do this and instead use TouchUI, problems like this can't and won't be addressed by Adobe.
Now, a couple of things to check, did you by any chance bounce the instance after the SP was installed? I don't recall on top of my head if you must do it in such an upgrade, but usually, it is a good idea once everything is calm and stable. Second, did you check all the bundles are active? Can you also make sure the package you are referring can be resolved by the depfinder http://localhost:4502/system/console/depfinder in the console?
I knew the Touch UI thing would be the first go to. As I said, I've been told they have no plans for that migration, though the users would prefer there were.
My packages are active, the com.day.cq.wcm.api.Page is core to AEM so I don't see why it wouldn't be found.
We actually have the code running but it is a different archetype that it is built with. Same one used to build the bundles for the 6.2 instance but with pom settings to export old libraries.
The issue is that I'm probably missing something in the new archetype.
This is what I would try:
1. Restart the instance, if you have a local instance to test this out, the better.
2. Try using the depfinder to identify which bundle was exporting the class in 6.2 and which is exporting in 6.5. Then make sure the bundle version is actually the one being used in your project, hopefully, this can give more clues.
If the error is saying that the class was not found, means the Class is not available at runtime, so either AEM is wonky and restart may help, or indeed you are not referencing the correct bundle.
Now when the code tries to get the PageManger, I am getting this exception.
java.lang.ClassCastException: class com.day.cq.wcm.core.impl.page.PageManagerImpl cannot be cast to class com.day.cq.wcm.api.PageManager (com.day.cq.wcm.core.impl.page.PageManagerImpl is in unnamed module of loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader @3cd6ddee; com.day.cq.wcm.api.PageManager is in unnamed module of loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader @61fd291d)
I've searched but I can't find a resolution for this bit.
My local instance has been restarted several times. I exported a listing of classes that are contained in the uber-jar.6.5.0.jar file and it does not contain the com.day.cq.wcm.api.Page.class. When I go to the dependency finder and then use the bundle that contains the class and add that to the project and export the library, it breaks the whole instance because the versions of other classes aren't the same as what is in the uber-jar.
I've been going in circles on this. Restarting the instance solves nothing.
Here is a listing from the associated bundle showing that the com/day/cq/wcm/api/Page.class class is in the bundle.
Listing by using jar tvf [bundle_file_name]
3093 Wed Aug 30 06:42:08 MDT 2023 com/day/cq/wcm/api/LanguageManager.class
4608 Wed Aug 30 06:42:08 MDT 2023 com/day/cq/wcm/api/NameConstants.class
290 Wed Aug 30 06:42:08 MDT 2023 com/day/cq/wcm/api/package-info.class
2044 Wed Aug 30 06:42:08 MDT 2023 com/day/cq/wcm/api/Page.class
3942 Wed Aug 30 06:42:08 MDT 2023 com/day/cq/wcm/api/PageEvent.class
1723 Wed Aug 30 06:42:08 MDT 2023 com/day/cq/wcm/api/PageFilter.class
The error in the log file.
Caused by: java.lang.ClassNotFoundException: com.day.cq.wcm.api.Page
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:471)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:588)
at org.apache.sling.launchpad.base.shared.LauncherClassLoader.loadClass(LauncherClassLoader.java:160)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
at org.apache.felix.framework.BundleWiringImpl.doImplicitBootDelegation(BundleWiringImpl.java:1817)
at org.apache.felix.framework.BundleWiringImpl.tryImplicitBootDelegation(BundleWiringImpl.java:1746)
at org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1699)
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1575)
at org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
This doesn't make any sense. The class loader should see the class in the bundle.
Did the upgrade of the AEM instance go well? The uber-jar is marked as "provided," which means it should be available at runtime. However, that seems to be the exact issue you're facing – it's not available. As far as I know[1], this jar is part of the OSGI container, which should be updated during the AEM upgrade.
I believe you can experiment with two approaches to narrow down the issue:
Attempt to embed and manually upload the uber-jar. This should ensure that the classes are exposed at runtime.
Try changing the version of the uber-jar to the previous one you had. If it runs without any issues, it might indicate that the OSGI context retained the old version of the uber-jar (which is unusual).
[1] https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/uber-jar/m-p/141763
Oddly, the com.day.cq.wcm.api.Page class is not in the uber-jar.6.5.0.jar. I've checked. I've added it to the exported libraries in my bundles and when I check those bundles, I see the class file there. It seems odd to me that I don't see the com.day.cq.wcm.api.Page class in the uber-jar. I would have thought that was core.
This just keeps getting stranger. I still haven't found a resolution to this. I added code to get the class object of the currentPage attribute in the JspContext..
From the logs:
The class is com.day.cq.wcm.core.impl.page.PageImpl
Interface0 = com.day.cq.wcm.api.Page
Super Class = org.apache.sling.adapter.SlingAdaptable
I don't understand why in the next couple lines I try to cast the PageImpl object to the Page object that it generates a ClassCastExeption when the com.day.cq.wcm.api.Page interface is the object's interface that it is implementing. Why would this be? I've never seen this before.
Views
Replies
Total Likes
Views
Likes
Replies