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 so
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 aspect that "all" need to
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 :) At
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
>> (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
>> (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 consi
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
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 main goal of ServiceUse
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
Serv
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 p
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 components wait
at star
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 not a good idea to exp
>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 registry
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 remov
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
>>>
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
>>>
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 th
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.
>
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 use
19 matches
Mail list logo