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
- Cassie On Wed, Oct 1, 2008 at 11:51 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > On Wed, Oct 1, 2008 at 11:13 AM, Brian Eaton <[EMAIL PROTECTED]> wrote: > > > On Wed, Oct 1, 2008 at 9:41 AM, Cassie <[EMAIL PROTECTED]> wrote: > > > My specific ask for this bug is much much simpler. Most of the token > > > implementations that we have already know what the container is. I am > > just > > > proposing adding a getter for the field and pulling it up into the > > > SecurityToken interface. I'm also not proposing that we need to use > this > > > anywhere in the shindig code. > > > > Philosophical objection: why should we clutter the Shindig code with > > interfaces that Shindig doesn't use? > > > We *would* use it if it existed. Right now we have to pass container > separately for many operations where the security token is already passed. > This would eliminate that requirement. > > I actually agree with Cassie's next point more though. getParameter seems > like a much cleaner extensibility mechanism. >
