You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@sling.apache.org by cz...@apache.org on 2017/05/09 15:57:52 UTC

svn commit: r1794603 - /sling/site/trunk/content/documentation/the-sling-engine/service-authentication.mdtext

Author: cziegeler
Date: Tue May  9 15:57:52 2017
New Revision: 1794603

URL: http://svn.apache.org/viewvc?rev=1794603&view=rev
Log:
Provide default mapping for service users and correct sample for mapping reference

Modified:
    sling/site/trunk/content/documentation/the-sling-engine/service-authentication.mdtext

Modified: sling/site/trunk/content/documentation/the-sling-engine/service-authentication.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/documentation/the-sling-engine/service-authentication.mdtext?rev=1794603&r1=1794602&r2=1794603&view=diff
==============================================================================
--- sling/site/trunk/content/documentation/the-sling-engine/service-authentication.mdtext (original)
+++ sling/site/trunk/content/documentation/the-sling-engine/service-authentication.mdtext Tue May  9 15:57:52 2017
@@ -158,19 +158,24 @@ This is configured through an OSGi confi
 
     <service-name>[:<subservice-name>]=<authorizable id of a JCR system user>]
 
-The according user must exist at the point in time where `ResourceResolverFactory.getServiceResourceResolver(...)` or `SlingRepository.loginService(...)` is called. If you rely on one of those methods in your `activate` method of an OSGi component you should make sure that you defer starting your OSGi component until the according service user mapping is in place. For that you can reference the OSGi service `ServiceUserMapped` ([SLING-4312](https://issues.apache.org/jira/browse/SLING-4312)), optionally with a target filter on property `subServiceName` (in case such a subservice name is used). The service `ServiceUserMapped` does not expose any methods but is only a marker interface exclusively used to defer starting of other OSGi components.
+The according user must exist at the point in time where `ResourceResolverFactory.getServiceResourceResolver(...)` or `SlingRepository.loginService(...)` is called. If you rely on one of those methods in your `activate` method of an OSGi component you should make sure that you defer starting your OSGi component until the according service user mapping is in place. For that you can reference the OSGi service `ServiceUserMapped` ([SLING-4312](https://issues.apache.org/jira/browse/SLING-4312)), optionally with a target filter on property `subServiceName` (in case such a subservice name is used). The service `ServiceUserMapped` does not expose any methods but is only a marker interface exclusively used to defer starting of other OSGi components. However this waits only for the mapping configuration to be available, it does not wait for the service user itself to be available.
 
 Example OSGi DS Component
 
     :::java
-    @Component
+    @Component(
+        reference = {
+            // this waits with the activation of this component until a service user mapping with the service name = current bundle's id and the sub service name 'my-subservice-name' is available.
+            // you can leave out "target" if the sub service name is not used.
+            // Please note that this only waits for the mapping to be available, it does not wait for the service user itself to be available!
+            @Reference(name ="scriptsServiceUser", target="(subServiceName=my-subservice-name)", service=ServiceUserMapped.class)
+        }
+    )
     class MyComponent {
-      // this waits with the activation of this component until a service user mapping with the service name = current bundle's id and the sub service name 'my-subservice-name' is available.
-      // you can leave out "target" if the sub service name is not used
-      @Reference(target = "(subServiceName=my-subservice-name)")
-      private ServiceUserMapped serviceUserMapped;
     }
 
+There is a default mapping applied if no OSGi configuration is available for the mapping. The default is: "serviceuser--" + bundleId [ + "--" + subservice-name]. Please note, that these default mappings are not represented as a ServiceUserMapped service and therefore the above mentioned reference does not work.
+
 ## Deprecation of administrative authentication
 
 Originally the `ResourceResolverFactory.getAdministrativeResourceResolver`