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
:
> >> * 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
> >
Sorry not to reply earlier. Comments inline.
* There is a "init" method which does lot of datasource related work.
+1 I thought we had consensus to get rid of these and just use
constructors.
JDBCRegistry(DataSource dataSource)
+1
If what user has is a DB URI... he will,
new JDBCRegi
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 whic
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 instan
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 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 do
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
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
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
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.
Paul
Sanjiva Weerawarana wrote:
+1.
Paul Fremantle wrote:
I understand that we are using HSQLDB to pr
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
suppor
+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
u
Hi Paul,
The datasource I am refering here is the java.sql.Datasource interface. So
what you get is a java.sql.Connection which you will be using internally like
you do now.
Also this helps you to overcome the problem of having to treat a registry
which need to work with a JDBC datasource as
Sanjaya
We did already look at this design where there were two key interfaces:
the Registry interface and behind this a DataStore interface. However,
we realized that the underlying datastore had to implement almost ALL
the logic that was in the Registry interface, so instead we refactored
i
Hi Chathura,
I see few OO problems here.
First, InMemoryRegistry, JDBCRegistry doesn't sound polymorphic. It simply
exposed implementation details. Do you have an abstract class Registry?
What we have here is a Registry which can work with different Datasources. If
a datasource is not availabl
I am in agreement with Paul. Doing magic in your code is bad. If it is a bad
datasource throw an exception. Let the programmer to tell you what exactly
he want. Give him a constructor to create a registry with an in-mem database.
Makes the programming model simple, easy to understand.
Thanks
S
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
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
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
>
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 HSQL
+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.
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 Weerawaran
23 matches
Mail list logo
