|
|
|
> What is the main driver for this ?
I am using castor in a GUI application. At program startup there is a login String db_name = "MyApp#" + db_url + "#" + _username; _jdo.setDatabaseName(db_name); StringReader reader = new StringReader(conf_str); [By the way: This could be made much easiear if Castor had a method for At the first login the user is prompted to change its password. (for security > And why is it not an option for you to take the JVM running Castor down ? This is no option because the application should remain running - otherwise the Martin, could you please write a quick JUnit test to verify this patch? I'd like
to add this to CVS, but the lack of a test is slowing me down and I don't currently have the time to write a test for it myself. One other thought that I had on this subject was to overload the Created an attachment (id=584)
DBRegistryTest.java Created an attachment (id=585)
oracle.xml DB-config 1 Created an attachment (id=587)
empty mapping file OK, I wrote a JUnit test case for the pending patch.
It logs in to the database using the default password "sectret". Without the call to DatabaseRegistry.clear() the second login will fail. Can I rename attachements in Bugzilla after posting them?
I can't find an option for that, so here are the missing file names:
> One other thought that I had on this subject was to overload the I would appreciate that very much. This would be a much cleaner way For the current version of Castor in CVS there is an additional call to
JDOConfLoader.deleteConfiguration() necessary to reset the JDO configuration data. Martin, based on your last comment above, can you please re-create your patch,
and attach it to this bug report. Once that's in, I'll get this committed, and add the setConfiguration() overload as well (if possible). Created an attachment (id=650)
OK, here is the updated patch. Thank you. I am just looking at the patch, but because of your dependency on
Oracle, it's quite hard for me to run things. Why not create and alter some entity that maps to a simple table, and attach entity class and mapping to this bug report. Martin, in your code example above, can you please give an idea how a value for
map_url might look like ? Created an attachment (id=657)
Revised patch. Above patch (in addition to Martin's contribution) provides a
JDO.setConfiguration (JdoConf) method. I have not had any time (yet) to get a test case done for this addition, but have successfully amended the test case as provided by Martin to access AccountNature instances based on different mapping files. Actually, having said that, somehow I should make it clear that there's a
certain level of 'ugliness' in JDO.java. By introducing JDO.setConfiguration (JdoConf), I had to find a way to store the JdoConf instance somewhere - thus I introduced a new member named _jdoConf, and renamed the existing one to _jdoConfURI. Have a look at JDO.getDatabase() to see how these two members are used to load one or the other configuration. I am really tired today, so suggestions how to improve this are welcome. Btw, here's one way of improving things without much work. When setting a URI
for a JDO configuration file, try to unmarshall the configuration file immediately, and sore the result in one and one instance variable only: _jdoConf (of type JdoConf). Of course this would remove 'lazy configuration' instantiation, but who cares .. ![]() Sure. The value of map_url is for example:
"file:/D:/src/test_app/bin/de/mentopolis/test_app/jdo/DBMapping.xml" It's the URL from where Castor shall load the mapping configuration file. When Thanks, Martin. I just wanted to make sure that you are using absolute URIs,
indeed. This way (and only this way), things should work. Hi Werner,
I tried your patch and fixed it to avoid NULL pointer exceptions while calling public Database getDatabase() if ( DatabaseRegistry.getDatabaseRegistry( _dbName ) == null ) { This way I successfully used a prepared JdoConf instance in my application. > When setting a URI for a JDO configuration file, try to unmarshall I think this would be a good idea. Created an attachment (id=661)
JdoConfHelpers I attached a file containing a few helper classes to make it easy to configure
the Castor database connection without a XML file. Using them this task becomes as simple as: JDO jdo = new JDO(); jdo.setDatabaseName("db"); JdoDriverConf driverConf = new JdoDriverConf(s_jdo_driver_name, db_url, Some questions to this:
> Do you think the overloaded constructors should be integrated directly
> in the already existing org.exolab.castor.jdo.conf classes or better > remain as separate classes? One should definitely not integrate them with the existing castor.jdo classes, as they are auto-generated from an XML Schema instance. > If not - should they be integrated into Castor or remain in the Why not create a factory class (JdoConfFactory) that offered a couple of static >Should I create a new bugzilla entry for this new enhancements? >> When setting a URI for a JDO configuration file, try to unmarshall
>> the configuration file immediately, and store the result in one and >> one instance variable only: _jdoConf (of type JdoConf). > >I think this would be a good idea. Any objections ? None at all. I was literally just thinking that this is desperately important to us.
![]() clear the JDO instance on unload... However, to be honest, what I actually want is to "de-register" the databases I've registered Basically, I'd like DatabaseRegistry to become a first-class, publically accessible thing that we can load However, that's a topic for another bug, if any at all (maybe I'm nuts, after all) and I'd just like to say: +1. (just read the whole thing. I should know better.)
Can I say +2, or do I only get one vote? Created an attachment (id=667)
OK, here is the new JdoConfFactory class for convenient creation of JDO configurations without the need of a database configuration XML file. Great. Let's see whether I can get this committed tomorrow.
> Can I say +2, or do I only get one vote?
![]() > needing this functionality; this will be an absolutely huge time-saver > on our side, and I'd love to see it in post-haste. Aren't you meant to be going on holiday tomorrow ? So how come you are in desparate need of this ? > However, that's a topic for another bug, if any at all ...
Don't forget to add a new feature request BEFORE you go on holiday .., otherwise it will never happen, as you might have experienced in the past ... ;- ). I, for myself, will be very glad to commit this simple addition as a first Maybe I should ask for money from you guys in London for all this commits .. Created an attachment (id=670)
Final patch Above patch is the total of the contributions above, incl. JdoConfFactory (which
I have moved to the castor.util package, as castor.jdo.conf only holds auto-generated classes). Applied above patch as discussed.
Martin, I've already seen the class Javadocs of JdoConfFactory, but can you I think that sections about JdoConfFactory and JDO.setConfiguration should be Created an attachment (id=682)
Documentation patch > I think that sections about JdoConfFactory and JDO.setConfiguration should be
> added to src/docs/database-conf.xml at least, maybe to src/docs/jdo.xml as well > (in form of a link to database-conf.xml). Not sure where the functionality of clearing a Database instance should go. The patch above contains the documentation about the new setConfiguration() Could you please also apply the following JavaDoc fix: Index: JdoConfFactory.java
Thanks, Martin Thanks, Martin, and I would seriously recommend to change your email address to
something like "mailto:martin-fuchs AT gmx DOT net", to avoid being spammed. Of course you can change the address, if you like. But it's no big problem for
a spammer to decode it then. My address is public through a few mailing lists (and this bugzilla entries) anyway. (Btw: Same with any mail addresses here) But my mail provider's spam filters works quite good. I have just noticed that JDO2 is begging for the loadConfiguration(JdoConf)
method to be added as well. Martin ? When looking at JDO2 I had to notice, the usage of JdoConfFactory has been
broken. I think it's ben the commit of bug 1616, because it's the call to getDatabaseChoice(), that always returns null. Because of this there occure NULLPointer Ecpetions in JdoConfFactory.createJdoDbConf(). Might have a closer look tomorrow... Thanks, Martin, and you might be right that this is a result of committing bug
1616 .. 8-(. Created an attachment (id=728)
fix for JdoConfFactory's DatabaseChoice handling May be we should add some test cases for JdoConfFactory. This way it gets
easier to find such problems. Patch applied, incl. a couple of code improvements in JDO2 (exception handling,
broken JavaDocs, ...). Martin, it looks like JDO is working again, but JDO2 still lacks a
loadConfiguration(JdoConf) method. Whilst this is not high priority, I think we should try to make it for the 0.9.6 release. And mabe we should try to pick up on this old idea below as well.
> When setting a URI for a JDO configuration file, try to unmarshall Created an attachment (id=732)
first patch version for JDO and JDO2 The new patch above includes the requested method JDO2.loadConfiguration
(JdoConf) as well as a revised version of the old JDO class to load the JDO configuration file immediately when calling JDO.setConfiguration(). This already works for my test applications, both using XML configuration files and JDOConfFactory. However the JTF tests don't yet run - they print the following exception Caused by: unable to add attribute "configuration" at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:622) It seems the BASE URI used to load the config file is the current directory Werner,
if you look into the patch you will see it also addresses some other small issues I found on the way:
I asked myself it it would not be better to remove the static variable An additional comment to JDO2: Here is a small usage example: org.exolab.castor.jdo.conf.Database jdoDbConf; String db_url = "jdbc:mysql://localhost:3306/test"; URL map_url = DeptEmp.class.getResource("mapping.xml"); // Set up JDO with the configuration the specified database driver and // Store mapping file location in the configuration // Activate the JDO configuration Created an attachment (id=734)
documentation update This documentation update contains the JDO2 example from above. It also fixes a
few small mistakes of the old JDO examples, and indents them to make it a bit easier to read. Werner, do you think, the JDO2/JdoConfFactory adjustments should still go into
the 0.9.6 release? If not, we might move this into a new bug entry to avoid forgetting about it - this bug here is already closed. ... and if it doesn't make it into 0.9.6, I would like to propose not to
deprecate the whole old JDO class. It should be enough to deprecate only the JDO.setConfiguration(String url) function. Otherwise any usage of JdoConfFactory results in warning messages about the deprecated JDO class. As it stands right now, I honestly do not feel comfortable about making JDO2
available but in an experimental form. As a result, here's what I suggest: a) de-deprecate JDO.java. And now the 'more difficult' part. We need to find a way to prevent users Created an attachment (id=758)
Proposed (final) patch This is a final patch for the 0.9.6 RC, implementing all of the items discussed Created an attachment (id=759)
Proposed (final) patch And once again ... this time without JAR files, etc. |
how you intend to be using this ? What is the main driver for this ? And why is
it not an option for you to take the JVM running Castor down ?