Since no one reply to my mail on this regard, I created a JIRA. https://wso2.org/jira/browse/REGISTRY-23
:-) /Sanjaya On Wednesday 05 December 2007, Sanjaya Karunasena wrote: > I went through the code in SVN last night. Here are few problems I have > noticed. > > * There is a "init" method which does lot of datasource related work. > > First of all having a init method in a OO code doesn't make sense. YES, IOC > containers use this since they can't handle any thing else while doing > constructor injection. But we shouldn't follow that. > > This code actually belong to a RegistryDatasource class, which should > ideally implement java.sql.Datasource. Then we are clean. > > * There is a ConnectionFactory class which does a trick. > > Given a java.sql.Datasource or a DB URI it gives a java.sql.connection. > However, when a DB URI is given it uses the DriverManager. Please read the > Java doc. The connections you get have very different QoS properties. If I > am a user I will assume the Registry nicely encapsulate all of that and > give me a very reliable connectivity to the datasource, which is not the > case. > > Another reason to have our own RegistryDatasource class. > > So that way we need one constructor; > > JDBCRegistry(DataSource dataSource) > > If what user has is a DB URI... he will, > > new JDBCRegistry( new RegistryDatasource(DB URI, ...) ) > > * The SecureRegistry doesn't completely encapsulate the Registry > > Right now the user has to construct a Registry and pass it to the > SecureRegistry. The problem here is, there is insecure access to the same > registry since the use build that externally. If we aggregate the Registry > in to the SecureRegistry, an instance of a SecureRegistry is always secure. > > > > BTW, I was thinking about Paul's reason to have a JDBCRegistry class and a > InMemory Registry class where he would like the developer to know what > exactly he is going to get just looking at the class name (without reading > the Javadoc). In that case how about naming them as, "PersistentRegistry" > and "TransientRegistry"? > > /Sanjaya > > On Wednesday 05 December 2007, Chathura C. Ekanayake wrote: > > Paul Fremantle wrote: > > > Sanjaya has also persuaded me (on IM) that we should add another > > > constructor > > > > > > new JDBCRegistry(DataSource dataSource) > > > > > > I'm not sure if there is an equivalent that uses a Connection as well. > > > > I think Sanjaya is proposing to have a DataSource implementation that > > can wrap a Connection to handle this scenario. > > So we need only one constructor to instantiate a registry with a > > database connection (datasource or connection). > > > > Thanks, > > Chathura > > > > > Paul > > > > > > Sanjiva Weerawarana wrote: > > >> +1. > > >> > > >> 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 > > >>>>>>>> Registry-dev@wso2.org > > >>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev > > >>>>>>> > > >>>>>>> _______________________________________________ > > >>>>>>> Registry-dev mailing list > > >>>>>>> Registry-dev@wso2.org > > >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev > > >>>> > > >>>> _______________________________________________ > > >>>> Registry-dev mailing list > > >>>> Registry-dev@wso2.org > > >>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev > > > > _______________________________________________ > > Registry-dev mailing list > > Registry-dev@wso2.org > > http://wso2.org/cgi-bin/mailman/listinfo/registry-dev > > _______________________________________________ > Registry-dev mailing list > Registry-dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/registry-dev _______________________________________________ Registry-dev mailing list Registry-dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
