I put together a quick prototype to demonstrate what I was thinking and published it here:
https://reviews.apache.org/r/2390/ You should be able to apply that patch to trunk and then build/deploy, and every 30 seconds you should see something on the console from the BlobCrypterSecurityTokenCodec saying that it's changing encryption keys. Note that I only updated the tests enough to get it to compile but not actually pass though so you'll have to build with skipTests=true to try it out. I also put all the stuff that I envisioned as third party code that wouldn't be part of shindig into a "org.thirdparty.code" package so be sure to note the package names when looking through it. --Jesse >-----Original Message----- >From: Stanton Sievers [mailto:ssiev...@us.ibm.com] >Sent: Friday, October 14, 2011 2:11 PM >To: dev@shindig.apache.org >Subject: Re: Container Config / Provider Pattern > >Dan, I don't think we want to type the Classes you've proposed. Imagine a >scenario where I want to create a provider that provides for different >pieces of information: a String, a Boolean, a File, and an int. Typing >would restrict doing that. > >I think the real value of this idea comes into play where there are many >places in the code where people are creating ConfigObservers to listen to >the same config keys. A provider would allow them to not have to worry >about how the config is actually stored. Therefore, making changes, such >as changing the key, would only have to happen in the Provider. Even >changing the type of the config value would be trivial in this case >because the Provider gives you that layer of abstraction. > >-Stanton > > > >From: Dan Dumont/Westford/IBM@Lotus >To: dev@shindig.apache.org, >Cc: "Ciancetta, Jesse E." <jc...@mitre.org>, Stanton >Sievers/Westford/IBM@Lotus >Date: 10/14/2011 13:40 >Subject: Container Config / Provider Pattern > > > >I think we should probably move this to the dev list and out of the >review. >For those interested, the conversation started here: >https://reviews.apache.org/r/2362/ > >Jesse, I agree something should be done to make dealing with the container > >config easier. I just don't think it's going to be possible for us to >make this generic enough so that a ContainerConfig would be able to drive >this setting (security token key) and many other changes as well. To me, > >that sounds like... "config driven implementation" in my mind. I don't > >know if that's practical in shindig. > >If we did something like that, we would need a hardened interface and >extension pattern for being able to control the types of returned >values... So the ContainerConfig would return a byte[]? >Having the interpretation of how the config value is something I'd rather >leave up to the particular implementation. > >For instance, in Stanton's review, they default key provider is container >specific... But I really don't see why an encryption key would really >need to be container specific. If the default impl is set up that way we >want to cope, but the impl we have in mind is container agnostic, and will > >have other mechanisms to revoke and manage a key. The provider pattern >allows us to be configured if we want to, or ignore the container config. > >Though you're right... it's far to awkward to deal with the container >config, and the change listening is prone to concurrency issues and other >problems. >I'd like to propose that we introduce some abstract classes for >implementing future Provider classes that do the work of listening to a >arbitrary key(impl specific) and providing some pre-baked impl to deal >with changes and further notify consumers of the provider if the value >changes. >This will make it much easier to roll your own implementation of features. > >My proposed heirarchy is: > >IOnChangedListener<type> (interface used by a provider to handle changes >in the value being provided) >IProvider<type> > AbstractProvider (for impls not based on a ContainerConfig) > AbastractConfiguredProvider (for impls that listen to a container >config setting) > >What do you think? >(BTW, this discussion has been excellent and has really helped me >understand a lot more about shindig... I'm very grateful you're >participating in it and hopefully others can chime in as well) > > >
