<html>
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>ExceptionsOnNotStorable</title>
<link rel="stylesheet" type="text/css" href="../../../style.css">
</head>
<body>
<div class="CommonContent">
<div class="CommonContentArea">
<h1>ExceptionsOnNotStorable</h1>
<p>There is another setting that can be of great value in debug process:</p>
<span name="cs_wiki_filter" csw_filters="net">
<p>.NET: </p><p><code>configuration.ExceptionsOnNotStorable (true) </code></p>
</span>
<p>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. </p>
<p>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. </p>
<p>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</p>
<span name="cs_wiki_filter" csw_filters="net">
<p>.NET: </p><p><code>configuration.ReflectWith(new JdkReflector(classLoader)) </code></p>
</span>
<p>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:</p>
<ul>
<li>
In servlet containers, there usually should be no problem, since most containers automatically set the context classloader to the webapp classloader. So it shouldn't matter, whether the db4o.jar resides in your webapp's WEB_INF/lib (where it will be loaded by the appropriate classloader itself, anyway) or in one of the shared lib folders (where the classloader responsible for loading db4o will not be able to see webapp specific classes). </li>
<li>
In Eclipse, the context classloader is the system classloader, which is agnostic of plugin-specific classes. You'll have to configure db4o to use your plugin's classloader, e.g. MyPlugin.class.getClassLoader(). (If the db4o.jar resides in your plugin, you'll get the same effect by just using Db4o.class.getClassLoader()). </li>
</ul>
<p>The approach to solving classloader problems (not only for db4o, but generally) is: </p>
<ul>
<li>
identify the classes/libs db4o needs to know </li>
<li>identify the classloader hierarchy of your application context </li>
<li>use the most generic classloader that knows all needed classes, either directly or indirectly via delegation</li>
</ul>
<p>See also:<a href="../../platform_specific_issues/classloader_issues.html" class="wikiLink">Classloader issues</a></p>
<p>
#exceptionsOnNotStorable(true) will also help you to identify classes that db4o cannot persist.</p>
<p>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. </p>
<p>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: </p>
<ul>
<li>
add a zero-parameter constructor specifically for db4o; </li>
<li>derive from the class and add a zero-parameter constructor; </li>
<li>add a custom translator. </li>
</ul>
<p>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:</p>
<span name="cs_wiki_filter" csw_filters="net">
<p>.NET: </p><p><code>configuration.ObjectClass("java.net.URL").Translate(new TSerializable()); </code></p>
</span>
<p>The above code needs to be executed every time before the db4o engine is started. See also:<a href="../../object_lifecycle/object_construction.html" class="wikiLink">Constructors</a>, <a href="../../implementation_strategies/translators.html" class="wikiLink">Translators</a>.</p>
<p>Another db4o system, which can give you a valuable feedback about db4o functioning in your application is <a href="../diagnostics.html" class="wikiLink">Diagnostics</a>.</p></div>
</div>
<div id="footer">
This revision (10) was last Modified 2007-05-07T16:55:45 by Tetyana.
</div>
</body>
</html>
