Oops - that last item in the list of 3 methods should read as: SessionManager#start(Map initData)
Instead of taking in an InetAddress directly (the InetAddress could go in the map). On Thu, May 28, 2009 at 4:07 PM, Les Hazlewood <[email protected]>wrote: > In an effort of making things more flexible to specific runtime and > deployment environments, I'd like to make some initializer/factory method > calls more flexible. > > The only two methods that are really important that come to mind are: > > SessionManager#start(InetAddress inetAddress) > SecurityManager#getSubject() > > These are limited in how to direct the underlying Session or Subject to be > created, if that would be necessary. > > For example, before last week, I proposed adding these two methods to > SecurityManager: > > getSubjectBySessionId( Serializable sessionId ); > getSubject(PrincipalCollection principals); > > These two methods take in very specific arguments based on what is being > accomplished and are not flexible should other information be required by > the underlying implementation and/or factory to construct an instance. > > Instead of adding overloaded methods for start and getSubject, I think it > might be better to take in a Map instance that the underlying > implementation(s) could inspect for whatever data that might be needed to > create the instance returned. So we could have this instead: > > SecurityManager#getSubject(); //existing method, keep it > SecurityManager#getSubject(Map initData); //new method > SessionManager#getSubject(Map initData); //new method > > Of course we could have the above overloaded methods and the Map argument > method, which might make more sense for ease-of-use. > > Thoughts? >
