Hi List, as requested by Angelo :) Here are my notes from last weeks meeting just to get them on record.
1) On the Amdatu 0.1.0 release This release contains some important features and bug fixes for projects that are currently at 0.0.5 / 0.0.6. Therefore we should not stall the release pending long running discussions on multi-tenancy, provisioning etc. We agreed to try and get the release out around febrauri first and identified the following TODOs and owners (details in JIRA). * Cassandra clustering support (IvoL / MUST HAVE) ** Document mechanism on the wiki ** Support deployment, configuration and backup strategies * Finish Multi-Tenancy 1.0 (BramK / MUST HAVE) ** Document Mechanisms on the wiki ** Multi-Tenant UserAdmin (PAX useradmin extender pattern) ** Multi-Tenant Resolver (basic first version) ** Multi-Tenant Shindig REST services (ThreadLocal workaround) ** Multi-Tenant UserAdmin REST services (RequestContext workaround) * JAX-RS init problem resolution (Angelo / MUST HAVE) ** Doument mechanism on the wiki ** use Activator Dependecy strategy ** Submit this to Felix (Dependency Manager)? * MetaType imlementation for configuration (Angelo / SHOULD HAVE) ** Document Mechanisme on wiki ** Implement for Logging / HttpService / etc.. ? * Remove FS Storage code redundancy (BramK / SHOULD HAVE) 2) On the Amdatu 0.2.0 release This release must focus on an initial solution for provisioning as projects will require it soonish. Providing this along with some project infrastructure tasks and bugfixing will probably make a well rounded 0.2.0 to be delivered at the beginning of march. 3) On the JAX-RS discussion Mainly discussed two solutions that have been on the mailing list before. Decided in favor of activator dependency strategy as oposed to adding vendor specific packages to bootdelegation. 4) On the context discussion As seen on the mailing list and in JIRA. Mainly discussed wether a threadlocal based strategy for providing omnipresent pluggable context information to services is desireable, doable and what the alternatives are. Conclusion is that it is not our principle mechanism (tenant aware services are) and it has too many drawbacks (no way to deal with async) and/or open questions to promote to an official mechanism. However it may (and probably must) be used in some cases to workaround 3rd party software design limitations (eg. Shindig using Guice injection). It shall however remain an implementation detaiil and responsibility to those modules. 5) On the web resolver Basic mechanism should be something like... * Intercept request (probably all) / handle exceptions * General security/sanity checks / handle exceptions * Resolve to tenant and its config / handle exceptions * Determine target (availability/validaty) / handle exceptions x) QoS could come in here at some point * Add context info to Request * Dispatch -> / handle exceptions * <- Response / handle exceptions Feedback on the proceedings is welcome. For discussions on design/implementation details please find/start and appropriate on topic thread or JIRA issue. Regards, Bram
