[Registry-dev] Registry as a library inside other products
Chathura C. Ekanayake
chathura at wso2.com
Mon Dec 17 02:00:27 PST 2007
I changed the registry code as discussed in this thread. Details of the
changes are sent in the mail "Refactoring of registry constructors".
Thanks,
Chathura
Sanjaya Karunasena wrote:
> 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 at wso2.org
>>>>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Registry-dev mailing list
>>>>>>>>>> Registry-dev at wso2.org
>>>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Registry-dev mailing list
>>>>>>> Registry-dev at wso2.org
>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>>>>>>>
>>> _______________________________________________
>>> Registry-dev mailing list
>>> Registry-dev at wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>>>
>> _______________________________________________
>> Registry-dev mailing list
>> Registry-dev at wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>>
>
>
> _______________________________________________
> Registry-dev mailing list
> Registry-dev at wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>
>
More information about the Registry-dev
mailing list