[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] Ldbc
I have looked at the code and in fact it should be possible to implement
all in one single common code by adding two more configuration parameters.
Paring the mapping should be possible after some code modification (the
',' inside a mapping should not break in future)
Before I start however I want to make sure the current code works. I
tested the ldbc with postgres and there is one only error in the
testsuite. It fails when making the request in peekBySamePriority when
12 entries in the queue and 4 entries expected to be peeked. The statement:
"SELECT * from TEST_ENTRIES where
queueName='callback_QueuePluginpeekMsg' and nodeId='xmlBlaster' and
prio=(select max(prio) from TEST_ENTRIES where
queueName='callback_QueuePluginpeekMsg' AND nodeId='xmlBlaster') ORDER
BY dataId ASC"
with the error
[Nov 18, 2003 10:05:08 PM TRACE LdbcPreparedQuery] Constructor.
Any idea about the cryptic 37000 ?
About the tests: I think it is not necessary to write new tests: the
criteria that the old tests should pass should be sufficient.
Marcel Ruff wrote:
Peter Bennett wrote:
Marcel Ruff wrote:
Peter Bennett wrote:
Have uploaded the Ldbc stuff...
I ran a few more tests yesterday and today...
I think I have a problem with one topic test.
I have no doubt it will need some more work...
I already need to add a couple of notes to the ldbc requirement...
(1) JDK 1.4 only.
Hu, does this mean that xmlBlaster is not compiling / running
with JDK 1.3 / 1.2 anymore?
No... Just the ldbc driver is compiled under 1.4. I just read the ldbc
howto again and I missed something... It can be compiled under JDK1.3.
I better redo the jar under 1.3. Should I upload a set of docs for ldbc?
Probably its better to add those links to the ldbc requirement.
(2) No Oracle support in ldbc.jar
Well, we still have the native Oracle support.
Ldbc does support Oracle... I don't however. Its scary.
From the ldbc howto... The Oracle JDBC driver needs to be in the
build class path. I don't have a recent Oracle jdbc driver. Oracle
users need to roll there own. Or somebody in the team download and
I have Oracle installed when i find time i'll look at it.
I think I need some Oracle files to compile Oracle support into the
As you will see the code is virtually identical to the commontable
plugin. The part I am not 100% sure of is the routine to delete stuff.
diff JdbcConnectionPool.java LdbcConnectionPool.java
diff JdbcManagerCommonTable.java LdbcManagerCommonTable.java
diff JdbcQueueCommonTablePlugin.java LdbcQueueCommonTablePlugin.java
diff PreparedQuery.java LdbcPreparedQuery.java
It seems that only JdbcManagerCommonTable is replaced by
only LdbcManagerCommonTable.java has two places with additional code.
We should somehow merge the files to avoid having duplicate code
and duplicate errors, probably having a common interface class
and having a factory to create with or without ldbc. Any idea?
Yes... I am sure Michele could look at the diffs and figure something
out... But. Its just I hate getting him to make changes to support
Ldbc/MySQL or whatever. I can put watches on the relevant files and do
Yes/No :-) The problem is that everything should be automatically
tested - otherwise one never knows if something broke or us outdated ...
One day we'll find a smart solution for this ;-)
There are many modules in xmlBlaster already (just think of the
python clients, JMX parts, Peter Antmans' jboss extensions ...) -
we definitely need automatic testcases for each piece and avoid
code duplication - how else shall we keep everything together?
We need to discuss if we really want to drop JDK 1.3 and 1.2 support.
From the ldbc howto... Most likely JDK 1.2 also works.
I have no problems if it goes no further at present. It is just a go
at abstraction. I will continue to work with it to see if I can
improve and develop it. It is most certainly less strain on me if the
development code is in the repository and it opens up the chance for
others to look at it and test on there platforms if they are brave
OK, thanks for all this, we look towards a bright ldbc future ...
ldbc does not support cascade delete so I added some code and am not
sure I am deleting enough...
mailto:laghi at swissinfo.org
tel. +46 8 7492952 / mob. +46 70 4103964