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
Registry-dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
--
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
email: [EMAIL PROTECTED]; cell: +1 650 265 8311 | +94 77 787 6880
"Oxygenating the Web Service Platform."
_______________________________________________
Registry-dev mailing list
Registry-dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
