> From: Alex Cruise [mailto:[EMAIL PROTECTED] > > Maarten Bosteels wrote: > > > I really dislike singletons. At least when they have state. > > When I create a new SimpleServiceRegistry instance, I know exactly > > which classes have access to it. > > And unrelated code is not able to mock around with my services. > > Seconded! >
Same here. 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. 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. 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(); But maybe this mathods should be on some Factory class. > > I really prefer the type-safety of setters, and the associated javadoc. > > Seconded! 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 see no reason why we cannot have something very similar to the URL model, where you first get a subclass of IOConnector (for example) with any parameters in the URL already set, and then one does IOConnector.connect(IOHandler), or something like that. Users can in between downcast to an specific interface and change properties programmatically if they want to, but it is not necessary. Jose Alberto
