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
[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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
Registry-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
