There is another setting that can be of great value in debug process:
.NET: Db4oFactory.Configure().ExceptionsOnNotStorable (true)
In some environments (especially those that provide plugin mechanics or perform some kind of class reloading) you may encounter strange problems due to classloader issues. These environments include servlet containers, Eclipse plugins, reloading JUnit test runners, etc.
In most of those cases db4o will fail quietly (i.e. will not deliver any results on queries), unless you have configured #exceptionsOnNotStorable(true) - then you may see messages related to not being able to store db4o internal classes or set db4o internal translators, etc.
Db4o uses the context classloader by default. This is an appropriate choice in most situations, but it's not really reliable, since the concrete context classloader depends on the environment you're running in. Therefore you can explicitly specify the classloader to be used for db4o operation by calling
.NET: Db4oFactory.Configure()ReflectWith(new JdkReflector(classLoader))
Basically you just have to find out the appropriate classloader and configure db4o accordingly. The right choice depends on the specific classloader hierarchy of your application context. Two examples:
The approach to solving classloader problems (not only for db4o, but generally) is:
See also:Classloader issues
#exceptionsOnNotStorable(true) will also help you to identify classes that db4o cannot persist.
db4o needs a constructor that it can use to create user objects. Ideally this is a zero-parameter constructor (declared public for Java JDK versions prior to JDK 1.2). If db4o does not find a zero-parameter constructor, it iterates through all other constructors and internally attempts to create an instance of an object by passing appropriate null parameters. If this is successful with any of the present constructors, this constructor is used.
There are classes that do not have usable constructors. java.net.URL is an example from the Java JDK. In this case you have the following options:
If you need to quickly implement a solution for one of the JDK classes, and querying members is not an issue, you may choose to use the built-in serializable translator. Here is an example, how this is done for java.net.URL:
.NET: Db4oFactory.Configure().ObjectClass("java.net.URL").Translate(new TSerializable());
The above code needs to be executed every time before the db4o engine is started. See also:Constructors, Translators.
Another db4o system, which can give you a valuable feedback about db4o functioning in your application is Diagnostics.