On Thu, Oct 2, 2008 at 2:41 PM, Cassie <[EMAIL PROTECTED]> wrote: > Anybody else want to chime in? > We can either: > > 1. add SecurityToken.getContainer > 2. add SecurityToken.getParameter(String key) > 3. leave it as is and go find a different solution for SecurityToken > extensions
My rough order of preference: - find a different solution, though I've got no idea what one would look like. - SecurityToken.getContainer() - getParameter(String key) I don't like getParameter(String key) because it forces us to treat all security token extensions as Strings. What if it's a List? What if it's something else entirely? Hrm. I do have some idea of what a good solution would look like, but so far everytime I mention it people give me dirty looks. I'll try it out on shindig-dev just to see where things go: Assuming that all instances of SecurityToken are generated by deployment specific code, Shindig deployers can implement a single subclass of SecurityToken for all SecurityToken instances they generate. Shindig SPI implementations can then cast down to that SecurityToken subclass. This type of pattern is remarkably common in old school C code: opaque void* pointers are tossed around anywhere you have two APIs that can't have compile time dependencies but do need to call each other at runtime.
