[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554645
]
Trustin Lee commented on DIRMINA-495:
-
I'd prefer IoSessionInitializer to
IoSessionInitializer. Except that, the change looks very good!
> IoConnector needs a way to store information into the IoSession before the
> IoHandler gets ahold of it
> -
>
> Key: DIRMINA-495
> URL: https://issues.apache.org/jira/browse/DIRMINA-495
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: David M. Lloyd
>Assignee: Mike Heath
> Fix For: 2.0.0-M1
>
> Attachments: DIRMINA-495-3.patch, DIRMINA-495-mikeheath.patch,
> IoConnector.patch
>
>
> It is often necessary to pass information into the IoHandler associated with
> an IoConnector. Sometimes this information is needed even as early as
> IoSession creation time. A mechanism is needed to pass information in to the
> IoSession at the time you call IoConnector.connect(). Discussing this with
> Mike Heath, we determined that a logical approach could be to have variants
> of the connect() methods that accept information that can be attached to the
> IoSession when it is created.
> One option is to simply pass a Map in to the connect method. The contents of
> the Map would be copied into the IoSession's attribute map after it is
> constructed but before the IoHandler.sessionCreated method is created. In
> addition, it seems likely that in many cases only one entry would need to be
> added - in this case the user could simply do this:
>ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
> Another option would be to use variable argument lists to accept any number
> of key-value pairs. The pairs could be represented by a class -
> AttributePair for example. It could look like this:
>public final class AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value =
> value; }
>public static AttributePair pair(K key, V value) { return
> new AttributePair(key, value); }
>}
> Then the user can use static imports to pull in the "pair" method. The
> connect() method on IoConnector could accept a variable list of AttributePair
> objects, so the user could write code like this:
> ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
> myValue2));
> Though this approach is somewhat more complicated than just using a Map.
> Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552622
]
Trustin Lee commented on DIRMINA-495:
-
I have renamed its method from initSession to initializeSession, which looks
more beautiful (just kidding :). I'd like to avoid shorten words whenever
possible.
> IoConnector needs a way to store information into the IoSession before the
> IoHandler gets ahold of it
> -
>
> Key: DIRMINA-495
> URL: https://issues.apache.org/jira/browse/DIRMINA-495
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: David M. Lloyd
>Assignee: Mike Heath
> Fix For: 2.0.0-M1
>
> Attachments: DIRMINA-495-3.patch, DIRMINA-495-mikeheath.patch,
> IoConnector.patch
>
>
> It is often necessary to pass information into the IoHandler associated with
> an IoConnector. Sometimes this information is needed even as early as
> IoSession creation time. A mechanism is needed to pass information in to the
> IoSession at the time you call IoConnector.connect(). Discussing this with
> Mike Heath, we determined that a logical approach could be to have variants
> of the connect() methods that accept information that can be attached to the
> IoSession when it is created.
> One option is to simply pass a Map in to the connect method. The contents of
> the Map would be copied into the IoSession's attribute map after it is
> constructed but before the IoHandler.sessionCreated method is created. In
> addition, it seems likely that in many cases only one entry would need to be
> added - in this case the user could simply do this:
>ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
> Another option would be to use variable argument lists to accept any number
> of key-value pairs. The pairs could be represented by a class -
> AttributePair for example. It could look like this:
>public final class AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value =
> value; }
>public static AttributePair pair(K key, V value) { return
> new AttributePair(key, value); }
>}
> Then the user can use static imports to pull in the "pair" method. The
> connect() method on IoConnector could accept a variable list of AttributePair
> objects, so the user could write code like this:
> ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
> myValue2));
> Though this approach is somewhat more complicated than just using a Map.
> Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552402
]
David M. Lloyd commented on DIRMINA-495:
The name is unimportant to me - Mike?
> IoConnector needs a way to store information into the IoSession before the
> IoHandler gets ahold of it
> -
>
> Key: DIRMINA-495
> URL: https://issues.apache.org/jira/browse/DIRMINA-495
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: David M. Lloyd
>Assignee: Mike Heath
> Fix For: 2.0.0-M1
>
> Attachments: DIRMINA-495-3.patch, DIRMINA-495-mikeheath.patch,
> IoConnector.patch
>
>
> It is often necessary to pass information into the IoHandler associated with
> an IoConnector. Sometimes this information is needed even as early as
> IoSession creation time. A mechanism is needed to pass information in to the
> IoSession at the time you call IoConnector.connect(). Discussing this with
> Mike Heath, we determined that a logical approach could be to have variants
> of the connect() methods that accept information that can be attached to the
> IoSession when it is created.
> One option is to simply pass a Map in to the connect method. The contents of
> the Map would be copied into the IoSession's attribute map after it is
> constructed but before the IoHandler.sessionCreated method is created. In
> addition, it seems likely that in many cases only one entry would need to be
> added - in this case the user could simply do this:
>ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
> Another option would be to use variable argument lists to accept any number
> of key-value pairs. The pairs could be represented by a class -
> AttributePair for example. It could look like this:
>public final class AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value =
> value; }
>public static AttributePair pair(K key, V value) { return
> new AttributePair(key, value); }
>}
> Then the user can use static imports to pull in the "pair" method. The
> connect() method on IoConnector could accept a variable list of AttributePair
> objects, so the user could write code like this:
> ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
> myValue2));
> Though this approach is somewhat more complicated than just using a Map.
> Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552320
]
Trustin Lee commented on DIRMINA-495:
-
I think at least we need to add 'Io' prefix because all others in the core
module do. BTW, the patch looks great!
> IoConnector needs a way to store information into the IoSession before the
> IoHandler gets ahold of it
> -
>
> Key: DIRMINA-495
> URL: https://issues.apache.org/jira/browse/DIRMINA-495
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: David M. Lloyd
>Assignee: Mike Heath
> Fix For: 2.0.0-M1
>
> Attachments: DIRMINA-495-3.patch, DIRMINA-495-mikeheath.patch,
> IoConnector.patch
>
>
> It is often necessary to pass information into the IoHandler associated with
> an IoConnector. Sometimes this information is needed even as early as
> IoSession creation time. A mechanism is needed to pass information in to the
> IoSession at the time you call IoConnector.connect(). Discussing this with
> Mike Heath, we determined that a logical approach could be to have variants
> of the connect() methods that accept information that can be attached to the
> IoSession when it is created.
> One option is to simply pass a Map in to the connect method. The contents of
> the Map would be copied into the IoSession's attribute map after it is
> constructed but before the IoHandler.sessionCreated method is created. In
> addition, it seems likely that in many cases only one entry would need to be
> added - in this case the user could simply do this:
>ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
> Another option would be to use variable argument lists to accept any number
> of key-value pairs. The pairs could be represented by a class -
> AttributePair for example. It could look like this:
>public final class AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value =
> value; }
>public static AttributePair pair(K key, V value) { return
> new AttributePair(key, value); }
>}
> Then the user can use static imports to pull in the "pair" method. The
> connect() method on IoConnector could accept a variable list of AttributePair
> objects, so the user could write code like this:
> ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
> myValue2));
> Though this approach is somewhat more complicated than just using a Map.
> Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552319
]
Trustin Lee commented on DIRMINA-495:
-
What do you think about renaming it to IoSessionInitializer?
> IoConnector needs a way to store information into the IoSession before the
> IoHandler gets ahold of it
> -
>
> Key: DIRMINA-495
> URL: https://issues.apache.org/jira/browse/DIRMINA-495
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: David M. Lloyd
>Assignee: Mike Heath
> Fix For: 2.0.0-M1
>
> Attachments: DIRMINA-495-3.patch, DIRMINA-495-mikeheath.patch,
> IoConnector.patch
>
>
> It is often necessary to pass information into the IoHandler associated with
> an IoConnector. Sometimes this information is needed even as early as
> IoSession creation time. A mechanism is needed to pass information in to the
> IoSession at the time you call IoConnector.connect(). Discussing this with
> Mike Heath, we determined that a logical approach could be to have variants
> of the connect() methods that accept information that can be attached to the
> IoSession when it is created.
> One option is to simply pass a Map in to the connect method. The contents of
> the Map would be copied into the IoSession's attribute map after it is
> constructed but before the IoHandler.sessionCreated method is created. In
> addition, it seems likely that in many cases only one entry would need to be
> added - in this case the user could simply do this:
>ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
> Another option would be to use variable argument lists to accept any number
> of key-value pairs. The pairs could be represented by a class -
> AttributePair for example. It could look like this:
>public final class AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value =
> value; }
>public static AttributePair pair(K key, V value) { return
> new AttributePair(key, value); }
>}
> Then the user can use static imports to pull in the "pair" method. The
> connect() method on IoConnector could accept a variable list of AttributePair
> objects, so the user could write code like this:
> ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
> myValue2));
> Though this approach is somewhat more complicated than just using a Map.
> Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552282
]
David M. Lloyd commented on DIRMINA-495:
It works, woo. I'd say, commit!
> IoConnector needs a way to store information into the IoSession before the
> IoHandler gets ahold of it
> -
>
> Key: DIRMINA-495
> URL: https://issues.apache.org/jira/browse/DIRMINA-495
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: David M. Lloyd
>Assignee: Mike Heath
> Fix For: 2.0.0-M1
>
> Attachments: DIRMINA-495-3.patch, DIRMINA-495-mikeheath.patch,
> IoConnector.patch
>
>
> It is often necessary to pass information into the IoHandler associated with
> an IoConnector. Sometimes this information is needed even as early as
> IoSession creation time. A mechanism is needed to pass information in to the
> IoSession at the time you call IoConnector.connect(). Discussing this with
> Mike Heath, we determined that a logical approach could be to have variants
> of the connect() methods that accept information that can be attached to the
> IoSession when it is created.
> One option is to simply pass a Map in to the connect method. The contents of
> the Map would be copied into the IoSession's attribute map after it is
> constructed but before the IoHandler.sessionCreated method is created. In
> addition, it seems likely that in many cases only one entry would need to be
> added - in this case the user could simply do this:
>ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
> Another option would be to use variable argument lists to accept any number
> of key-value pairs. The pairs could be represented by a class -
> AttributePair for example. It could look like this:
>public final class AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value =
> value; }
>public static AttributePair pair(K key, V value) { return
> new AttributePair(key, value); }
>}
> Then the user can use static imports to pull in the "pair" method. The
> connect() method on IoConnector could accept a variable list of AttributePair
> objects, so the user could write code like this:
> ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
> myValue2));
> Though this approach is somewhat more complicated than just using a Map.
> Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551910
]
David M. Lloyd commented on DIRMINA-495:
It's missing the SessionCallback interface, so it won't compile.
> IoConnector needs a way to store information into the IoSession before the
> IoHandler gets ahold of it
> -
>
> Key: DIRMINA-495
> URL: https://issues.apache.org/jira/browse/DIRMINA-495
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: David M. Lloyd
>Assignee: Mike Heath
> Fix For: 2.0.0-M1
>
> Attachments: DIRMINA-295-mikeheath.patch, DIRMINA-495-3.patch,
> IoConnector.patch
>
>
> It is often necessary to pass information into the IoHandler associated with
> an IoConnector. Sometimes this information is needed even as early as
> IoSession creation time. A mechanism is needed to pass information in to the
> IoSession at the time you call IoConnector.connect(). Discussing this with
> Mike Heath, we determined that a logical approach could be to have variants
> of the connect() methods that accept information that can be attached to the
> IoSession when it is created.
> One option is to simply pass a Map in to the connect method. The contents of
> the Map would be copied into the IoSession's attribute map after it is
> constructed but before the IoHandler.sessionCreated method is created. In
> addition, it seems likely that in many cases only one entry would need to be
> added - in this case the user could simply do this:
>ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
> Another option would be to use variable argument lists to accept any number
> of key-value pairs. The pairs could be represented by a class -
> AttributePair for example. It could look like this:
>public final class AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value =
> value; }
>public static AttributePair pair(K key, V value) { return
> new AttributePair(key, value); }
>}
> Then the user can use static imports to pull in the "pair" method. The
> connect() method on IoConnector could accept a variable list of AttributePair
> objects, so the user could write code like this:
> ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
> myValue2));
> Though this approach is somewhat more complicated than just using a Map.
> Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551062
]
David M. Lloyd commented on DIRMINA-495:
Works for me. As long as it's definitely called before the sessionCreated()
filter chain/handler method :-)
> IoConnector needs a way to store information into the IoSession before the
> IoHandler gets ahold of it
> -
>
> Key: DIRMINA-495
> URL: https://issues.apache.org/jira/browse/DIRMINA-495
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: David M. Lloyd
>Assignee: Mike Heath
> Fix For: 2.0.0-M1
>
> Attachments: IoConnector.patch, IoConnector.patch
>
>
> It is often necessary to pass information into the IoHandler associated with
> an IoConnector. Sometimes this information is needed even as early as
> IoSession creation time. A mechanism is needed to pass information in to the
> IoSession at the time you call IoConnector.connect(). Discussing this with
> Mike Heath, we determined that a logical approach could be to have variants
> of the connect() methods that accept information that can be attached to the
> IoSession when it is created.
> One option is to simply pass a Map in to the connect method. The contents of
> the Map would be copied into the IoSession's attribute map after it is
> constructed but before the IoHandler.sessionCreated method is created. In
> addition, it seems likely that in many cases only one entry would need to be
> added - in this case the user could simply do this:
>ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
> Another option would be to use variable argument lists to accept any number
> of key-value pairs. The pairs could be represented by a class -
> AttributePair for example. It could look like this:
>public final class AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value =
> value; }
>public static AttributePair pair(K key, V value) { return
> new AttributePair(key, value); }
>}
> Then the user can use static imports to pull in the "pair" method. The
> connect() method on IoConnector could accept a variable list of AttributePair
> objects, so the user could write code like this:
> ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
> myValue2));
> Though this approach is somewhat more complicated than just using a Map.
> Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551060
]
Mike Heath commented on DIRMINA-495:
In MINA 1.x you can pass the IoHandler into in the connect method. This is not
the case in MINA 2.0.
I really like the idea of being able to pass in a callback. I'm not so sure I
like the idea of using an IoFutureListener though because it would require
creating a SessionFuture type that would only be used to pass the session into
the IoFutureListener.
An interface like:
public interface SessionCallback {
void onSession(IoSession session);
}
is simple and sufficient callback mechanism, IMO.
WDYT?
> IoConnector needs a way to store information into the IoSession before the
> IoHandler gets ahold of it
> -
>
> Key: DIRMINA-495
> URL: https://issues.apache.org/jira/browse/DIRMINA-495
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: David M. Lloyd
>Assignee: Mike Heath
> Fix For: 2.0.0-M1
>
> Attachments: IoConnector.patch, IoConnector.patch
>
>
> It is often necessary to pass information into the IoHandler associated with
> an IoConnector. Sometimes this information is needed even as early as
> IoSession creation time. A mechanism is needed to pass information in to the
> IoSession at the time you call IoConnector.connect(). Discussing this with
> Mike Heath, we determined that a logical approach could be to have variants
> of the connect() methods that accept information that can be attached to the
> IoSession when it is created.
> One option is to simply pass a Map in to the connect method. The contents of
> the Map would be copied into the IoSession's attribute map after it is
> constructed but before the IoHandler.sessionCreated method is created. In
> addition, it seems likely that in many cases only one entry would need to be
> added - in this case the user could simply do this:
>ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
> Another option would be to use variable argument lists to accept any number
> of key-value pairs. The pairs could be represented by a class -
> AttributePair for example. It could look like this:
>public final class AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value =
> value; }
>public static AttributePair pair(K key, V value) { return
> new AttributePair(key, value); }
>}
> Then the user can use static imports to pull in the "pair" method. The
> connect() method on IoConnector could accept a variable list of AttributePair
> objects, so the user could write code like this:
> ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
> myValue2));
> Though this approach is somewhat more complicated than just using a Map.
> Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550970
]
David M. Lloyd commented on DIRMINA-495:
That seems reasonable - with a general callback you could cleanly add
attributes. BUT we'd have to ensure that the callback is called -immediately-
after the session is created. The regular ConnectFuture callback doesn't
happen until the connect completes - which is too late :-)
So maybe a new "SessionFuture" type is called for?
Also the callback method should be allowed to throw exceptions.
You could then do this (which would meet the requirements of this issue):
connector.connect(addr, new IoFutureListener() {
void operationComplete(SessionFuture future) {
future.getSession.setAttribute(MY_KEY, myVal);
}
}
> IoConnector needs a way to store information into the IoSession before the
> IoHandler gets ahold of it
> -
>
> Key: DIRMINA-495
> URL: https://issues.apache.org/jira/browse/DIRMINA-495
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: David M. Lloyd
>Assignee: Mike Heath
> Fix For: 2.0.0-M1
>
> Attachments: IoConnector.patch, IoConnector.patch
>
>
> It is often necessary to pass information into the IoHandler associated with
> an IoConnector. Sometimes this information is needed even as early as
> IoSession creation time. A mechanism is needed to pass information in to the
> IoSession at the time you call IoConnector.connect(). Discussing this with
> Mike Heath, we determined that a logical approach could be to have variants
> of the connect() methods that accept information that can be attached to the
> IoSession when it is created.
> One option is to simply pass a Map in to the connect method. The contents of
> the Map would be copied into the IoSession's attribute map after it is
> constructed but before the IoHandler.sessionCreated method is created. In
> addition, it seems likely that in many cases only one entry would need to be
> added - in this case the user could simply do this:
>ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
> Another option would be to use variable argument lists to accept any number
> of key-value pairs. The pairs could be represented by a class -
> AttributePair for example. It could look like this:
>public final class AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value =
> value; }
>public static AttributePair pair(K key, V value) { return
> new AttributePair(key, value); }
>}
> Then the user can use static imports to pull in the "pair" method. The
> connect() method on IoConnector could accept a variable list of AttributePair
> objects, so the user could write code like this:
> ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
> myValue2));
> Though this approach is somewhat more complicated than just using a Map.
> Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550889
]
Niklas Therning commented on DIRMINA-495:
-
I ran into a similar situation some time ago though I wanted to do more with
the session than add attributes. First I thought I could just use an
IoFutureListener and access the new session there. I soon realized that this
wouldn't work since I needed my IoFutureListener to be called before
sessionCreate() on my IoHandler. There's no way to guarantee that that happens
in this order with MINA 1.x.
I ended up with something like
connector.connect(address, new IoHandlerProxy(realIoHandler) {
public void sessionCreated(IoSession session) {
// Do whatever it was I needed to do with the session here
super.sessionCreated(session);
}
}
IoHandlerProxy is a simple custom class which let's me intercept calls to the
real IoHandler. I think you get the point.
My point here is that there may be other things than adding attributes one
might want to do before sessionCreated() is called. If connect() would take a
ConnectCallback as an argument the user could do whatever she wants before the
IoHandler is called, not just add attributes.
ConnectCallback would be very similar to IoFutureListener so maybe we could use
that and connect() would automatically set the IoFutureListener on the
ConnectFuture. In that way it is guaranteed that the listener is called before
the IoHandler is called.
With this it would be simple to add attributes to the session:
connector.connect(add, new IoFutureListener() {
void operationComplete(ConnectFuture future) {
if (future.isConnected()) {
future.getSession().addAttribute(...);
}
}
});
We could still also add a connect(addr, Map) method to IoConnector but it would
be implemented like the above.
WDYT?
> IoConnector needs a way to store information into the IoSession before the
> IoHandler gets ahold of it
> -
>
> Key: DIRMINA-495
> URL: https://issues.apache.org/jira/browse/DIRMINA-495
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: David M. Lloyd
>Assignee: Mike Heath
> Fix For: 2.0.0-M1
>
> Attachments: IoConnector.patch, IoConnector.patch
>
>
> It is often necessary to pass information into the IoHandler associated with
> an IoConnector. Sometimes this information is needed even as early as
> IoSession creation time. A mechanism is needed to pass information in to the
> IoSession at the time you call IoConnector.connect(). Discussing this with
> Mike Heath, we determined that a logical approach could be to have variants
> of the connect() methods that accept information that can be attached to the
> IoSession when it is created.
> One option is to simply pass a Map in to the connect method. The contents of
> the Map would be copied into the IoSession's attribute map after it is
> constructed but before the IoHandler.sessionCreated method is created. In
> addition, it seems likely that in many cases only one entry would need to be
> added - in this case the user could simply do this:
>ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
> Another option would be to use variable argument lists to accept any number
> of key-value pairs. The pairs could be represented by a class -
> AttributePair for example. It could look like this:
>public final class AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value =
> value; }
>public static AttributePair pair(K key, V value) { return
> new AttributePair(key, value); }
>}
> Then the user can use static imports to pull in the "pair" method. The
> connect() method on IoConnector could accept a variable list of AttributePair
> objects, so the user could write code like this:
> ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
> myValue2));
> Though this approach is somewhat more complicated than just using a Map.
> Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550842
]
Mike Heath commented on DIRMINA-495:
I've taken an initial stab at this issue too and have a patch at
http://swamp.homelinux.net/mina/mina-495.patch for people to review. I think
this will take a little more discussion to determine that best approach at
solving it.
> IoConnector needs a way to store information into the IoSession before the
> IoHandler gets ahold of it
> -
>
> Key: DIRMINA-495
> URL: https://issues.apache.org/jira/browse/DIRMINA-495
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: David M. Lloyd
>Assignee: Mike Heath
> Fix For: 2.0.0-M1
>
> Attachments: IoConnector.patch, IoConnector.patch
>
>
> It is often necessary to pass information into the IoHandler associated with
> an IoConnector. Sometimes this information is needed even as early as
> IoSession creation time. A mechanism is needed to pass information in to the
> IoSession at the time you call IoConnector.connect(). Discussing this with
> Mike Heath, we determined that a logical approach could be to have variants
> of the connect() methods that accept information that can be attached to the
> IoSession when it is created.
> One option is to simply pass a Map in to the connect method. The contents of
> the Map would be copied into the IoSession's attribute map after it is
> constructed but before the IoHandler.sessionCreated method is created. In
> addition, it seems likely that in many cases only one entry would need to be
> added - in this case the user could simply do this:
>ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
> Another option would be to use variable argument lists to accept any number
> of key-value pairs. The pairs could be represented by a class -
> AttributePair for example. It could look like this:
>public final class AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value =
> value; }
>public static AttributePair pair(K key, V value) { return
> new AttributePair(key, value); }
>}
> Then the user can use static imports to pull in the "pair" method. The
> connect() method on IoConnector could accept a variable list of AttributePair
> objects, so the user could write code like this:
> ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
> myValue2));
> Though this approach is somewhat more complicated than just using a Map.
> Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
