[
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<ConnectFuture>() {
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<K, V> {
> private final K key;
> private final V value;
> private AttributePair(K key, V value) { this.key = key; this.value =
> value; }
> public static <K, V> AttributePair<K,V> pair(K key, V value) { return
> new AttributePair<K, V>(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.
