[sshd] use of session attributes and AttributeKey

[Frank van der Kleij <kl...@hotmail.com>]

Has anyone used the ServerSession attributes? I'm puzzled by the AttributeKey class that is used to define the key. It's an empty class without any state. The only way I can see to use it is to make a subclass of it, but that seems like a lot of trouble just to store something in the session.
To be useful it should have some state together with the methods hashCode and equals. The subclass I made is based on a String...
Am I missing something or should everyone define his own key? It would be nice if something workable would be in the core...
Thanks,
Frank
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

RE: [sshd] use of session attributes and AttributeKey

[Frank van der Kleij <kl...@hotmail.com>]

> >
> > Has anyone used the ServerSession attributes? I'm puzzled by the
> > AttributeKey class that is used to define the key. It's an empty class
> > without any state. The only way I can see to use it is to make a subclass of
> > it, but that seems like a lot of trouble just to store something in the
> > session.
> > To be useful it should have some state together with the methods hashCode
> > and equals. The subclass I made is based on a String...
> > Am I missing something or should everyone define his own key? It would be
> > nice if something workable would be in the core...
> 
> 
> Yes, its easier than that.  All you have to do is this:
> 
>   class MyState {
>     public static final AttributeKey<MyState> MY_STATE = new
> AttributeKey<MyState>();
> 
>     public static MyState get(ServerSession s) {
>       return s.getAttribute(MY_STATE);
>     }
> 
>     public void put(ServerSession s) {
>       s.setAttribute(MY_STATE, this);
>     }
>   }
> 
> No need to subclass it.  The reason AttributeKey exists as it does is to
> make the get/set methods have type safe signatures.  You just need to create
> a new instance of the AttributeKey to get a unique entry in the attribute
> map.  Since AttributeKey is then relying on reference equality, two keys are
> only equal if they are the same key instance.  You can scope your attribute
> data by scoping your AttributeKey instance; if nobody can get your key,
> nobody can get (or set) your attribute.

Thanks, I did not think of that. I got my integration working now. 
I submitted a patch to have communication between the PasswordAuthenticator and the Shell; hopefully it will be integrated (or something similar) so I can publish my project. In the patchI also added some documentation to the AttributeKey class that describes your pattern.


_________________________________________________________________
What can you do with the new Windows Live? Find out
http://www.microsoft.com/windows/windowslive/default.aspx

Re: [sshd] use of session attributes and AttributeKey

[Shawn Pearce <so...@google.com>]

On Wed, Jul 15, 2009 at 23:33, Frank van der Kleij <kl...@hotmail.com>wrote:

>
> Has anyone used the ServerSession attributes? I'm puzzled by the
> AttributeKey class that is used to define the key. It's an empty class
> without any state. The only way I can see to use it is to make a subclass of
> it, but that seems like a lot of trouble just to store something in the
> session.
> To be useful it should have some state together with the methods hashCode
> and equals. The subclass I made is based on a String...
> Am I missing something or should everyone define his own key? It would be
> nice if something workable would be in the core...


Yes, its easier than that.  All you have to do is this:

  class MyState {
    public static final AttributeKey<MyState> MY_STATE = new
AttributeKey<MyState>();

    public static MyState get(ServerSession s) {
      return s.getAttribute(MY_STATE);
    }

    public void put(ServerSession s) {
      s.setAttribute(MY_STATE, this);
    }
  }

No need to subclass it.  The reason AttributeKey exists as it does is to
make the get/set methods have type safe signatures.  You just need to create
a new instance of the AttributeKey to get a unique entry in the attribute
map.  Since AttributeKey is then relying on reference equality, two keys are
only equal if they are the same key instance.  You can scope your attribute
data by scoping your AttributeKey instance; if nobody can get your key,
nobody can get (or set) your attribute.