LoginException: Cannot derive user name for bundle (Service Resolver Issue)

Avatar

Avatar

Gdubz-57m2mu

Avatar

Gdubz-57m2mu

Gdubz-57m2mu

07-02-2017

Platform Version: AEM 6.2

Something I've noticed after using the service resolver pattern for a few months now, is that unless my class is a @Service and can @Reference the ResourceResolverFactory, then anytime I try to get a service resolver, I get the following error:

org.apache.sling.api.resource.LoginException: Cannot derive user name for bundle org.apache.sling.api [64] and sub service ugc-writer at org.apache.sling.resourceresolver.impl.ResourceResolverFactoryImpl.getServiceResourceResolver(ResourceResolverFactoryImpl.java:83)

Example class:

package org.testing.temp; import com.day.cq.wcm.api.Page; import org.apache.commons.lang.StringUtils; import org.apache.sling.api.resource.LoginException; import org.apache.sling.api.resource.ResourceResolver; import org.apache.sling.api.resource.ResourceResolverFactory; import org.apache.sling.api.scripting.SlingScriptHelper; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import java.util.HashMap; import java.util.Map; public class TempFunctions { private static final Logger LOG = LoggerFactory.getLogger(TempFunctions.class); private TempFunctions() { /* Static methods only - no instances */ } public static final String getSomeString(final SlingScriptHelper sling, final Page page) { final ResourceResolverFactory resourceResolverFactory = sling.getService(ResourceResolverFactory.class); Map<String, Object> serviceParams = new HashMap<>(); serviceParams.put(ResourceResolverFactory.SUBSERVICE, "ugc-writer"); try (ResourceResolver serviceResolver = resourceResolverFactory.getServiceResourceResolver(serviceParams)) { // do something with the service resolver here... } catch (LoginException e) { LOG.error("LoginException: {}", e); } return StringUtils.EMPTY; } }

Example of how I'm calling this code, a JSTL taglib function called within the JSP:

<%@include file="/libs/foundation/global.jsp"%> <c:set var="tempString" value="${ testingTemp:getSomeString(sling, resourcePage) }" /> <div>${ tempString }</div>

It's like, despite the call originating from my bundle, it's using the org.apache.sling.api bundle context and so the service mapper that I configured with my bundle is completely ignored. Has anyone else encountered this?

View Entire Topic

Avatar

Avatar

Gdubz-57m2mu

Avatar

Gdubz-57m2mu

Gdubz-57m2mu

08-02-2017

smacdonald2008 wrote...

I would go the @Service approach. 

 

Any idea if there is any sort of performance degradation* from doing this simply to provide the @Reference capability to a class/interface? Couldn't tell just from looking at the documentation[1].

* other than a couple extra <service> declaration lines in the META-INF file.

[1] http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html...