Proposed SessionManager/SecurityManager API changes for 1.0

[Les Hazlewood <lh...@apache.org>]

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?

Re: Proposed SessionManager/SecurityManager API changes for 1.0

[Les Hazlewood <lh...@apache.org>]

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 <lh...@apache.org>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?
>