Great, i've just closed the issue :)
Let's give people a couple of days for further comments and then I'll cut a
release.
2013/4/22 Felix Meschberger <fmesc...@adobe.com>
>
>
> On 22.04.13 13:22, "Carsten Ziegeler" <cziege...@apache.org> wrote:
>
> >Thanks Felix - for the naming while I see minor problems with
> >TenantProvider I don't have a stronge urge to change the name and in lack
> >of a good alternative we can keep it.
> >The separation between the reading and the administrative use case makes
> >sense to me.
> >
> >So what about declaring this done and do a release?
>
> +1 ;-)
>
> Regards
> Felix
>
> >
> >Carsten
> >
> >
> >2013/4/22 Felix Meschberger <fmesc...@adobe.com>
> >
> >> Hi
> >>
> >> Maybe we should have this discussion on the list ?
> >>
> >> On 22.04.13 12:13, "Carsten Ziegeler (JIRA)" <j...@apache.org> wrote:
> >>
> >> >Carsten Ziegeler commented on SLING-2710:
> >> >-----------------------------------------
> >> >
> >> >So we expect only a single provider to be available, right?
> >>
> >> Yes.
> >>
> >> > I think the javadocs need some clarifications in this case.
> >>
> >> Currently it states:
> >>
> >> /**
> >> * The <code>TenantProvider</code> defines the service interface of for
> >>a
> >> sevice
> >> * which may be asked for {@link Tenant tenant instances}.
> >> * <p>
> >> * For now this provider interface provides access to a tenant applying
> >>to
> >> a
> >> * particular request as well as to all tenants known to this provider.
> >> */
> >> @ProviderType
> >>
> >>
> >> >And maybe a different name than TenantProvider - I might be biased but
> >>it
> >> >sounds similar to ResourceProvider where we have a potential set of
> >> >providers and not just a single one.
> >>
> >> I don't have too strong of an opinion regarding the name. But I think
> >>the
> >> distinction between the general (and broder) use of reading tenants as
> >> opposed to the specialized management of tenants warrants having two
> >> separate APIs.
> >>
> >> In any case, there is, of course, also an AdapterFactory for tenants in
> >> the implementation.
> >>
> >> Regards
> >> Felix
> >>
> >> >
> >> >> Define TenantManager API
> >> >> ------------------------
> >> >>
> >> >> Key: SLING-2710
> >> >> URL:
> https://issues.apache.org/jira/browse/SLING-2710
> >> >> Project: Sling
> >> >> Issue Type: New Feature
> >> >> Components: Extensions
> >> >> Reporter: Felix Meschberger
> >> >> Assignee: Felix Meschberger
> >> >> Fix For: Tenant 1.0
> >> >>
> >> >> Attachments: SLING-2710-2.patch, SLING-2710.patch
> >> >>
> >> >>
> >> >> Tenants currently can only be administered (create, update, remove)
> >> >>through the Web Console. In addition the TenantProvider service
> >> >>interface allows for looking tenants up (read).
> >> >> For administrative purposes it would be good to have a TenantManager
> >> >>service interface which allows for these administrative tasks.
> >>Something
> >> >>like:
> >> >> public interface TenantManager extends TenantProvider {
> >> >> Tenant create(String tenantId, Map<String, Object> properties);
> >> >> void setProperty(Tenant tenant, String name, Object value);
> >> >> void remove(Tenant tenant);
> >> >> }
> >> >
> >> >--
> >> >This message is automatically generated by JIRA.
> >> >If you think it was sent incorrectly, please contact your JIRA
> >> >administrators
> >> >For more information on JIRA, see:
> >>http://www.atlassian.com/software/jira
> >>
> >>
> >
> >
> >--
> >Carsten Ziegeler
> >cziege...@apache.org
>
>
--
Carsten Ziegeler
cziege...@apache.org
