I am trying to retrieve the bundle's last modified date within an OSGi Service using
bundle = FrameworkUtil.getBundle(this.getClass());
bundle.getLastModified();
It works in the local instance but not in AEM cloud where the bundle is null. Is there any reason for this behaviour in the aem cloud alone?
Solved! Go to Solution.
Taking a long shot but I think it might not be possible for the following reason -
AEMaaCS has pods which is a discrete instance that is part of an AEM Service (Author or Publish).
Pods are transient, meaning AEM as a Cloud Service creates and destroys them as need.
Only pods that are part of the associated AEM as a Cloud Service environment, are listed that environment’s Developer Console’s Pod switcher.
When we are viewing bundle's status and configuration we are doing so w.r.t a particular pod.
The bundles and their configurations will be the same but the timestamp might not be as pods are dynamically created and destroyed.
I tested the same on sandbox environment in AEMaaCS -
I had 2 pods in author service, I extracted the bundle configuration for the both.
As seen below the last modified time stamp for almost all bundles on the 2 pods are different. (PFB info for one particular bundle of Adobe Granite Crypto Support)
POD A { "bundleID": 10, "bundleName": "Adobe Granite Crypto Support", "symbolicName": "com.adobe.granite.crypto", "status": "active", "location": "reference:file:/opt/aem/launcher/cache/com/adobe/granite/com.adobe.granite.crypto/3.4.18/com.adobe.granite.crypto-3.4.18.jar", "lastModified": "Wed May 31 23:00:21 UTC 2023", "version": "3.4.18"}
POD B { "bundleID": 10, "bundleName": "Adobe Granite Crypto Support", "symbolicName": "com.adobe.granite.crypto", "status": "active", "location": "reference:file:/opt/aem/launcher/cache/com/adobe/granite/com.adobe.granite.crypto/3.4.18/com.adobe.granite.crypto-3.4.18.jar", "lastModified": "Wed May 31 09:45:59 UTC 2023", "version": "3.4.18"}
I am not sure if this reasoning is correct but seemed plausible hence wanted to put it out here!
Even if you get the lastModifiedTime() of the bundle it might not be same for all the pods.
You can use the Developer Console: https://experienceleague.adobe.com/docs/experience-manager-learn/cloud-service/debugging/debugging-a.... to see bundle details, and you don't need to write code until you have some specific use case.
I want to retrieve the date only through code because I'm trying to use the date for a functionality.
Taking a long shot but I think it might not be possible for the following reason -
AEMaaCS has pods which is a discrete instance that is part of an AEM Service (Author or Publish).
Pods are transient, meaning AEM as a Cloud Service creates and destroys them as need.
Only pods that are part of the associated AEM as a Cloud Service environment, are listed that environment’s Developer Console’s Pod switcher.
When we are viewing bundle's status and configuration we are doing so w.r.t a particular pod.
The bundles and their configurations will be the same but the timestamp might not be as pods are dynamically created and destroyed.
I tested the same on sandbox environment in AEMaaCS -
I had 2 pods in author service, I extracted the bundle configuration for the both.
As seen below the last modified time stamp for almost all bundles on the 2 pods are different. (PFB info for one particular bundle of Adobe Granite Crypto Support)
POD A { "bundleID": 10, "bundleName": "Adobe Granite Crypto Support", "symbolicName": "com.adobe.granite.crypto", "status": "active", "location": "reference:file:/opt/aem/launcher/cache/com/adobe/granite/com.adobe.granite.crypto/3.4.18/com.adobe.granite.crypto-3.4.18.jar", "lastModified": "Wed May 31 23:00:21 UTC 2023", "version": "3.4.18"}
POD B { "bundleID": 10, "bundleName": "Adobe Granite Crypto Support", "symbolicName": "com.adobe.granite.crypto", "status": "active", "location": "reference:file:/opt/aem/launcher/cache/com/adobe/granite/com.adobe.granite.crypto/3.4.18/com.adobe.granite.crypto-3.4.18.jar", "lastModified": "Wed May 31 09:45:59 UTC 2023", "version": "3.4.18"}
I am not sure if this reasoning is correct but seemed plausible hence wanted to put it out here!
Even if you get the lastModifiedTime() of the bundle it might not be same for all the pods.
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies