You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2011/12/05 14:35:27 UTC
[MINA 3] Session attributes
Hi,
in MINA 2, session's attributes were stored using the AttributeKey
class, which was concatenating a class name and a name :
private static final AttributeKey PROCESSOR = new AttributeKey(
SimpleIoProcessorPool.class, "processor");
...
IoProcessor<S> processor = (IoProcessor<S>)
session.getAttribute(PROCESSOR);
...
session.setAttributeIfAbsent(PROCESSOR, processor);
...
Currently, the new IoSession is using five methods to manipulate
Attributes :
<T> T getAttribute(String name);
<T> T setAttribute(String name, T value);
<T> T removeAttribute(String name);
boolean containsAttribute(String name);
Set<String> getAttributeNames();
All of them take a String as a key (the name), and a generic value.
I would suggest that we don't use the AttributeKey class at all, and
instead, define each internal MINA Attribute by prefixing them with
'__'. For instance, the SslContext would use the '__SslContext' key. The
rational is that there is no reaon to use complex key, even if we have
some collision risks.
wdyt ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3] Session attributes
Posted by Emmanuel Lécharny <el...@apache.org>.
On 12/7/11 2:58 PM, Chad Beaulac wrote:
> Why not use an enum for all the keys?
There is no such thing like a generic Enum type which would be inherited
by all Enums.
Something like session.addAttribute( Enum, Object ) is not possible.
Of course, if we define the addAttribute method as :
addAttribute(Object, Object)
that would be possible.
>
>
> On Mon, Dec 5, 2011 at 10:34 AM, Emmanuel Lécharny<el...@apache.org>wrote:
>
>> On 12/5/11 4:32 PM, Christian Schwarz wrote:
>>
>>> As a user, having to create a new instance to hold the key and value might
>>>
>>>> be seen as heavy, don't you think ?
>>>>
>>>> session.set(new AttributeKey<String>(String.**
>>>> class,"myKey"),"myAttribute");
>>>>
>>>> is a bit more complex than
>>>>
>>>> session.set( "myKey", "myAttribute" );
>>>>
>>>> Or is it just me ?
>>>>
>>>> It's true for your example! I don't know, but i think the most
>>> developers
>>> would use a 'final static'- constant for there keys, to avoid misspelling
>>> and to reduce the memory footprint. I my huble opinion the heavier
>>> constuction process (+ ~5sec) could save time because i don't have to test
>>> and/or debug, if set an attribute of the wrong type accidently. I think
>>> we
>>> need more opinions here, to see what the future users might think about
>>> the
>>> pro& contra.
>>>
>> Totally agree. And we can still change in a near future, before freezing
>> the code.
>>
>> Note that your proposal is closer to MINA 2, so a migration would be
>> easier (another pro for your proposal).
>>
>>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3] Session attributes
Posted by Chad Beaulac <ca...@gmail.com>.
Why not use an enum for all the keys?
On Mon, Dec 5, 2011 at 10:34 AM, Emmanuel Lécharny <el...@apache.org>wrote:
> On 12/5/11 4:32 PM, Christian Schwarz wrote:
>
>> As a user, having to create a new instance to hold the key and value might
>>
>>> be seen as heavy, don't you think ?
>>>
>>> session.set(new AttributeKey<String>(String.**
>>> class,"myKey"),"myAttribute");
>>>
>>> is a bit more complex than
>>>
>>> session.set( "myKey", "myAttribute" );
>>>
>>> Or is it just me ?
>>>
>>> It's true for your example! I don't know, but i think the most
>> developers
>> would use a 'final static'- constant for there keys, to avoid misspelling
>> and to reduce the memory footprint. I my huble opinion the heavier
>> constuction process (+ ~5sec) could save time because i don't have to test
>> and/or debug, if set an attribute of the wrong type accidently. I think
>> we
>> need more opinions here, to see what the future users might think about
>> the
>> pro& contra.
>>
> Totally agree. And we can still change in a near future, before freezing
> the code.
>
> Note that your proposal is closer to MINA 2, so a migration would be
> easier (another pro for your proposal).
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
Re: [MINA 3] Session attributes
Posted by Emmanuel Lécharny <el...@apache.org>.
On 12/5/11 4:32 PM, Christian Schwarz wrote:
> As a user, having to create a new instance to hold the key and value might
>> be seen as heavy, don't you think ?
>>
>> session.set(new AttributeKey<String>(String.**
>> class,"myKey"),"myAttribute");
>>
>> is a bit more complex than
>>
>> session.set( "myKey", "myAttribute" );
>>
>> Or is it just me ?
>>
> It's true for your example! I don't know, but i think the most developers
> would use a 'final static'- constant for there keys, to avoid misspelling
> and to reduce the memory footprint. I my huble opinion the heavier
> constuction process (+ ~5sec) could save time because i don't have to test
> and/or debug, if set an attribute of the wrong type accidently. I think we
> need more opinions here, to see what the future users might think about the
> pro& contra.
Totally agree. And we can still change in a near future, before freezing
the code.
Note that your proposal is closer to MINA 2, so a migration would be
easier (another pro for your proposal).
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3] Session attributes
Posted by Christian Schwarz <ch...@googlemail.com>.
As a user, having to create a new instance to hold the key and value might
> be seen as heavy, don't you think ?
>
> session.set(new AttributeKey<String>(String.**
> class,"myKey"),"myAttribute");
>
> is a bit more complex than
>
> session.set( "myKey", "myAttribute" );
>
> Or is it just me ?
>
It's true for your example! I don't know, but i think the most developers
would use a 'final static'- constant for there keys, to avoid misspelling
and to reduce the memory footprint. I my huble opinion the heavier
constuction process (+ ~5sec) could save time because i don't have to test
and/or debug, if set an attribute of the wrong type accidently. I think we
need more opinions here, to see what the future users might think about the
pro & contra.
Re: [MINA 3] Session attributes
Posted by Emmanuel Lécharny <el...@apache.org>.
On 12/5/11 3:52 PM, Christian Schwarz wrote:
>> What about mixing both mode ? A<String, Value> mode for simple usage, and
>> a typesafe mode, as you suggested (that means we will have two different
>> kind of map to store both elements).
>
> I think two modes is one mode to much, it would confuse the user and the
> typesafe aspect would be underminded by the<String, Value> mode.
As a user, having to create a new instance to hold the key and value
might be seen as heavy, don't you think ?
session.set(new AttributeKey<String>(String.class,"myKey"),"myAttribute");
is a bit more complex than
session.set( "myKey", "myAttribute" );
Or is it just me ?
(don't get me wrong, I understand the rational behind your proposal,
it's far superior than what I currently propose, but I'm not sure the
extra complexity worth it... Just my personal opinion, here).
thoughts ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3] Session attributes
Posted by Christian Schwarz <ch...@googlemail.com>.
>
> What about mixing both mode ? A <String, Value> mode for simple usage, and
> a typesafe mode, as you suggested (that means we will have two different
> kind of map to store both elements).
I think two modes is one mode to much, it would confuse the user and the
typesafe aspect would be underminded by the <String, Value> mode.
Re: [MINA 3] Session attributes
Posted by Emmanuel Lécharny <el...@apache.org>.
On 12/5/11 3:32 PM, Christian Schwarz wrote:
> Hi,
>
>
> I would suggest that we don't use the AttributeKey class at all, and
>> instead, define each internal MINA Attribute by prefixing them with '__'.
>> For instance, the SslContext would use the '__SslContext' key. The rational
>> is that there is no reaon to use complex key, even if we have some
>> collision risks.
>>
> As mentiont in ticket [DIRMINA-874] Typesafe
> Attributes<https://issues.apache.org/jira/browse/DIRMINA-874>,
> i think a AttributeKey is a good tool to provide typesafey and a reduced
> risk of key-collisions. The most time i get confused with String
> attribute-keys in MINA 2, is when some one uses a String for more than one
> purpose (e.g. attribute-key& nls-key ). If we have one key-type we can
> prevent users to abuse a attribute-key for an other purpose.
Yes, I read your JIRA (and replied).
What about mixing both mode ? A <String, Value> mode for simple usage,
and a typesafe mode, as you suggested (that means we will have two
different kind of map to store both elements).
>
> The idea of an '__' prefix is still possible, but i think a prefix like
> 'internal' is more expressive for those how don't read deep in the API-Docs.
It can be 'internal_'<the name>, sure. Doesn't matter too much here,
it's just about avoiding collision as much as we can.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3] Session attributes
Posted by Christian Schwarz <ch...@googlemail.com>.
Hi,
I would suggest that we don't use the AttributeKey class at all, and
> instead, define each internal MINA Attribute by prefixing them with '__'.
> For instance, the SslContext would use the '__SslContext' key. The rational
> is that there is no reaon to use complex key, even if we have some
> collision risks.
>
As mentiont in ticket [DIRMINA-874] Typesafe
Attributes<https://issues.apache.org/jira/browse/DIRMINA-874>,
i think a AttributeKey is a good tool to provide typesafey and a reduced
risk of key-collisions. The most time i get confused with String
attribute-keys in MINA 2, is when some one uses a String for more than one
purpose (e.g. attribute-key & nls-key ). If we have one key-type we can
prevent users to abuse a attribute-key for an other purpose.
The idea of an '__' prefix is still possible, but i think a prefix like
'internal' is more expressive for those how don't read deep in the API-Docs.
Chris