Hi, While probably similarly off-topic, I have just written down another idea in this area: support for multitenancy [1]. The idea is, that at the beginning of a request, based on various request input (URL, authenticated user, etc.) a Tenant might be selected for the request, which may then influence how the request will be handled.
One such influence would be ResourceResolver.getSearchPath() depending on the the actual Tenant. Others are conceivable and possible by just declaring a Tenant to provide a set of key-value pairs. Regards Felix [1] http://cwiki.apache.org/SLING/multitenancy-support.html Pontus Amberg schrieb: > This is not really a reply to your question but I just wanted to mention > that I think that it is possible to map specific parts of the content > tree to specific domains/sites [1] . Haven't tested it myself but it > looks pretty cool. > > /Pontus > > [1] https://issues.apache.org/jira/browse/SLING-249 > > John Crawford wrote: >> Also, what about if I want to host many sites? I can see clustering the >> sites together by template. So if Brands A,B and C want a specific >> layout >> or set of components, give them server running on 8081. Perhaps >> Brands D, E >> and F want a completely different layout / set of components, give them >> server 8082. All sites could on the same repository just as easily (and >> probably easier), but I could see it getting out of hand with 80+ sites. >> >> I guess my question is one of scalability. Is it recommended to have >> more >> than say ten sites on one instance? And is it better to only have one >> instance / physical hardware? >> >> Respectfully, >> John >> >> >> On Mon, Apr 6, 2009 at 8:46 AM, John Crawford <[email protected]> wrote: >> >> >>> Hi Bertrand, >>> >>> Thank you for the reply, it definitely makes sense. >>> >>> The separation was primarily for 1) the main website 2) an >>> administrative >>> type of area and then 3) a clients section where they can place >>> orders and >>> have access to their private data (transaction handled by application >>> server). The admin area almost doesn't even need to have a backing >>> repository (except for the fact that it's gated -- security). I >>> would just >>> rely on the post servlet to handle my writing and the json servlet to >>> gather >>> the data. Another thing, in production, I would want to restrict the >>> post >>> servlet to only the requests made inside of my network (in your >>> experience, >>> do you find this to be the best solution to protecting the data on >>> live?). >>> I could definitely see it being in one repository, just different >>> content >>> paths, but thought having separate instances might help with >>> performance/modularity (please correct me if I'm wrong). >>> >>> In one of David Neuschler's blog entries or articles (I believe thats >>> the >>> source), I read that workspaces were more for replicas/copies of data >>> (such >>> as an author/publish environment), but I have had some thoughts about >>> separating domain content in there as well (but haven't due to David's >>> posts). I guess he primarily wants to eliminate as much overhead as >>> possible, so perhaps thats the reason for his statement and it seemed to >>> align with your suggestions below as well. >>> >>> Thank you again. >>> >>> Respectfully, >>> John >>> >>> >>> On Mon, Apr 6, 2009 at 7:37 AM, Bertrand Delacretaz < >>> [email protected]> wrote: >>> >>> >>>> Hi John, >>>> >>>> On Mon, Apr 6, 2009 at 4:09 AM, John Crawford <[email protected]> >>>> wrote: >>>> >>>>> I'm in the process of implementing a site that is basically >>>>> comprised of >>>>> three independent modules, however, I want them to interact on some >>>>> >>>> level.... >>>> >>>> >>>>> ...I'm trying to decide if it's best practice to have one repository >>>>> >>>> with 3 >>>> >>>>> different workspaces (which will need to interact) or if it's >>>>> better to >>>>> >>>> have >>>> >>>>> multiple repos with different RMI ports (thus, non-standard). >>>>> >>>> Eventually, I >>>> >>>>> may have these on separate machines, but certainly no need at this >>>>> >>>> time.... >>>> >>>> I'd start by even questioning the need for separate workspaces...the >>>> content of your three modules might simply be under separate paths in >>>> a single repository, and you can use sling resource types to >>>> differentiate between them. >>>> >>>> Next step, if you really need it, might be to have each module in its >>>> own workspace. This would require less coordination between the teams >>>> designing each module, and might make it easier to manage strict >>>> separation of access rights, but apart from that I'm not sure what the >>>> advantages are. >>>> >>>> Interaction between the modules can be much easier with a single >>>> workspace. Using JCR observation on repository subtrees works quite >>>> well for inter-module communications. >>>> >>>> I don't usually see a need at the application level for separate >>>> repositories, the need might come from environment / admin / security >>>> requirements, but if you can avoid that it's probably easier. >>>> >>>> >>>>> ...Also, is there any other gotchas or good practices I should >>>>> follow in >>>>> >>>> this >>>> >>>>> area during my implementation?... >>>>> >>>> Not sure what you mean by "this area", but the choice of a single or >>>> multiple workspaces will have a big impact on your code. >>>> >>>> Hope this helps, and if not feel free to ask, maybe with a bit more >>>> details about your requirements. >>>> >>>> -Bertrand >>>> >>>> >>> >> >> > >
