|
||||||||
|
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 |
||||||||
_______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
The first page is outdated, and I moved it to our Attic.
The second page (and subpages) is our design and should be your main resource to look at.
The third page was a specific analysis that lead to the design. Only interesting if you want to follow our thinking, but not necessarily up to date (or meant as docs for users of multi-tenancy).
Not describing that header is an omission, I will add that to the document. In short, it determines if a bundle should provide only a platform tenant, only normal tenants or both.
Bundles cannot be both multi- and single-tenant, so indeed you need to split any bundles that currently are both.
To answer your general question about clear documentation for designing a multi-tenant bundle, I would like to point out that you should probably start by writing a bundle that does not explicitly deal with tenants at all. That should be the starting point for any bundle you develop as part of Amdatu. The next step is to then wrap this bundle using the headers we documented (and we have examples of third party bundles like ConfigurationAdmin and HttpService that demonstrate how that works: it does not involve changing any code, just the pom.xml and some headers). In a lot of cases, this should be enough, and you never ever have to work with the multi-tenancy API directly.
In special cases, you might want to optimize how you want the multi-tenant version of the bundle to work. In those cases, we would appreciate it if you could explain us why, so we help you decide if you're going in the right direction. An area where we predict that you might want to write such code is when you have a bundle that maintains persistent state outside of the bundle cache. On the other hand, our general view on such "storage" services is that most of them will have their (clustered) server parts run outside of Amdatu anyway, with only the client side being packaged in a bundle.