Re: Revisiting ServiceUserMapped

Marius Petria wrote > Hi, > > Do we need an additional interface to check for user existence, or could we > just treat it as a special case of validity by using the ServiceUserValidator? > I think it's easier :) We can just try to login to the resource resolver factory. If it fails, there is

Re: Revisiting ServiceUserMapped

Hi, Do we need an additional interface to check for user existence, or could we just treat it as a special case of validity by using the ServiceUserValidator? Marius On 5/12/17, 7:14 PM, "Carsten Ziegeler" wrote: Julian Sedding wrote > > Interesting

Re: Revisiting ServiceUserMapped

Julian Sedding wrote > > Interesting aspect that "all" need to have the service user. I had > assumed "at least one" resource provider needs to have the service > user. > > Both "all" and "at least one" are heuristics, because we don't know > what the service-user will access. Not exactly :)

Re: Revisiting ServiceUserMapped

On Fri, May 12, 2017 at 9:56 AM, Carsten Ziegeler wrote: > Julian Sedding wrote >> Definitely +1 on doing this right. >> >> Regardless of the above, the goals I read in this thread are the following: >> - only register a service if the required service-user is available >>

Re: Revisiting ServiceUserMapped

On Fri, May 12, 2017 at 9:56 AM, Carsten Ziegeler wrote: > Julian Sedding wrote >> Definitely +1 on doing this right. >> >> Regardless of the above, the goals I read in this thread are the following: >> - only register a service if the required service-user is available >>

Re: Revisiting ServiceUserMapped

Julian Sedding wrote > Definitely +1 on doing this right. > > Regardless of the above, the goals I read in this thread are the following: > - only register a service if the required service-user is available > (ServiceUserMapped) > - announce service-users lazily > > An implementation could

Re: Revisiting ServiceUserMapped

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

Re: Revisiting ServiceUserMapped

Bertrand Delacretaz wrote > Hi, > > On Thu, May 11, 2017 at 9:39 AM, Carsten Ziegeler > wrote: >> ...Service users are a very low level >> configuration of the data store and we could assume that this is >> correctly configured - as well as the mapping... > > I think the

Re: Revisiting ServiceUserMapped

Definitely +1 on doing this right. Regardless of the above, the goals I read in this thread are the following: - only register a service if the required service-user is available (ServiceUserMapped) - announce service-users lazily An implementation could consist of a component, let's call it

Re: Revisiting ServiceUserMapped

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

Re: Revisiting ServiceUserMapped

Hi, On Thu, May 11, 2017 at 9:39 AM, Carsten Ziegeler wrote: > ...Service users are a very low level > configuration of the data store and we could assume that this is > correctly configured - as well as the mapping... I think the main goal of ServiceUserMapped is to have

Re: Revisiting ServiceUserMapped

Hi Carsten, 2017-05-11 9:39 GMT+02:00 Carsten Ziegeler : > From the few responses in this thread I have the feeling that the > preference is on implementing this correctly. > > However, we're still lacking a good idea on how exactly to implement this. > > Now, I think it is

Re: Revisiting ServiceUserMapped

>From the few responses in this thread I have the feeling that the preference is on implementing this correctly. However, we're still lacking a good idea on how exactly to implement this. Now, I think it is not a good idea to expose each and every service user as a service in the service

Re: Revisiting ServiceUserMapped

Carsten Ziegeler wrote > Robert Munteanu wrote >> On Tue, 2017-05-09 at 09:41 +0200, Oliver Lietz wrote: There is the assumption that if such a mapping is available the underlying service user is available as well - which unfortunately is wrong. In this sense we could also

Re: Revisiting ServiceUserMapped

Robert Munteanu wrote > On Tue, 2017-05-09 at 09:41 +0200, Oliver Lietz wrote: >>> There is the assumption that if such a mapping is available the >>> underlying service user is available as well - which unfortunately >>> is >>> wrong. In this sense we could also remove the whole concept again >>>

Re: Revisiting ServiceUserMapped

Robert Munteanu wrote > On Tue, 2017-05-09 at 09:41 +0200, Oliver Lietz wrote: >>> There is the assumption that if such a mapping is available the >>> underlying service user is available as well - which unfortunately >>> is >>> wrong. In this sense we could also remove the whole concept again >>>

Re: Revisiting ServiceUserMapped

On Tue, 2017-05-09 at 09:41 +0200, Oliver Lietz wrote: > > There is the assumption that if such a mapping is available the > > underlying service user is available as well - which unfortunately > > is > > wrong. In this sense we could also remove the whole concept again > > and > > simply assume

Re: Revisiting ServiceUserMapped

On Tuesday 09 May 2017 07:31:53 Carsten Ziegeler wrote: > While working on the "configurationless" Sling, I noticed that the > ServiceUserMapped concept does not only create problems with zero > configurations but is also not working as expected. Right now, it > creates a false sense of safety. >

Revisiting ServiceUserMapped

While working on the "configurationless" Sling, I noticed that the ServiceUserMapped concept does not only create problems with zero configurations but is also not working as expected. Right now, it creates a false sense of safety. It is a good idea to express the requirement of a component to