i'll go for the .getContainer(). Once happened to me in an integration that i needed on extra field in the ST, and getExtraField() was the *logic* solution for my custom extension.
ropu On Thu, Oct 2, 2008 at 6:50 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > 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. > -- .-. --- .--. ..- R o p u
