Konrad Windszus wrote > There is indeed a very valid use case for ServiceUserMapped and that is using > the service resolver in the activate() method. > If the configuration or system user is not available at that point, the > activate() fails with an exception and the component is never being restarted > (even if at a later point in time both configuration and the bound system > user is there).
That's true - but even if ServiceUserMapped is available it gives you zero guarantee that the service user is really registered in the repository. So your component can still fail and never gets activated. Right now this works under the assumption that all service users are there when the repository starts. But thats a faulty assumption. Or if people think it's a valid one, I can argue that the assumption of configurations being there holds true as well. In which case the ServiceUserMapped service is not needed. > This functionality is IMHO crucial, because at least during development it > could be that the configuration mapping is not yet provided when the service > would be first started. Just failing once and never retry again, is IMHO > against all OSGi services practice. So having an explicit dependency against > that feels right. Ok, so I could argue that we make production difficult to make development easy :) > If it is too complicated to check for the existence of the service user we > could at least keep the current dependency, which enforces that the service > is not started until at least the configuration is available. This is very > helpful and should not be removed. This is were I don't agree as it provides a wrong perception. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
