RE: [mina] Introducing the New API for 0.9.1.

[Jose Alberto Fernandez]

From: Trustin Lee [mailto:[EMAIL PROTECTED] 2006/1/25, Jose Alberto Fernandez <[EMAIL PROTECTED]>: I think we need to define better how is it that we want MINA to be configured and used. When people use the Spring approach, they definitely want to be in control of the objects they create and of the scope of those objects in the system. Singletons are a no-no on that regard. It should be up to the Spring configuration to decide whether an object should be a singleton or not. We already discussed on singleton issues and we'll provide a non-singleton way.   On the same vein, when we compose a system out of different components, we also want to maintain unknown interactions of the components to a minimum. What is the 'unknown interaction' here?  I don't think we cause any unknown interaction.  Besides adding a thread pool by default, what IoService does is almost the same with the code that configures your acceptors and connectors manually.   For example:    Component A does: IOService.connect(…..); (Maybe more than once)      Component B independently does: IOService.connect(….); (maybe more than once)   Now component A decides to go away and shut itself down: IOService.unbindAll(); Ups, Component B just lost all its connections and does not know about it.   These are unknown interactions due to the usage of a singleton.     I did not fully like SimpleServiceRegistry in particular because it had endless amounts of methods depending on the kind of service one wanted, but at least when one called unbindAll() I knew the scope of what was been unbound. I would like IOService to work the same way in that regard. The only thing I would be willing to have statically is some registry of all the IOServices currently available, to be able to do global management. Something like:   /**    * Creates if necessary and returns the IOService instance of that name   */   public static IOservice getInstance(String name);   /**    * List all the current active IOService instances    */   public static IOService[] listInstances(); It would be nice if we have this kind of feature, but do we really need these registry methods?  Is the 'name' an ID of IoService instance?   As I said, maybe they belong on some factory. The reason for having something like this is management. You have a system build by several components that can independently be using MINA. But you still want a way to tell everyone to shutdown when you want the system to go down. As the server will stay alive until all the IOServices finish, you need a way to tell them to shut down gracefully.   These are just loose ideas, not an API. Maybe what is needed is a notification mechanism. Something like:   public static IOService getInstance(UnbindListener listener);   public static void shutdownIOServices();   public interface UnbindListener {       void unbind(IOConnector);     void unbind(IOAcceptor); }   In this model, when you obtain an IOService you provide a listener where the component will receive notifications of connections being terminated and hence has a chance to update its state accordingly. Each component can do as it see fits, and will only be notified about things created by his own IOService instance.       Here I am a little ambivalent. I am all for type safety. But I like the simplicity of addressing using a URI and being able to pass parameters at the same time. On the other hand, the objects returned by the methods should be manageable using set/getters, which means for each type of URI one should define a proper interface that define all its properties. The URL parameters can be simply introspected on the setters. I didn't get what you're saying.  Could you give me an example?   I do not have your code in front of me so this is just from what I understood from reading the messages on this thread.   So you have different types of URLs:   String  url = "">nio:socket:*:8080?reuseAddress=true&threadModel=normal&threadPoolSize=20&receiveBufferSize=4096",   You get from your IOService instance a URL-like object, x (or y), already introspected to set the parameters passed in the URL.      IOAcceptor x = ioService.getAcceptor(url);      IOConnector y = ioService.getConnector(url);   After that, you could set more properties programmatically by downcasting to the correct type (interface) specific to the URL you requested.      ((IOSocketAcceptor) x).setXYZ(….);   Now you can call on the object to actually perform the connection or binding, passing the handlers and filters.     x.bind(filterBuilder, handler);     y.connect(filterBuilder, handler);   Jose Alberto