Are you facing such errors while migrating to AEM 6.3 :
osgi bundle whitelist error-osgi-service is NOT whitelisted to use SlingRepository.loginAdministrative
Here is a quick hack but please ensure not to use it in production
I believe most of the AEM developers are aware that
SlingRepository.loginAdministrative methods have been defined to provide access to the resource tree and JCR Repository.
Consequently the following methods are being deprecated
and alternatively we started using service authentication method getServiceResourceResolver to get the resourceResolver and then making a systme user and mapping service with user in felix congigurations.
like this <service-name>[:<subservice-name>]=<authorizable id of a JCR system user>]
IMAGINE YOU ARE A DEVELOPER AND YOU RESUME YOUR WORK AFTER LUNCH AND U HAVE BEEN ASKED TO RUN A GENERIC OSGI SERVICE ON AEM 6.3 AND YOU TRYING TO RUN THAT SERVICE BUT ITS GIVING THE ABOVE ERROR osgi-service is NOT whitelisted to use SlingRepository.loginAdministrative
Relax , You might be aware of the fix(service authentication) but you still dont want to add it coz you need to make code changes and build again and deploy. Hold on thats gonna take another 1 hour. Ridiculous ! and then youe question why they keep on changing methods to get resourceResolver.
LETS SAVE ONE HOUR IF YOU ARE USING THIS SERVICE OR BUNDLE ON LOCAL ENVIRONMENT.
1) go to osgi configurations
2) search for keyword whitelist
3) click on add and give a name to config and bundle symbolic name
YOU ARE DONE !
Refer to following link :
The recommended way to whitelist a bundle for administrative login is via a whitelist fragment configuration. It can be created as an OSGi factory configuration with the factoryPID
org.apache.sling.jcr.base.internal.LoginAdminWhitelist.fragment. E.g. a typical configuration file might be called
org.apache.sling.jcr.base.internal.LoginAdminWhitelist.fragment-myapp.config and could look as follows:
whitelist.name="myapp" whitelist.bundles=[ "com.myapp.core", "com.myapp.commons" ]
|String||Purely informational property that allows easy identification of different fragments.|
|String||||An array of bundle symbolic names that should be allowed to make use of the administrative login functionality.|
All configured whitelist fragments are taken into account. This makes it easy to separate whitelists for different application layers and purposes.
For example, some Sling bundles need to be whitelisted, which could be done in a whitelist fragment named
sling. In addition
myapp adds a whitelist fragment called
myapp. For integration tests and additional whitelist fragment
myapp-integration-testing may be added.
Furthermore, there is a global configuration with PID
org.apache.sling.jcr.base.internal.LoginAdminWhitelist, which should only be used in exceptional cases. It has a switch to turn administrative login on globally (
whitelist.bypass) and it allows supplying a regular expression to whitelist matching bundle symbolic names (
The regular expression is most useful for running PaxExam based tests, where bundle symbolic names follow a set pattern but have randomly generated parts.
Example: to whitelist all bundles generated by PaxExam a configuration file named
org.apache.sling.jcr.base.internal.LoginAdminWhitelist.config might look as follows:
The configuration PID is
org.apache.sling.jcr.base.internal.LoginAdminWhitelist. It supports the following configuration properties.
|Boolean||false||Allow all bundles to use administrative login. This is NOT recommended for production and warnings will be logged.|
|String||""||A regular expression that whitelists all matching bundle symbolic names. This is NOT recommended for production and warnings will be logged.|
I found this issue out on my own and then stumbled on this article while trying to understand this whitelist. This is needed for Brackets to work with AEM 6.3 (from what I can tell). You need to add aem-sightly-ide-api to the whitelist. Unfortunately, this just makes another error saying that WCMUse DNE for AEM 6.3... So from what I can tell, this API needs to be updated to use WCMUsePojo in order for the Brackets sync to work. When I learn more, I'll post a seperate thread for this.