ResourceResolverFactory getServiceResourceResolver renvoie une exception dans AEM 6.1
Je veux écrire des données à l'AEM, et le code ci-dessous fonctionne très bien pour moi dans les AEM 6.0, mais pas dans les AEM 6.1 , jette toujours un Login Exception comme suit:
"Connexion Exception lors de l'obtention d'un CRX de l'Utilisateur pour le Service: writeService'.org.apache.la fronde.l'api.de la ressource.LoginException: Ne peut pas dériver le nom d'utilisateur pour le groupe d'ensembles.tti.communes-service [395] et sous service writeService"
OSGI Config:
Code dans ma classe:
import javax.jcr.Session;
import org.apache.sling.api.resource.ResourceResolver;
import org.apache.sling.api.resource.ResourceResolverFactory;
....
@Reference
private ResourceResolverFactory factory;
private ResourceResolver resourceResolverWriter;
private static Session adminSession;
...
...
Map<String, Object> param = new HashMap<String, Object>();
param.put(ResourceResolverFactory.SUBSERVICE, "writeService");
try {
resourceResolverWriter = factory.getServiceResourceResolver(param);
adminSession = resourceResolverWriter.adaptTo(Session.class);
...
} catch (LoginException e) {
...
}
Ai-je raté quelque chose sur AEM 6.1?
source d'informationauteur Suren Konathala
Vous devez vous connecter pour publier un commentaire.
Dans AEM 6.1, les utilisateurs des services des utilisateurs du système, ce qui signifie que leur nœud dans le JCR est de type rep:SystemUser. Ces utilisateurs ne peut pas être utilisé pour se connecter normalement, seulement par des processus d'arrière-plan. L'utilisateur admin est pas un utilisateur du système, de sorte que vous ne pouvez pas utiliser l'utilisateur admin dans un service de mappage de l'utilisateur comme ceci. Vous devez créer un nouvel utilisateur du système et de leur attribuer les autorisations appropriées.
Si vous souhaitez lire la suite de l'arrière-plan sur ce changement, prendre un coup d'oeil à https://issues.apache.org/jira/browse/SLING-3854.
Avec Justin conseils, j'ai essayé et trouvé la solution. L'affichage peut donc être bénéfique pour les autres.
Objectif: écrire des données/nœuds de contenu (plus précisément dans /etc/userdata) lorsqu'un utilisateur se connecte.
Nous pouvons atteindre cet objectif en 2 façons (de toute façon, l'utilisateur doit être un système de "l'utilisateur")
Processus 1:
Étape 1: Utilisation dans le système de l'utilisateur dans OSGI configuration. Dans OSGI sélectionnez Apache Sling Utilisateur de Services de Mappeur de Service
groupe.abc.communes-service:writeService=oauthservice (où "oauthservice' est un utilisateur du système)
Étape 2: Assigner l'utilisateur du système des autorisations pour accéder au contenu du dossier.
Vous voyez les utilisateurs du système CRX dans: /home/utilisateurs/système
Processus 2:
Étape 1: Créer un nouvel utilisateur du système. pour ce faire
Ouvrir http://localhost:4502/crx/explorer/index.jsp
Connecter en tant qu'admin > l'ouverture de l'Administration > Sélectionnez "Créer un Utilisateur Système" > Entrez "user id" > Frapper le bouton Vert (vous ne serez pas se un bouton "enregistrer":)
J'ai créé "abcwriteservice" utilisateur
Étape 2: Aller à des Autorisations, et pour l'utilisateur 'abcwriteservice' accorder des Autorisations d'accès au dossier où vous souhaitez écrire. (Dans cet exemple: /etc/userdata )
Étape 3: Ouvrez la console OSGI et aller à "Apache Sling Utilisateur de Services de Mappeur de Service" pour définir la fonction de mappage de l'utilisateur. Par exemple: "le groupe.communes-service:writeService=abcwriteservice'
Étape 4: Dans le code, j'ai rajouté un paramètre supplémentaire, comme:
Aussi, si vous êtes la planification d'une future migration vers AEM 6.2, envisager l'utilisation de l'ACS Communes afin de faciliter la création et la disponibilité des utilisateurs du système. Il élimine tous ce manuel processus, qui peut être sujette à erreur.
https://adobe-consulting-services.github.io/acs-aem-commons/features/ensure-service-users/index.html
place de session de faire comme:
Session comme ci-dessous ,espérons-le, de Connexion exception ne se produira pas
Cela arrive à cause resourceResolverWriter n'est pas d'objet implicite.