On Thu, Sep 25, 2008 at 3:17 AM, Brian Eaton <[EMAIL PROTECTED]> wrote:
> social-api folks: the proposal below for how to configure shindig to > use real security tokens requires that the social-api side of the > shindig tree inject a ContainerConfig object. The gadgets side of the > code base currently gets the ContainerConfig by: > > - reading java/gadgets/conf/gadgets.properties > - extracting shindig.containers.default from that > - injecting a ContainerConfig based on shindig.containers.default. > > Any objections to this happening on the social-api side as well? Is > there an alternative mechanism that would work better? The social-api code already depends on ContainerConfig (by way of auth code). We could always re-invent the container mechanism for the 4th or 5th time though. > > > On Wed, Sep 24, 2008 at 5:03 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > On Wed, Sep 24, 2008 at 3:11 AM, Brian Eaton <[EMAIL PROTECTED]> wrote: > > > >> I just checked in a couple of classes that provide real security > >> tokens, configured per-container. They are, for the moment, dead > >> code. I don't want to remove the default usage of > >> BasicSecurityTokenDecoder, because easy testing is too useful. > >> > >> Any thoughts on how Shindig java deployments should opt-in to using > >> these classes? Hand-written Guice modules? Configuration in > >> containers.js? > >> > > > > container configuration is the way to go. It's actually pretty easy: > > > > - bind all possible variants with symbolic names (the class names are as > > good as any) > > - decoder code dispatches to appropriate variant based on container name. > > > > Making people write Guice modules is a non-starter. Shindig should be > able > > to be used without writing any code. > > >
