[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] Ldbc
Peter Bennett wrote:
Marcel Ruff wrote:
Peter Bennett wrote:
Greetings
Have uploaded the Ldbc stuff...
I ran a few more tests yesterday and today...
I think I have a problem with one topic test.
testVolatile...
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 build ldbc.
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
ldbc driver.
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
LdbcManagerCommonTable,
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
the diffs.
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 enough.
OK, thanks for all this, we look towards a bright ldbc future ...
regards,
Marcel
ldbc does not support cascade delete so I added some code and am not
sure I am deleting enough...
Regards
--
http://www.xmlBlaster.org