Hi,

I am a newbie, and have scanned the subjects of all the posts to the tools forum, but admit to not reading all the the threads yet.

I have an architectural question concerning configuration. I am using XDoclet to specify my hibernate mapping, and use SchemaExport to
generate the DDL for the resulting schema.

I am building an application that needs to be database agnostic. I have
an ant task that iterates through all of the dialects and emits the DDL for each dialect in turn.

My issue is that in order to do this, I need to have a separate properties file for each dialect. This is intractable because all of the other properties specified in the configuration file are common across all of the dialects. In particular, the rest of the properties specify the persistent classes.

Ideally, I would like the properties file contain ONLY the set of persistent classes and put this file under source control. In this way, I specify the set
of persistent classes only once, and all tools and deployments use this as the basis for configuring hibernate. I would layer any deployment specific configuration properties on top of this common properties file. The mechanism for managing this deployment specific properties would be built by hand.

The tools as far as I can tell do not allow layering of configuration properties from multiple sources or files. I have considered modifying the SchemaExportTask class to specify task arguments for dialect and perhaps other configuratoin parameters that are target specific. I don't want the maintenance headache of maintaining my own set of tools, however.

I am currently considering an approach that generates a property file for each dialect from the common property file for use solely for the SchemaExport task. While this approach is entirely doable, I cringe at having to build tools that 'flatten' a set of configuration parameters with different lifetimes.

How do others manage muiltiple deployment environments? Is there a standard or recommended methodology?

Thanks in advance
leckband

You can easily work around this I'd say by using something like xml entity imports in combination with an ant filtertask.

First off, many thanks Michael for your reply. I have used XML for a variety of purposes in the last couple of years, but clearly I am not an expert. For those who may follow, what Michael was recommending was to augment the DOCTYPE of the configuration xml file to add an external entity declaration in addition to the reference to the standard DTD. The entity declaration would be something like <!ENTITY mapping SYSTEM "mappings.cfg.xml">. Then in the xml body the contents of mapping.cfg.xml would be the replacement text of a reference to this entity (&mapping;).

This is a clever way to manage configuration parameters specified at different times and places.

However, I am stuck once again. The issue seems to turn on how relative URIs are resolved, at least in the context of Java's XML parsing library.

There is a strong desire to rely on relative URIs both in development environments as well as for deployment. Absolute URIs are not portable, so we work hard making software packages self contained within some definable domain. In practice in the java world, it is usually some variant of relative to some jar file, war, ear, or whatever.

Consider an ant target that invokes hibernate's SchemaExportTask. This target passes a config parameter to the task that is a relative URI. It was a painful multiday lesson to learn that the config parameter was a URI, and not a filespec. It was an even harder lesson to realize that the leading / in the URI was absolutely CRITICAL to having the tool find the config file.

<taskdef name="schema.export"
classpathref="compile.class.path"
classname="net.sf.hibernate.tool.hbm2ddl.SchemaExportTask"/>

<schema.export
config="/hibernate.cfg.xml"
quiet="yes"
delimiter=";"
text="yes"
drop="no"
output="${distdir}/PGSchema.sql"/>

Now, as I mentioned previously, the hibernate.cfg.xml file looks like this:
<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE hibernate-configuration
PUBLIC "-//Hibernate/Hibernate Configuration DTD//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-2.0.dtd"
[<!ENTITY mapping SYSTEM "mapping.cfg.xml">
]>

<hibernate-configuration>

<session-factory>

<!-- Define the 'default' db dialect, can be overridden -->
<property name="dialect">net.sf.hibernate.dialect.PostgreSQLDialect</property>
&mapping;

</session-factory>

</hibernate-configuration>

and finally, my mapping.cfg.xml file looks like this, not that it matters, as nothing I do seems to let the parser find this file.

<?xml version='1.0' encoding='utf-8'?>
<!-- Mapping files -->
<mapping resource="com/myCompany/obj1.hbm.xml"/>
<mapping resource="com/myCompany/obj2.hbm.xml"/>
<mapping resource="com/myCompany/obj3.hbm.xml"/>
<mapping resource="com/myCompany/obj4.hbm.xml"/>

mapping.cfg.xml is in the same directory as hibernate.cfg.xml was found, but nothing I do seems to change the outcome. For completeness, the both of the cfg.xml files are placed in a top level directory of a classpath element, in this case a classes directory.

As I have alluded above, I get variations on the theme of the following error:
[schema.export] SEVERE: problem parsing configuration/hibernate.cfg.xml
[schema.export] org.dom4j.DocumentException: C:\cygwin\home\leckband\tnt\mapping.cfg.xml (The system cannot find the file specified) Nested exception: C:\cygwin\home\leckband\tnt\mapping.cfg.xml (The system cannot find the file specified)

The way I read the URI spec (RFC 2396) is that given a relative URI, it looks for a suitable base URI specified in the document where the relative URI reference is made (in this case, the body of the hibernate.cfg.xml file)
failing that, it tries to use the base URI of the enclosing document. We know that the hibernate.cfg.xml file got found, but it was referred to with a relative URI.

Finally, if all else fails, there is an application specific default that gets used to try to resolve the mapping.cfg.xml URI. This is almost always the wrong thing if it hasn't gotten a legitimate base URI by this time. This is the case in my situation as well. The default ends up being the 'current working directory' when the ant task is invoked.

Was it wrong of me to think that if hibernate.cfg.xml could be resolved to a file, that if mapping.cfg.xml were in that same directory that it should be found as well?

For what it is worth, I am using hibernate 2.1 and jdk1.4.1 and ant 1.6.0, and the hibernate extensions 2.0.2.

Thanks in advance.
Craig

Probably this thread http://forum.hibernate.org/viewtopic.php?t=927396&highlight=entityresolver and this JIRA entry http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-677 help you out.

ya' problem is best solved by using ant filtering which is done on <copy> task - it is VERY easy and lightweight!

Go look in the ant docs for it ;)

Thx to both Michael and Max for their responses. I have struggled for several days trying to apply patches referenced by Michael to hibernate to fix relative URI resolution in the EntityResolver.

However, I find that I must abandon this effort. The more I have read from the forums about the apparent fragility of using the right XML parser, patching hibernate is just too much on the lunatic fringe for me. I have no choice but to conclude that this is not viable right now.

The final straw for me was that even after I upgraded my xerces and patched my hibernate, it still meant that SchemaExport wouldn't correctly resolve the relative URI because a custom EntityResolver needed to be written in order to intercept the URI and force it to look for the file relative to the classpath. I do not want to maintain hibernate or its tools.

Thanks again for your help.

Craig

Note that the custom EntityResolver patch is now in CVS v22branch, so you don't have to maintain it yourself.