Re: Setting the context path using the launchpad
Hi, Am 10.11.2012 um 22:24 schrieb Robert Munteanu: Just to complete the below information, updating the version of the org.apache.felix.http.jetty bundle only works when it is set in the maven-launchpad-plugin configuration/jarWebSupport element. This seems a bit strange to me, should I file a bug? No, this is by intent: Http Service support is specific to whether the Sling Launchpad is built as a Java Application (in which case the Jetty based Http Service is used) or a Web Application (in which case the Http Service bridge is used). The bundle list is used for the rest of the system, which does not care about these deployment details. Regards Felix Robert I've noticed that indeed the updated configuration properties are only available for org.apache.felix.http.jetty 2.2.1-SNAPSHOT for now. I've tried including the updated http bundle in the launchpad, but that seems to have no effect. I've tried: - configuring the maven-launchpad-plugin configuration defaultBundleList version6/version /defaultBundleList additionalBundles bundle groupIdorg.apache.felix/groupId artifactIdorg.apache.felix.http.jetty/artifactId version2.2.1-SNAPSHOT/version !-- pick up fixes for setting context path and bind host -- /bundle /additionalBundles /configuration - updating the list.xml bundle list startLevel level=5 bundle groupIdorg.apache.felix/groupId artifactIdorg.apache.felix.http.jetty/artifactId version2.2.1-SNAPSHOT/version !-- pick up fixes for setting context path and bind host -- /bundle /startLevel but they both have the same result: $ find target/classes/resources/ -name org.apache.felix.http.jetty\* target/classes/resources/bundles/0/org.apache.felix.http.jetty-2.2.0.jar What am I doing wrong? Thanks, Robert Regards Felix
Re: Multi-tenancy support in Sling - SLING-2656
Hi Amit
Thanks for taking a stab at multi-tenancy support. I have looked at
your patch and I re-read Felix' draft spec on the wiki[0].
The code and the spec leave me with some thoughts. Sorry for the
lengthy reply, the thoughts are still pretty fresh in my mind.
The spec states that multi-tenancy support is targeted to a hosted
scenario, where several Sling applications (let's simplify to
websites) run side by side. I think this can easily be extended to
cases where a large corporation runs websites of several brands on the
same Sling instance. Assuming our brands are banana, kiwi and
lemon, we'd have a content structure like this:
tenants: {
banana: { ... },
kiwi: { ... },
lemon: { ... }
}
The main purpose of multi-tenancy support (as per my interpretation of
the spec) is to be able to use different rendering scripts for
different tenants, which is expressed via the concept of the
ResourceResolver(Factory)#searchPath.
Assuming we want the banana and lemon websites to be rendered with
the yellow application and the kiwi website with the green
application (and assuming we don't use CSS for this...), we might want
our rendering scripts organized like this:
apps: {
yellow: { ... },
green: { ... },
shared: { ... }
}
As far as I can see, the currently committed code doesn't enhance the
search paths yet. However, it looks like it is intended that tenants
get resolved mapped from the paths of any of the following:
* user home path (e.g. /home/users/banana/julian; this is kind of CQ
specific, afaik jackrabbit still uses the system workspace for users
by default, so there's no /home/users)
* resource path (e.g. /tenants/kiwi)
So if I request the page /tenants/kiwi logged in as julian, I could
get two different resolutions, depending on whether the implementation
adapts the Resource (/tenants/kiwi), which leads to the tenant green
or the ResourceResolver backed by the user julian, which leads to the
tenant yellow.
Considering that most requests to websites are anonymous, I suggest
that multi-tenancy support should only care about the resource being
requested, not about the requesting user, This also guarantees
consistent results for rendering.
Looking at the problem from this angle, script resolution (i.e.
looking up the resource type relative path) needs depend on the
location of the requested resource. This in turn rules out the
possibility to adapt a ResourceResolver to a tenant, because the RR
does not have a path. Also setting injecting the search path into the
RR is troublesome, because /tenants/kiwi might include resources from
/tenants/banana by reference and would thus need to trigger the
yellow rendering for these includes (or are there arguments against
this?).
Given the above thoughts, I would allow adapting a Resource to a
Tenant. The Tenant would correspond to the Resource itself or to an
ancestor of the Resource (i.e. hierarchical inheritance). Since the
tenant would thus correspond to a Resource, maybe it makes sense to
have the Tenant interface extend from Resource. If no Tenants are
configured, the attempt to adapt a Resource to a tenant may return
null or a default Tenant, which is rooted at the resource tree's root
(maybe this would simplify implementations).
All of this raises the question of the consistency of search paths, as
the ResourceResolver cannot convey tenant specific search paths,
however the script resolution would need to depend upon tenant
specific search paths. To me it seems that multi-tenancy support might
require the extension of some sling concepts. This extension could
(and should IMHO) be implemented as a hook, which allows to manipulate
script resolution. Having such a hook should decouple the
multi-tenancy implementation from the core of sling and possibly allow
for alternative implementations.
WDYT?
Regards
Julian
[0] https://cwiki.apache.org/SLING/multitenancy-support.html
On Mon, Nov 12, 2012 at 3:35 AM, Amit.. Gupta. amitg...@adobe.com wrote:
Thanks Felix.
I will work on the web console plugin.
Thanks,
Amit
-Original Message-
From: Felix Meschberger [mailto:fmesc...@adobe.com]
Sent: 10 November 2012 04:23
To: users@sling.apache.org
Subject: Re: Multi-tenancy support in Sling - SLING-2656
Hi Amit
Thanks alot. I have applied your patch with some changes (see SLING-2656 for
details). I placed it as th extensions/tenant module in the contrib section
for now. As of now it only provides the Tenant API but no integration with
the rest in Sling. As such it is of use mainly to multi-tenancy aware uses.
I think we should just provide read access through the TenantProvider and
leave management (create, update, delete) to some administrative tooling;
e.g. a web console plugin.
I also removed the default configuration which does not relate to Sling.
Would you be able to come up with a Web Console Plugin for management ?
Regards
Felix
Am 08.11.2012 um 11:03 schrieb Amit.. Gupta.:
Hi All,
I
Re: Multi-tenancy support in Sling - SLING-2656
Hi Julian
Am 12.11.2012 um 10:33 schrieb Julian Sedding:
Hi Amit
Thanks for taking a stab at multi-tenancy support. I have looked at
your patch and I re-read Felix' draft spec on the wiki[0].
The code and the spec leave me with some thoughts. Sorry for the
lengthy reply, the thoughts are still pretty fresh in my mind.
The spec states that multi-tenancy support is targeted to a hosted
scenario, where several Sling applications (let's simplify to
websites) run side by side.
Yes, that was an initial though. But running different applications for
different tenants is a tricky thing because the Java platform does not allow
use to properly sandbox those applications and thus to prevent on application
from starving another application.
For now, only the TenantProvider/Tenant part is implemented and we did not
consider the tenant-specific ResourceResolution yet.
I think this can easily be extended to
cases where a large corporation runs websites of several brands on the
same Sling instance. Assuming our brands are banana, kiwi and
lemon, we'd have a content structure like this:
tenants: {
banana: { ... },
kiwi: { ... },
lemon: { ... }
}
The main purpose of multi-tenancy support (as per my interpretation of
the spec) is to be able to use different rendering scripts for
different tenants, which is expressed via the concept of the
ResourceResolver(Factory)#searchPath.
Assuming we want the banana and lemon websites to be rendered with
the yellow application and the kiwi website with the green
application (and assuming we don't use CSS for this...), we might want
our rendering scripts organized like this:
apps: {
yellow: { ... },
green: { ... },
shared: { ... }
}
As far as I can see, the currently committed code doesn't enhance the
search paths yet. However, it looks like it is intended that tenants
get resolved mapped from the paths of any of the following:
* user home path (e.g. /home/users/banana/julian; this is kind of CQ
specific, afaik jackrabbit still uses the system workspace for users
by default, so there's no /home/users)
* resource path (e.g. /tenants/kiwi)
So if I request the page /tenants/kiwi logged in as julian, I could
get two different resolutions, depending on whether the implementation
adapts the Resource (/tenants/kiwi), which leads to the tenant green
or the ResourceResolver backed by the user julian, which leads to the
tenant yellow.
I think if you are logged in, you are being run under the hood of the tenant to
which you as the logged in user belong. So in your case, the tenant would be
green.
As a member of the green tenant you might not even have access the kiwi tree.
In which case, there is no reason to assume the request resource path to be the
tenant to consider.
As a consequence, I agree, that the anonymous user by itself is not running
under the hood of a tenant.
Considering that most requests to websites are anonymous, I suggest
that multi-tenancy support should only care about the resource being
requested, not about the requesting user, This also guarantees
consistent results for rendering.
This (and the following) raise good questions. And we are not ready to answer
them (yet) and we are not even considering per-tenant applications (for above
stated reasons).
So we left out tenant-awareness of the ResourceResolver by intent.
Looking at the problem from this angle, script resolution (i.e.
looking up the resource type relative path) needs depend on the
location of the requested resource. This in turn rules out the
possibility to adapt a ResourceResolver to a tenant, because the RR
does not have a path. Also setting injecting the search path into the
RR is troublesome, because /tenants/kiwi might include resources from
/tenants/banana by reference and would thus need to trigger the
yellow rendering for these includes (or are there arguments against
this?).
Given the above thoughts, I would allow adapting a Resource to a
Tenant. The Tenant would correspond to the Resource itself or to an
ancestor of the Resource (i.e. hierarchical inheritance). Since the
tenant would thus correspond to a Resource, maybe it makes sense to
have the Tenant interface extend from Resource. If no Tenants are
configured, the attempt to adapt a Resource to a tenant may return
null or a default Tenant, which is rooted at the resource tree's root
(maybe this would simplify implementations).
Even though a Tenant may correspond a Resource (which is wrong, because at best
a Resource corresponds to a Tenant) this does not imply a Tenant is a Resource.
Because this is an implementation detail of implementing the Tenant interface.
The Tenant interface is just representing a concept of a collection of users
sharing some common setup.
All of this raises the question of the consistency of search paths, as
the ResourceResolver cannot convey tenant specific search paths,
however the script
RE: Setting the context path using the launchpad
-Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: Monday, November 12, 2012 10:10 AM To: users@sling.apache.org Subject: Re: Setting the context path using the launchpad Hi, Am 10.11.2012 um 22:24 schrieb Robert Munteanu: Just to complete the below information, updating the version of the org.apache.felix.http.jetty bundle only works when it is set in the maven- launchpad-plugin configuration/jarWebSupport element. This seems a bit strange to me, should I file a bug? No, this is by intent: Http Service support is specific to whether the Sling Launchpad is built as a Java Application (in which case the Jetty based Http Service is used) or a Web Application (in which case the Http Service bridge is used). The bundle list is used for the rest of the system, which does not care about these deployment details. Thanks for clarifying the reasons behind this behaviour. I've filed an enhancement request for the documentation though, since I think it is helpful to mention this bit of information SLING-2658: Document that the bundle list does not allow selection of the HttpService provider https://issues.apache.org/jira/browse/SLING-2658 Robert Regards Felix Robert I've noticed that indeed the updated configuration properties are only available for org.apache.felix.http.jetty 2.2.1-SNAPSHOT for now. I've tried including the updated http bundle in the launchpad, but that seems to have no effect. I've tried: - configuring the maven-launchpad-plugin configuration defaultBundleList version6/version /defaultBundleList additionalBundles bundle groupIdorg.apache.felix/groupId artifactIdorg.apache.felix.http.jetty/artifactId version2.2.1-SNAPSHOT/version !-- pick up fixes for setting context path and bind host -- /bundle /additionalBundles /configuration - updating the list.xml bundle list startLevel level=5 bundle groupIdorg.apache.felix/groupId artifactIdorg.apache.felix.http.jetty/artifactId version2.2.1-SNAPSHOT/version !-- pick up fixes for setting context path and bind host -- /bundle /startLevel but they both have the same result: $ find target/classes/resources/ -name org.apache.felix.http.jetty\* target/classes/resources/bundles/0/org.apache.felix.http.jetty-2.2.0.jar What am I doing wrong? Thanks, Robert Regards Felix
Re: Multi-tenancy support in Sling - SLING-2656
On 12.11.2012, at 10:55, Felix Meschberger fmesc...@adobe.com wrote: Considering that most requests to websites are anonymous, I suggest that multi-tenancy support should only care about the resource being requested, not about the requesting user, This also guarantees consistent results for rendering. This (and the following) raise good questions. And we are not ready to answer them (yet) and we are not even considering per-tenant applications (for above stated reasons). I'd agree with Julian. A tenant should be dependent on something clearly defined through the URL: e.g. the domain / Host header or a URL path, such as domain.com/tenant. So it's essentially request-dependent, not necessarily user or content dependent. Otherwise it would also overlap too much with ACLs. * A ResourceResolver representing a user (just like JCR Session does) can be adapted to a Tenant to which the user belongs. Hmm, I am not sure if a user belongs to a (single) tenant. What if a user should be able to log into multiple tenants? For example, an agency with multiple customers (who are tenants) or just the admin users of the site provider. * A Resource can be adapted to a Tenant under the assumption that the respective Resource belongs to one of the Tenant's data areas in the repository. What if there are shared resources? You probably need the resources from a request-specific resource resolver, which in turn handles the request-dependent tenant resolution, so you get the right tenant from the resource based on that, but not based on the resource's location. Cheers, Alex
Re: Multi-tenancy support in Sling - SLING-2656
Hi Felix
On Mon, Nov 12, 2012 at 10:55 AM, Felix Meschberger fmesc...@adobe.com wrote:
Hi Julian
Am 12.11.2012 um 10:33 schrieb Julian Sedding:
Hi Amit
Thanks for taking a stab at multi-tenancy support. I have looked at
your patch and I re-read Felix' draft spec on the wiki[0].
The code and the spec leave me with some thoughts. Sorry for the
lengthy reply, the thoughts are still pretty fresh in my mind.
The spec states that multi-tenancy support is targeted to a hosted
scenario, where several Sling applications (let's simplify to
websites) run side by side.
Yes, that was an initial though. But running different applications for
different tenants is a tricky thing because the Java platform does not allow
use to properly sandbox those applications and thus to prevent on application
from starving another application.
For now, only the TenantProvider/Tenant part is implemented and we did not
consider the tenant-specific ResourceResolution yet.
So if you are omitting the main feature of tenants as described in
Problem Scope in the draft specification[0] (Here you might want to
separate the resolution of resources for each client.), why call the
feature multi-tenancy support, why reference the specification and
why implement the interfaces described in the specification? The
problem scope statement does not mention the requirement to sand-box
applications. While I understand that sand-boxing may be desirable (or
even required) for some use-cases, it certainly is not necessary for
every use-case (e.g. one company runs several brand web-sites on the
same Sling instance).
Multi-tenancy support can certainly encompass a multitude of features
that are provided per-tenant. Script resolution is one of them,
tenant-specific users may be another one. Unfortunately the discussion
of what multi-tenancy support should mean in Sling has not happened
(yet?) on this mailing list.
[0] https://cwiki.apache.org/SLING/multitenancy-support.html
I think this can easily be extended to
cases where a large corporation runs websites of several brands on the
same Sling instance. Assuming our brands are banana, kiwi and
lemon, we'd have a content structure like this:
tenants: {
banana: { ... },
kiwi: { ... },
lemon: { ... }
}
The main purpose of multi-tenancy support (as per my interpretation of
the spec) is to be able to use different rendering scripts for
different tenants, which is expressed via the concept of the
ResourceResolver(Factory)#searchPath.
Assuming we want the banana and lemon websites to be rendered with
the yellow application and the kiwi website with the green
application (and assuming we don't use CSS for this...), we might want
our rendering scripts organized like this:
apps: {
yellow: { ... },
green: { ... },
shared: { ... }
}
As far as I can see, the currently committed code doesn't enhance the
search paths yet. However, it looks like it is intended that tenants
get resolved mapped from the paths of any of the following:
* user home path (e.g. /home/users/banana/julian; this is kind of CQ
specific, afaik jackrabbit still uses the system workspace for users
by default, so there's no /home/users)
* resource path (e.g. /tenants/kiwi)
So if I request the page /tenants/kiwi logged in as julian, I could
get two different resolutions, depending on whether the implementation
adapts the Resource (/tenants/kiwi), which leads to the tenant green
or the ResourceResolver backed by the user julian, which leads to the
tenant yellow.
I think if you are logged in, you are being run under the hood of the tenant
to which you as the logged in user belong. So in your case, the tenant would
be green.
No, it would be yellow. But that's not the point, the point is that
rendering the same content might lead to different script resolution.
This feels very awkward to me.
As a member of the green tenant you might not even have access the kiwi
tree. In which case, there is no reason to assume the request resource path
to be the tenant to consider.
I would avoid mixing up the concept of tenants and access control.
They are certainly complementary, but the user julian may equally well
have access to /tenants/kiwi. In that case we need to answer the
question if the tenant is identified by the logged in user or by the
content tree being rendered.
As a consequence, I agree, that the anonymous user by itself is not running
under the hood of a tenant.
Considering that most requests to websites are anonymous, I suggest
that multi-tenancy support should only care about the resource being
requested, not about the requesting user, This also guarantees
consistent results for rendering.
This (and the following) raise good questions. And we are not ready to answer
them (yet) and we are not even considering per-tenant applications (for above
stated reasons).
I hope that we can approach answering some of those questions on the
mailing
Re: Multi-tenancy support in Sling - SLING-2656
Hi Alex On Mon, Nov 12, 2012 at 1:07 PM, Alexander Klimetschek aklim...@adobe.com wrote: On 12.11.2012, at 10:55, Felix Meschberger fmesc...@adobe.com wrote: Considering that most requests to websites are anonymous, I suggest that multi-tenancy support should only care about the resource being requested, not about the requesting user, This also guarantees consistent results for rendering. This (and the following) raise good questions. And we are not ready to answer them (yet) and we are not even considering per-tenant applications (for above stated reasons). I'd agree with Julian. A tenant should be dependent on something clearly defined through the URL: e.g. the domain / Host header or a URL path, such as domain.com/tenant. So it's essentially request-dependent, not necessarily user or content dependent. Otherwise it would also overlap too much with ACLs. * A ResourceResolver representing a user (just like JCR Session does) can be adapted to a Tenant to which the user belongs. Hmm, I am not sure if a user belongs to a (single) tenant. What if a user should be able to log into multiple tenants? For example, an agency with multiple customers (who are tenants) or just the admin users of the site provider. I agree. For designing multi-tenancy support, we should assume that a user may belong to several tenants. Support for the single tenant case would thus be implied. * A Resource can be adapted to a Tenant under the assumption that the respective Resource belongs to one of the Tenant's data areas in the repository. What if there are shared resources? You probably need the resources from a request-specific resource resolver, which in turn handles the request-dependent tenant resolution, so you get the right tenant from the resource based on that, but not based on the resource's location. That's a good question, which I cannot currently answer. I think you can find arguments for rendering this resource based on the request-resource's tenant or on the resource's tenant itself. Maybe this would need to be controllable by the user of the API, e.g. by indicating the desired strategy when including a resource. Cheers, Alex Regards Julian
