Well I think this conflicts (or is it complement?) with Paul's idea of giving a very descriptive class names for developers (user) where they would know exactly what they are going to get from the class name. If we use a factory the user doesn't know what the real implementation which got instantiated since its depends on the configuration. Actually the idea is, he doesn't need to know since he must have ask for it or he should get what is appropriate using the configuration.
/Sanjaya On Wednesday 05 December 2007, Sanjiva Weerawarana wrote: > I hate factories; see: > http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 > > OTOH, I can see the value of being able to switch the underlying impl > based on config. So .. begrudging +1. > > However, this does not change the need to fix up the current constructors > correctly. So I suggest we do that immediately and then layer the > factories on top as soon as Glen has it working. > > Sanjiva. > > Paul Fremantle wrote: > > Glen > > > > Could you commit a starting point for the factory. I think I'd find it > > easier to look at some code and play around. > > > > Thanks > > > > Paul > > > > Glen Daniels wrote: > >> Hi folks! > >> > >> Sorry for the somewhat late response. > >> > >> +1 to the APIs below, I totally agree that "falling back" to a different > >> implementation type is not really appropriate if you use a particular > >> constructor. However... > >> > >> I think that a factory approach is probably better long run, in order to > >> support scenarios where we use configuration, not coding, to change > >> which implementation you're using. In particular, I'd like to be able > >> to swap JDBCRegistry or InMemoryRegistry for RemoteRegistry after a > >> system has been built and deployed. (use cases for this have been > >> discussed previously) > >> > >> One way to do this: > >> > >> // Assume static (or thread-based) configuration > >> Registry registry = RegistryFactory.getRegistry(credentials); > >> > >> or > >> > >> // Specify configuration > >> RegistryFactory fac = new RegistryFactory(config); > >> Registry registry = fac.getRegistry(credentials); > >> > >> By default, this can return an InMemoryRegistry, but via a system > >> property or a configuration parameter, it can be changed to some other > >> implementation. The credentials argument can be null, or can be a > >> username/pw or something like a certificate or even a custom User > >> object. The config argument would be a Map of properties. > >> > >> Another way to do this would be with injection, but then we'd need to > >> settle on a framework for that. I think a factory is simpler for now. > >> > >> Thoughts? > >> > >> Thanks, > >> --Glen > >> > >> Paul Fremantle wrote: > >>> Let's hear from Glen - he has a great sense of good APIs. > >>> > >>> Paul > >>> > >>> Chathura C. Ekanayake wrote: > >>>> I like it too. Then the constructors imply what is happening inside. > >>>> Shall I change the code according to this? > >>>> > >>>> Thanks, > >>>> Chathura > >>>> > >>>> Paul Fremantle wrote: > >>>>> I understand that we are using HSQLDB to provide the in-memory DB, > >>>>> its just a bit odd that the class is called JDBCRegistry. > >>>>> > >>>>> From a beginners perspective, wouldn't it make more sense to have > >>>>> another class called InMemoryRegistry. Of course under the covers > >>>>> it can use the JDBCRegistry with HSQLDB? > >>>>> > >>>>> I'm just trying to think of this from a beginning programmers > >>>>> perspective, and I'm not convinced everyone is going to > >>>>> automatically think of using a JDBCRegistry to do in-memory. > >>>>> > >>>>> So my preference would be: > >>>>> > >>>>> new InMemoryRegistry() > >>>>> new JDBCRegistry(String datasourceName) - Use the given data source. > >>>>> new JDBCRegistry(String driverClass, String URL, String userName, > >>>>> String password) - Use given connection URL to connect to the DB > >>>>> > >>>>> > >>>>> Paul > >>>>> > >>>>> Chathura C. Ekanayake wrote: > >>>>>> +1. So shall we remove "allowInMemoryDB" parameter from all > >>>>>> constructors and only start the in-memory database if the default > >>>>>> constructor is used. > >>>>>> > >>>>>> Then the constructors would look like: > >>>>>> > >>>>>> 1) JDBCRegistry() - Use in-memory DB. > >>>>>> > >>>>>> 2) JDBCRegistry(String datasourceName) - Use the given data source. > >>>>>> > >>>>>> 3) JDBCRegistry(String driverClass, String URL, String userName, > >>>>>> String password) - Use given connection URL to connect to the DB > >>>>>> > >>>>>> Thanks, > >>>>>> Chathura > >>>>>> > >>>>>> Paul Fremantle wrote: > >>>>>>> I'm bothered about the "fallback" to an inmemory database. I > >>>>>>> don't think that makes sense as something to do automatically. > >>>>>>> > >>>>>>> Surely its better for a user to explicitly try to start the > >>>>>>> JDBCReg and if that fails catch the exception or null and then > >>>>>>> create an in-mem Reg? > >>>>>>> > >>>>>>> Paul > >>>>>>> > >>>>>>> Sanjiva Weerawarana wrote: > >>>>>>>> +1 for 3 alternative constructors. Since the registry is > >>>>>>>> unusable until init'ed, IMO constructors make more sense. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> > >>>>>>>> Sanjiva. > >>>>>>>> > >>>>>>>> Chathura C. Ekanayake wrote: > >>>>>>>>> We want to allow users to configure registry database in > >>>>>>>>> different ways (e.g. using a data source, using a connection > >>>>>>>>> URL, specify whether to start in-memory database if other > >>>>>>>>> database is not available). > >>>>>>>>> > >>>>>>>>> So we provide few methods in the JDBCRegistry to configure > >>>>>>>>> them. We only want the registry to initialize after those > >>>>>>>>> parameters are configured. > >>>>>>>>> And we don't know whether the user is specifying them or not at > >>>>>>>>> the construction time. Therefore, user has to call init() after > >>>>>>>>> configuring them. > >>>>>>>>> > >>>>>>>>> Alternative would be to have 3 constructors. > >>>>>>>>> > >>>>>>>>> 1) JDBCRegistry() - Use default datasource name if available. > >>>>>>>>> If not available, use in-memory DB > >>>>>>>>> > >>>>>>>>> 2) JDBCRegistry(String datasourceName, boolean allowInMemoryDB) > >>>>>>>>> - Use given data source. If not available, use in-memory DB > >>>>>>>>> depending on the allowInMemoryDB parameter value > >>>>>>>>> > >>>>>>>>> 3) JDBCRegistry(String driverClass, String URL, String > >>>>>>>>> userName, String password, boolean allowInMemoryDB) - Use given > >>>>>>>>> connection URL to connect to the DB > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Chathura > >>>>>>>>> > >>>>>>>>> Paul Fremantle wrote: > >>>>>>>>>> Chathura C. Ekanayake wrote: > >>>>>>>>>>> JDBCRegistry registry = new JDBCRegistry(); > >>>>>>>>>>> registry.init(); > >>>>>>>>>> > >>>>>>>>>> Love it! That's what I was looking for. > >>>>>>>>>> > >>>>>>>>>> Last question - why do we need init()? > >>>>>>>>>> > >>>>>>>>>> Paul > >> > >> _______________________________________________ > >> Registry-dev mailing list > >> [email protected] > >> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev _______________________________________________ Registry-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
