On 22.04.13 13:24, "Carsten Ziegeler" <[email protected]> wrote:
>Ah just noticed the second part: >" * 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." > >There is nothing about a request in this interface, so I think this should >be changed? Yes ;-) Regards Felix > >Carsten > > > >2013/4/22 Carsten Ziegeler <[email protected]> > >> 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? >> >> Carsten >> >> >> 2013/4/22 Felix Meschberger <[email protected]> >> >>> Hi >>> >>> Maybe we should have this discussion on the list ? >>> >>> On 22.04.13 12:13, "Carsten Ziegeler (JIRA)" <[email protected]> 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 >> [email protected] >> > > > >-- >Carsten Ziegeler >[email protected]
