Am 25.02.15 um 03:18 schrieb Antonio Sanso: > hi Oliver > On Feb 25, 2015, at 12:09 PM, Oliver Lietz <[email protected]> wrote: > >> On Wednesday 25 February 2015 10:50:36 Antonio Sanso wrote: >>> hi * >>> >>> On Feb 24, 2015, at 6:00 PM, Oliver Lietz >>> <[email protected]<mailto:[email protected]>> wrote: >>> >>> On Friday 20 February 2015 17:53:02 Marius Petria wrote: >>> Hi, >>> >>> hi Marius, >>> >>> I discovered an issue related to service users. Due to the indeterminism >>> of OSGI a consumer of ServiceUserMapper cannot be sure that >>> getServiceUserID will find a registered mapping even if that mapping has >>> been configured. For example if a component starts roughly at the same >>> time as the mapping is installed it can happen that the calls the >>> component makes to loginService to fail. More concretely that can happen >>> for example if one needs a session in an activate method to register jcr >>> event listener, or to read some configuration properties from the >>> repository. >>> >>> In order to make this behavior more predictable I created an issue [1] >>> proposing to always register an osgi service (I called it >>> ServiceUserMapping) right after a mapping is installed, such that consumer >>> components can reference it and wait for the mapping to be available. I >>> also worked out an implementation in [2]. >>> >>> First, I would like to ask you if you think the problem is valid and if >>> the approach is correct? >>> Second, it will be really helpful if you can also comment on the issue >>> around the provided implementation. >>> >>> I hadn't the time to look into the implementation but I have this use case >>> right now. A service user mapping and a bundle with a service which relies >>> on this mapping are deployed in a (AEM) package - service fails because of >>> mapping not yet available when service gets activated. A ServiceUserMapping >>> service as reference would solve this problem. So +1 for this approach and >>> the name ServiceUserMapping. >>> >>> a valid alternative that will end up to a NOOP for SLING-4312 is to use >>> Sling initial content in the same bundle rather than a package. >> >> hi Antonio, >> >> we have a dedicated bundle (with Sling-Initial-Content) for configurations >> and >> IMHO service user mappings (as well as other global configurations) should >> be >> kept at a single place and not spread around in different application >> bundles. > > in general I do agree with you. This can be an exception though (hence why we > introduced the concept of mapping amendments aka > https://issues.apache.org/jira/browse/SLING-3578) >
I don't think that initial content solves the problem. What happens if an administrator of the system reconfigures the mapping, removes it, changes it? In that case the service is still active but does not work - at least not for the time of reconfiguration. OSGi configurations are dynamic and we should accept this fact. Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
