You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Julien Vermillard <jv...@archean.fr> on 2009/10/26 09:05:50 UTC
[3.0] IoSession attachment
Hi,
Here all the methods in IoSession used for session attribute management
(attaching, getting, etc..)
I personally thinks is a bit too many, and never use all of them.
What are the one you use and the one you don't care seeing removed ?
Thanks !
Julien
/**
* Returns the value of the user-defined attribute of this session.
*
* @param key the key of the attribute
* @return <tt>null</tt> if there is no attribute with the specified key
*/
Object getAttribute(Object key);
/**
* Returns the value of user defined attribute associated with the
* specified key. If there's no such attribute, the specified default
* value is associated with the specified key, and the default value is
* returned. This method is same with the following code except that the
* operation is performed atomically.
* <pre>
* if (containsAttribute(key)) {
* return getAttribute(key);
* } else {
* setAttribute(key, defaultValue);
* return defaultValue;
* }
* </pre>
*/
Object getAttribute(Object key, Object defaultValue);
/**
* Sets a user-defined attribute.
*
* @param key the key of the attribute
* @param value the value of the attribute
* @return The old value of the attribute. <tt>null</tt> if it is new.
*/
Object setAttribute(Object key, Object value);
/**
* Sets a user defined attribute without a value. This is useful when
* you just want to put a 'mark' attribute. Its value is set to
* {@link Boolean#TRUE}.
*
* @param key the key of the attribute
* @return The old value of the attribute. <tt>null</tt> if it is new.
*/
Object setAttribute(Object key);
/**
* Sets a user defined attribute if the attribute with the specified key
* is not set yet. This method is same with the following code except
* that the operation is performed atomically.
* <pre>
* if (containsAttribute(key)) {
* return getAttribute(key);
* } else {
* return setAttribute(key, value);
* }
* </pre>
*/
Object setAttributeIfAbsent(Object key, Object value);
/**
* Sets a user defined attribute without a value if the attribute with
* the specified key is not set yet. This is useful when you just want to
* put a 'mark' attribute. Its value is set to {@link Boolean#TRUE}.
* This method is same with the following code except that the operation
* is performed atomically.
* <pre>
* if (containsAttribute(key)) {
* return getAttribute(key); // might not always be Boolean.TRUE.
* } else {
* return setAttribute(key);
* }
* </pre>
*/
Object setAttributeIfAbsent(Object key);
/**
* Removes a user-defined attribute with the specified key.
*
* @return The old value of the attribute. <tt>null</tt> if not found.
*/
Object removeAttribute(Object key);
/**
* Removes a user defined attribute with the specified key if the current
* attribute value is equal to the specified value. This method is same
* with the following code except that the operation is performed
* atomically.
* <pre>
* if (containsAttribute(key) && getAttribute(key).equals(value)) {
* removeAttribute(key);
* return true;
* } else {
* return false;
* }
* </pre>
*/
boolean removeAttribute(Object key, Object value);
/**
* Replaces a user defined attribute with the specified key if the
* value of the attribute is equals to the specified old value.
* This method is same with the following code except that the operation
* is performed atomically.
* <pre>
* if (containsAttribute(key) && getAttribute(key).equals(oldValue)) {
* setAttribute(key, newValue);
* return true;
* } else {
* return false;
* }
* </pre>
*/
boolean replaceAttribute(Object key, Object oldValue, Object newValue);
/**
* Returns <tt>true</tt> if this session contains the attribute with
* the specified <tt>key</tt>.
*/
boolean containsAttribute(Object key);
/**
* Returns the set of keys of all user-defined attributes.
*/
Set<Object> getAttributeKeys();
Re: [3.0] IoSession attachment
Posted by Norman Maurer <no...@apache.org>.
I'm not a mina developer but here is my +1.
Bye,
Norman
2009/10/26 Julien Vermillard <jv...@archean.fr>:
> Le Mon, 26 Oct 2009 13:31:20 +0100,
> Emmanuel Lecharny <el...@apache.org> a écrit :
>
>> I would go with only those methods (applying the KISS principle)
>> > Object getAttribute(Object key);
>> > Object setAttribute(Object key, Object value);
>> > Object removeAttribute(Object key);
>> > boolean containsAttribute(Object key);
>> > Set<Object> getAttributeKeys();
>> >
>> Everything else is just overkilling, IMHO.
>>
>
> It's my POV too, but I wanted to see what others have to say without
> influencing.
>
> Julien
>
Re: [3.0] IoSession attachment
Posted by Julien Vermillard <jv...@archean.fr>.
Le Mon, 26 Oct 2009 13:31:20 +0100,
Emmanuel Lecharny <el...@apache.org> a écrit :
> I would go with only those methods (applying the KISS principle)
> > Object getAttribute(Object key);
> > Object setAttribute(Object key, Object value);
> > Object removeAttribute(Object key);
> > boolean containsAttribute(Object key);
> > Set<Object> getAttributeKeys();
> >
> Everything else is just overkilling, IMHO.
>
It's my POV too, but I wanted to see what others have to say without
influencing.
Julien
Re: [3.0] IoSession attachment
Posted by Emmanuel Lecharny <el...@apache.org>.
Steve Ulrich wrote:
> Hi!
>
> Some thoughts should be spend how the additional atomic operations can be triggered and how to hint that to new users.
> I know that they can be accessed via the AttributeMap, but this isn't stated somewhere explicitly. Letting only the simple get/set/remove methods at the IoSession will confuse new users, especially if they are documented as they are at the moment.
>
The current documentation is most certainly something we have to
improve. The fact that we have so many useless methods slowed down the
documentation effort too.
So I buy your point of view : if we keep the API small, we have to
increase the level of documentation.
> So either remove them completely, or just state that they are convenience methods and what to do "normally" (e.g. "This is a convenience method for getAttributeMap().getAttribute(Object key)"). Maybe a link to the IoSessionAttributeMap-method would be nice, too.
>
We may expose the inner data structure, but I'm not sure it's a good
idea. IMO, the way it's stored (ie attributeMap) should remain hidden to
the users.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [3.0] IoSession attachment no---signature
Posted by Julien Vermillard <jv...@archean.fr>.
Le Mon, 26 Oct 2009 17:47:00 +0100,
Emmanuel Lecharny <el...@apache.org> a écrit :
> Julien Vermillard wrote:
> > Le Mon, 26 Oct 2009 16:39:20 +0100,
> > Steve Ulrich <st...@proemion.com> a écrit :
> >
> >
> >>> Emmanuel Lecharny wrote:
> >>>
> >>> Julien Vermillard wrote:
> >>>
> >>>> That's the idea for me.
> >>>>
> >>>> kill IoSessionAttributMap,
> >>>> put a Synchronized HashMap in AbstractIoSession
> >>>> and provide only : getAttribute, setAttribute, removeAttribute,
> >>>> getAttributeKeys (could be renamed to getAttributeNames)
> >>>>
> >>>>
> >> Nitpick: A ConcurrentHashMap may have a better performance. ;-)
> >> IMHO, the methods from the ConcurrentMap should be accessible, too.
> >> But maybe I'm just too critical with thread safety concerns.
> >>
> >
> > Thanks forgot ConcurrentHashMap :)
> > What's the methods you need ? putIfAbsent(K key, V value) perhaps ?
> >
> No. Overkilling...
> >
> >
> >>> We may add a listener attached to some attributes too, or to the
> >>> session.
> >>>
> >> That may justify an own Map implementation, but you should
> >> redesign/clean that interface of the IoSessionAttributeMap (why do
> >> I need to give a sessions to it, the implementation ignores it
> >> anyway?).
> >>
> >> Steve
> >>
> >
> > Well I'm not sure a listener on the attribute is a really useful
> > feature. I can't thinks about a usecase.
> >
> I was thinking that for debuggingpurpose it may help.
>
> But we can start without it at first. Anyway, someone can extend the
> IoSession interface, adding the listener if needed.
>
For debugging a debug statement is perhaps enough ?
Re: [3.0] IoSession attachment no---signature
Posted by Emmanuel Lecharny <el...@apache.org>.
Julien Vermillard wrote:
> Le Mon, 26 Oct 2009 16:39:20 +0100,
> Steve Ulrich <st...@proemion.com> a écrit :
>
>
>>> Emmanuel Lecharny wrote:
>>>
>>> Julien Vermillard wrote:
>>>
>>>> That's the idea for me.
>>>>
>>>> kill IoSessionAttributMap,
>>>> put a Synchronized HashMap in AbstractIoSession
>>>> and provide only : getAttribute, setAttribute, removeAttribute,
>>>> getAttributeKeys (could be renamed to getAttributeNames)
>>>>
>>>>
>> Nitpick: A ConcurrentHashMap may have a better performance. ;-)
>> IMHO, the methods from the ConcurrentMap should be accessible, too.
>> But maybe I'm just too critical with thread safety concerns.
>>
>
> Thanks forgot ConcurrentHashMap :)
> What's the methods you need ? putIfAbsent(K key, V value) perhaps ?
>
No. Overkilling...
>
>
>>> We may add a listener attached to some attributes too, or to the
>>> session.
>>>
>> That may justify an own Map implementation, but you should
>> redesign/clean that interface of the IoSessionAttributeMap (why do I
>> need to give a sessions to it, the implementation ignores it anyway?).
>>
>> Steve
>>
>
> Well I'm not sure a listener on the attribute is a really useful
> feature. I can't thinks about a usecase.
>
I was thinking that for debuggingpurpose it may help.
But we can start without it at first. Anyway, someone can extend the
IoSession interface, adding the listener if needed.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [3.0] IoSession attachment no---signature
Posted by Ashish <pa...@gmail.com>.
> Well I'm not sure a listener on the attribute is a really useful
> feature. I can't thinks about a usecase.
>
> Julien
Well Session lifecycle listeners are good, but having an attribute
change listener would be too much for session management in core part.
Though I have seen an interesting implementation around this, but it
makes you to use custom value objects like MyInt etc, but from the
framework part, guess we can live without it.
--
thanks
ashish
Re: [3.0] IoSession attachment no---signature
Posted by Ashish <pa...@gmail.com>.
> A pig ??? You mean, a bunch of pigs !
>>
>> well I never faced a situation where I needed to optimize MINA code, but
>> showing good perf number is a good marketing point... but I agree API
>> first.
>>
>
> Yep. We can put lipstick on the pig later :)
+1, so we all agree that we shall have only required API's with documentation.
Also this time, lets ensure that we continue to write the Test cases
along with implementation :-)
--
thanks
ashish
SSL: recognition by first byte and adding SslFilter on the fly
Posted by Victor <dr...@mail333.com>.
Hello,
our server supported plain-text communication with clients, now we are
going to support both plain-text and SSL,
so I am interested what is a recommended way to add SSL filter "on the
fly" in the following situation:
I have this filter chain in the server:
ProtocolCodecFilter --> ExecutorFilter
ProtocolCodecFilter uses a decoder which extends CumulativeProtocolDecoder.
The decoder analyzes the first byte, if it equals to 0x16 (TLSv1, SSLv3)
or 0x80 (SSLv2) then I want to handle SSL, that is I would like to add
SSL filter:
SSLFilter --> ProtocolCodecFilter --> ExecutorFilter
My protocol decoder is like this:
public class ClientIODecoder extends CumulativeProtocolDecoder {
protected boolean doDecode(IoSession session, IoBuffer in,
ProtocolDecoderOutput out) throws Exception {
if (in.get() == SSL_FIRST_BYTE) {
// reset the buffer pointer to read from the beginning
in.position(0);
// create SSL filter
SslFilter sslFilter = ...;
session.getFilterChain().addFirst("SSL", sslFilter);
// say CumulativeProtocolDecoder that we handled the message
return true;
} else {
// our usual decoding procedure
}
}
}
But I should say the filter chain somehow that it should handle IoBuffer
again. How to make it work and eliminate memory leaks in
CumulativeProtocolDecoder?
Thanks!
Victor
Re: SSL: recognition by first byte and adding SslFilter on the fly
Posted by Victor <dr...@mail333.com>.
Emmanuel,
thanks for the idea, it works!
Victor
Emmanuel Lecharny wrote:
> Not easy ...
>
> What I would do :
>
> - add a specific first filter (not a codec) which read the first byte
> - if it detects that it's 0x16 or 0x80, add the SSL filter just after
> this first filter, reset the buffer position, and continue (the hanshake
> will take place then)
> - if not, then it's a plain text message, continue processing it
>
> There are issues though :
> - once you have started a SSL handshake, you have to tell your first
> filter to do nothing with incoming bytes, otherwise the handshake will
> fail. This is easy: just add a session parameter which is switched to
> TRUE when SSL handshake is started (this should be done in the first
> filter)
> - if you are using plain text, it should be assumed that once received
> the first byte, if it's not 0x16 or 0x80, then all the incoming bytes
> will be considered as plain text bytes (ie, you are not supposed to
> switch to SSL once the session has been created and once you started to
> received plain text bytes). A way to handle this is also to add a
> parameter stored in the session, set to TRUE when the session has started.
>
> The combinaison of those two parameters (session started and SSL
> established) and the fist received byte will be used to handle all the
> cases.
>
> Not sure 100% it would work, but this is how I see the full thing
> implemented. (No memory leak expected at this point).
>
Re: SSL: recognition by first byte and adding SslFilter on the fly
Posted by Emmanuel Lecharny <el...@apache.org>.
Not easy ...
What I would do :
- add a specific first filter (not a codec) which read the first byte
- if it detects that it's 0x16 or 0x80, add the SSL filter just after
this first filter, reset the buffer position, and continue (the hanshake
will take place then)
- if not, then it's a plain text message, continue processing it
There are issues though :
- once you have started a SSL handshake, you have to tell your first
filter to do nothing with incoming bytes, otherwise the handshake will
fail. This is easy: just add a session parameter which is switched to
TRUE when SSL handshake is started (this should be done in the first filter)
- if you are using plain text, it should be assumed that once received
the first byte, if it's not 0x16 or 0x80, then all the incoming bytes
will be considered as plain text bytes (ie, you are not supposed to
switch to SSL once the session has been created and once you started to
received plain text bytes). A way to handle this is also to add a
parameter stored in the session, set to TRUE when the session has started.
The combinaison of those two parameters (session started and SSL
established) and the fist received byte will be used to handle all the
cases.
Not sure 100% it would work, but this is how I see the full thing
implemented. (No memory leak expected at this point).
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
SSL: recognition by first byte and adding SslFilter on the fly
Posted by Victor <dr...@mail333.com>.
Hello,
our server supported plain-text communication with clients, now we are
going to support both plain-text and SSL,
so I am interested what is a recommended way to add SSL filter "on the
fly" in the following situation:
I have this filter chain in the server:
ProtocolCodecFilter --> ExecutorFilter
ProtocolCodecFilter uses a decoder which extends CumulativeProtocolDecoder.
The decoder analyzes the first byte, if it equals to 0x16 (TLSv1, SSLv3)
or 0x80 (SSLv2) then I want to handle SSL, that is I would like to add
SSL filter:
SSLFilter --> ProtocolCodecFilter --> ExecutorFilter
My protocol decoder is like this:
public class ClientIODecoder extends CumulativeProtocolDecoder {
protected boolean doDecode(IoSession session, IoBuffer in,
ProtocolDecoderOutput out) throws Exception {
if (in.get() == SSL_FIRST_BYTE) {
// reset the buffer pointer to read from the beginning
in.position(0);
// create SSL filter
SslFilter sslFilter = ...;
session.getFilterChain().addFirst("SSL", sslFilter);
// say CumulativeProtocolDecoder that we handled the message
return true;
} else {
// our usual decoding procedure
}
}
}
But I should say the filter chain somehow that it should handle IoBuffer
again. How to make it work and eliminate memory leaks in
CumulativeProtocolDecoder?
Thanks!
Victor
Re: [3.0] IoSession attachment no---signature
Posted by Emmanuel Lecharny <el...@apache.org>.
Julien Vermillard wrote:
> Perhaps it's ADS the pig ? ;)
>
A pig ??? You mean, a bunch of pigs !
> well I never faced a situation where I needed to optimize MINA code, but
> showing good perf number is a good marketing point... but I agree API
> first.
>
Yep. We can put lipstick on the pig later :)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [3.0] IoSession attachment no---signature
Posted by Julien Vermillard <jv...@archean.fr>.
Le Mon, 26 Oct 2009 17:50:17 +0100,
Emmanuel Lecharny <el...@apache.org> a écrit :
> Steve Ulrich wrote:
> >> Julien Vermillard wrote
> >>
> >> Thanks forgot ConcurrentHashMap :)
> >> What's the methods you need ? putIfAbsent(K key, V value) perhaps ?
> >>
> >
> > Yes, that's a good example when you want to fill an attribute on
> > demand. But maybe it's ok to let the user synchronize on a higher
> > level and if you are using an OrderedThreadPool, most of the
> > possbile synchronisation issues are gone.
> Using a ConcurrentHashMap is covering any situation, at no cost (or
> barely noticeable).
>
> One thing we must keep in mind : MINA won't be a bottleneck in most
> of the case. Squeezing a few nano seconds from core is probably a
> waste of energy, compared to having a simple, powerful, documented
> API.
>
> Not saying we must code like pigs, but my own experience with MINA in
> Directory is that MINA count for less than 3% of the server's time
> when heaviily loaded...
>
Perhaps it's ADS the pig ? ;)
well I never faced a situation where I needed to optimize MINA code, but
showing good perf number is a good marketing point... but I agree API
first.
Julien
Re: [3.0] IoSession attachment no---signature
Posted by Emmanuel Lecharny <el...@apache.org>.
Steve Ulrich wrote:
>> Julien Vermillard wrote
>>
>> Thanks forgot ConcurrentHashMap :)
>> What's the methods you need ? putIfAbsent(K key, V value) perhaps ?
>>
>
> Yes, that's a good example when you want to fill an attribute on demand.
> But maybe it's ok to let the user synchronize on a higher level and if you are using an OrderedThreadPool, most of the possbile synchronisation issues are gone.
>
Using a ConcurrentHashMap is covering any situation, at no cost (or
barely noticeable).
One thing we must keep in mind : MINA won't be a bottleneck in most of
the case. Squeezing a few nano seconds from core is probably a waste of
energy, compared to having a simple, powerful, documented API.
Not saying we must code like pigs, but my own experience with MINA in
Directory is that MINA count for less than 3% of the server's time when
heaviily loaded...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [3.0] IoSession attachment no---signature
Posted by Steve Ulrich <st...@proemion.com>.
> Julien Vermillard wrote
>
> Thanks forgot ConcurrentHashMap :)
> What's the methods you need ? putIfAbsent(K key, V value) perhaps ?
Yes, that's a good example when you want to fill an attribute on demand.
But maybe it's ok to let the user synchronize on a higher level and if you are using an OrderedThreadPool, most of the possbile synchronisation issues are gone.
Steve
Re: [3.0] IoSession attachment no---signature
Posted by Julien Vermillard <jv...@archean.fr>.
Le Mon, 26 Oct 2009 16:39:20 +0100,
Steve Ulrich <st...@proemion.com> a écrit :
> > Emmanuel Lecharny wrote:
> >
> > Julien Vermillard wrote:
> > > That's the idea for me.
> > >
> > > kill IoSessionAttributMap,
> > > put a Synchronized HashMap in AbstractIoSession
> > > and provide only : getAttribute, setAttribute, removeAttribute,
> > > getAttributeKeys (could be renamed to getAttributeNames)
> > >
>
> Nitpick: A ConcurrentHashMap may have a better performance. ;-)
> IMHO, the methods from the ConcurrentMap should be accessible, too.
> But maybe I'm just too critical with thread safety concerns.
Thanks forgot ConcurrentHashMap :)
What's the methods you need ? putIfAbsent(K key, V value) perhaps ?
> > We may add a listener attached to some attributes too, or to the
> > session.
>
> That may justify an own Map implementation, but you should
> redesign/clean that interface of the IoSessionAttributeMap (why do I
> need to give a sessions to it, the implementation ignores it anyway?).
>
> Steve
Well I'm not sure a listener on the attribute is a really useful
feature. I can't thinks about a usecase.
Julien
Re: AW: [3.0] IoSession attachment no---signature
Posted by Emmanuel Lecharny <el...@apache.org>.
Steve Ulrich wrote:
>> Emmanuel Lecharny wrote:
>>
>> Julien Vermillard wrote:
>>
>>> That's the idea for me.
>>>
>>> kill IoSessionAttributMap,
>>> put a Synchronized HashMap in AbstractIoSession
>>> and provide only : getAttribute, setAttribute, removeAttribute,
>>> getAttributeKeys (could be renamed to getAttributeNames)
>>>
>>>
>
> Nitpick: A ConcurrentHashMap may have a better performance. ;-)
>
Absolutely. Considering that the session will probably be used in a
single thread (or at least the concurrency level will be minimal), this
is most certainly the correct data structure to use.
>> We may add a listener attached to some attributes too, or to the
>> session.
>>
>
> That may justify an own Map implementation, but you should redesign/clean that interface of the IoSessionAttributeMap (why do I need to give a sessions to it, the implementation ignores it anyway?).
>
Well, not sure. It should be enough to add the triggers into the
addAttribute()/removeAttribute() methods.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
AW: [3.0] IoSession attachment no---signature
Posted by Steve Ulrich <st...@proemion.com>.
> Emmanuel Lecharny wrote:
>
> Julien Vermillard wrote:
> > That's the idea for me.
> >
> > kill IoSessionAttributMap,
> > put a Synchronized HashMap in AbstractIoSession
> > and provide only : getAttribute, setAttribute, removeAttribute,
> > getAttributeKeys (could be renamed to getAttributeNames)
> >
Nitpick: A ConcurrentHashMap may have a better performance. ;-)
IMHO, the methods from the ConcurrentMap should be accessible, too. But maybe I'm just too critical with thread safety concerns.
> We may add a listener attached to some attributes too, or to the
> session.
That may justify an own Map implementation, but you should redesign/clean that interface of the IoSessionAttributeMap (why do I need to give a sessions to it, the implementation ignores it anyway?).
Steve
Re: [3.0] IoSession attachment
Posted by Emmanuel Lecharny <el...@apache.org>.
Julien Vermillard wrote:
> That's the idea for me.
>
> kill IoSessionAttributMap,
> put a Synchronized HashMap in AbstractIoSession
> and provide only : getAttribute, setAttribute, removeAttribute,
> getAttributeKeys (could be renamed to getAttributeNames)
>
We may add a listener attached to some attributes too, or to the session.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [3.0] IoSession attachment
Posted by Ashish <pa...@gmail.com>.
On Mon, Oct 26, 2009 at 8:08 PM, Emmanuel Lecharny <el...@apache.org> wrote:
> Julien Vermillard wrote:
>>
>> That's the idea for me.
>>
>> kill IoSessionAttributMap,
>> put a Synchronized HashMap in AbstractIoSession
>> and provide only : getAttribute, setAttribute, removeAttribute,
>> getAttributeKeys (could be renamed to getAttributeNames)
>>
>
> I suggested we can have a contains( key ), but this is useless : a if (
> getAttribute( "blah" ) != null ) is doing exactly the same.
>
I think we should keep this API, its more intuitive to user (may be
coz we have similar API for most of Collections)
--
thanks
ashish
Re: [3.0] IoSession attachment
Posted by Emmanuel Lecharny <el...@apache.org>.
Julien Vermillard wrote:
> That's the idea for me.
>
> kill IoSessionAttributMap,
> put a Synchronized HashMap in AbstractIoSession
> and provide only : getAttribute, setAttribute, removeAttribute,
> getAttributeKeys (could be renamed to getAttributeNames)
>
I suggested we can have a contains( key ), but this is useless : a if (
getAttribute( "blah" ) != null ) is doing exactly the same.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [3.0] IoSession attachment
Posted by Julien Vermillard <jv...@archean.fr>.
Le Mon, 26 Oct 2009 15:11:10 +0100,
Emmanuel Lecharny <el...@apache.org> a écrit :
> Julien Vermillard wrote:
> > Hi,
> >
> > I think about removing IoSessionAttributeMap if what we could expose
> > if just a Map. As far as I understand it IoSessionAttributeMap is
> > here for adding all the utility methods.
> >
> The question is : would anyone want to extend the IoSession API by
> adding (useless) methods ?
>
> If you have a look at HttpSession API, it's damn limited :
> |java.lang.Object| ||
> <http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpSession.html#getAttribute%28java.lang.String%29>|*getAttribute
> <http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpSession.html#getAttribute%28java.lang.String%29>*(java.lang.String
> name)|
>
> |||java.util.Enumeration |
> <http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpSession.html#getAttributeNames%28%29>|*getAttributeNames
> <http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpSession.html#getAttributeNames%28%29>*()|
>
> |*removeAttribute
> <http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpSession.html#removeAttribute%28java.lang.String%29>*(java.lang.String
> name)|
>
> |*setAttribute
> <http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpSession.html#setAttribute%28java.lang.String,%20java.lang.Object%29>*(java.lang.String
> name, java.lang.Object value)|
>
> Nobody ever wanted one more method, and nobody ever wanted to know
> how it is handled by the server (as a Set, a Map, a List, whatever).
>
> IMHO, this is what we should do : keep it dead simple. We don't have
> have to expose a Map. Kill the IoSessionAttributeMap interface.
>
That's the idea for me.
kill IoSessionAttributMap,
put a Synchronized HashMap in AbstractIoSession
and provide only : getAttribute, setAttribute, removeAttribute,
getAttributeKeys (could be renamed to getAttributeNames)
Re: [3.0] IoSession attachment
Posted by Emmanuel Lecharny <el...@apache.org>.
Julien Vermillard wrote:
> Hi,
>
> I think about removing IoSessionAttributeMap if what we could expose
> if just a Map. As far as I understand it IoSessionAttributeMap is here
> for adding all the utility methods.
>
The question is : would anyone want to extend the IoSession API by
adding (useless) methods ?
If you have a look at HttpSession API, it's damn limited :
|java.lang.Object| ||
<http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpSession.html#getAttribute%28java.lang.String%29>|*getAttribute
<http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpSession.html#getAttribute%28java.lang.String%29>*(java.lang.String name)|
|||java.util.Enumeration |
<http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpSession.html#getAttributeNames%28%29>|*getAttributeNames
<http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpSession.html#getAttributeNames%28%29>*()|
|*removeAttribute
<http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpSession.html#removeAttribute%28java.lang.String%29>*(java.lang.String name)|
|*setAttribute
<http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpSession.html#setAttribute%28java.lang.String,%20java.lang.Object%29>*(java.lang.String name,
java.lang.Object value)|
Nobody ever wanted one more method, and nobody ever wanted to know how
it is handled by the server (as a Set, a Map, a List, whatever).
IMHO, this is what we should do : keep it dead simple. We don't have
have to expose a Map. Kill the IoSessionAttributeMap interface.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [3.0] IoSession attachment
Posted by Julien Vermillard <jv...@archean.fr>.
Hi,
I think about removing IoSessionAttributeMap if what we could expose
if just a Map. As far as I understand it IoSessionAttributeMap is here
for adding all the utility methods.
Julien
Le Mon, 26 Oct 2009 14:00:19 +0100,
Steve Ulrich <st...@proemion.com> a écrit :
> Hi!
>
> Some thoughts should be spend how the additional atomic operations
> can be triggered and how to hint that to new users. I know that they
> can be accessed via the AttributeMap, but this isn't stated somewhere
> explicitly. Letting only the simple get/set/remove methods at the
> IoSession will confuse new users, especially if they are documented
> as they are at the moment.
>
> So either remove them completely, or just state that they are
> convenience methods and what to do "normally" (e.g. "This is a
> convenience method for getAttributeMap().getAttribute(Object key)").
> Maybe a link to the IoSessionAttributeMap-method would be nice, too.
>
> Just my 2 cents
>
> Steve
>
> > Emmanuel Lecharny wrote:
> >
> > I would go with only those methods (applying the KISS principle)
> > > Object getAttribute(Object key);
> > > Object setAttribute(Object key, Object value);
> > > Object removeAttribute(Object key);
> > > boolean containsAttribute(Object key);
> > > Set<Object> getAttributeKeys();
> > >
> > Everything else is just overkilling, IMHO.
> >
> > --
> > --
> > cordialement, regards,
> > Emmanuel Lécharny
> > www.iktek.com
> > directory.apache.org
> >
>
>
> --------------------------------------------------------------------------
> PROEMION GmbH
>
> Steve Ulrich
>
> IT Development (IT/DEV)
>
> Donaustrasse 14
> D-36043 Fulda, Germany
> Phone +49 (0) 661 9490-601
> Fax +49 (0) 661 9490-333
> http://www.proemion.com/
> mailto:steve.ulrich@proemion.com
>
> Geschäftsführer: Dipl. Ing. Robert Michaelides
> Amtsgericht-Registergericht-Fulda: 5 HRB 1867
> --------------------------------------------------------------------------
> E-mail and any attachments may be confidential. If you have received
> this E-mail and you are not a named addressee, please inform the
> sender immediately by E-mail and then delete this E-mail from your
> system. If you are not a named addressee, you may not use, disclose,
> distribute, copy or print this E-mail. Addressees should scan this
> E-mail and any attachments for viruses. No representation or warranty
> is made as to the absence of viruses in this E-mail or any of its
> attachments.
>
> AKTUELLES
> http://www.rmcan.de/
>
> NEWS
> http://www.rmcan.com/
>
>
Re: [3.0] IoSession attachment
Posted by Steve Ulrich <st...@proemion.com>.
Hi!
Some thoughts should be spend how the additional atomic operations can be triggered and how to hint that to new users.
I know that they can be accessed via the AttributeMap, but this isn't stated somewhere explicitly. Letting only the simple get/set/remove methods at the IoSession will confuse new users, especially if they are documented as they are at the moment.
So either remove them completely, or just state that they are convenience methods and what to do "normally" (e.g. "This is a convenience method for getAttributeMap().getAttribute(Object key)"). Maybe a link to the IoSessionAttributeMap-method would be nice, too.
Just my 2 cents
Steve
> Emmanuel Lecharny wrote:
>
> I would go with only those methods (applying the KISS principle)
> > Object getAttribute(Object key);
> > Object setAttribute(Object key, Object value);
> > Object removeAttribute(Object key);
> > boolean containsAttribute(Object key);
> > Set<Object> getAttributeKeys();
> >
> Everything else is just overkilling, IMHO.
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
--------------------------------------------------------------------------
PROEMION GmbH
Steve Ulrich
IT Development (IT/DEV)
Donaustrasse 14
D-36043 Fulda, Germany
Phone +49 (0) 661 9490-601
Fax +49 (0) 661 9490-333
http://www.proemion.com/
mailto:steve.ulrich@proemion.com
Geschäftsführer: Dipl. Ing. Robert Michaelides
Amtsgericht-Registergericht-Fulda: 5 HRB 1867
--------------------------------------------------------------------------
E-mail and any attachments may be confidential. If you have received this E-mail and you are not a named addressee, please inform the sender immediately by E-mail and then delete this E-mail from your system. If you are not a named addressee, you may not use, disclose, distribute, copy or print this E-mail. Addressees should scan this E-mail and any attachments for viruses. No representation or warranty is made as to the absence of viruses in this E-mail or any of its attachments.
AKTUELLES
http://www.rmcan.de/
NEWS
http://www.rmcan.com/
Re: [3.0] IoSession attachment
Posted by Emmanuel Lecharny <el...@apache.org>.
I would go with only those methods (applying the KISS principle)
> Object getAttribute(Object key);
> Object setAttribute(Object key, Object value);
> Object removeAttribute(Object key);
> boolean containsAttribute(Object key);
> Set<Object> getAttributeKeys();
>
Everything else is just overkilling, IMHO.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [3.0] IoSession attachment
Posted by Ashish <pa...@gmail.com>.
I see two sets of API's here core api's (without which we can't work
with Session) and the other is util group.
We can trim the util group.
I think we can get rid of following
Object getAttribute(Object key, Object defaultValue);
Object setAttribute(Object key);
Object setAttributeIfAbsent(Object key);
Lets wait for more people to express their usage.
thanks
ashish
On Mon, Oct 26, 2009 at 1:35 PM, Julien Vermillard
<jv...@archean.fr> wrote:
> Hi,
> Here all the methods in IoSession used for session attribute management
> (attaching, getting, etc..)
>
> I personally thinks is a bit too many, and never use all of them.
>
> What are the one you use and the one you don't care seeing removed ?
>
> Thanks !
> Julien
>