Because this method is the only method that allows clean container specific extensibility. If we do not add this method we could instead add:
// Returns the parameter mapped with the specific key public String getParameter(String key); That would be fine as well. Without these methods social consumers of the SecurityToken class would need to constantly cast down to their own token base class if they want token extensions. That's pretty messy when we could just add one method to handle extensibility. The current shindig sample container is only responding to queries from one container. If we had it respond to queries from multiple containers then it would demonstrate a need for this functionality in one form or another. (If that sounds good its work for another patch though) - Cassie 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? >
