Which Framework, Tool or Plugin mandates the hardcoded 'database.xsd' filename?

Question

I inherited a CXF/Hibernate/JBoss based project that includes a filename named database.xsd. I combed the project to find out which subsystem/component in the system uses database.xsd but that yielded only one reference in a file used by the maven-war-plugin to create the WAR file (webapp-cache.xml).

To me this suggests that database.xsd is some standard filename expected by some framework or plugin. But which is it? Hibernate? CXF? Other?

Is there documentation that actually describes the role of database.xsd in the package that relies on it?

UPDATE: Temporarily removing database.xsd and trying to rebuild, resulted in numerous compilation errors that led to a principle XML2SQL.java file using a package referenced by *.hbm.xml DTO files. This tells me that the culprit is... Hibernate!

Answer 1

I would approach this the "old fashioned way", Good logging + a binary search approach.

First in a test environment:

1) Make sure your code is setup to use log4j and has the most extensive logging level on.

2) With the database.xsd removed, determine roughly the "half way point" of failure. For example, say with the system setup correctly it produces 1000 lines of logging. With database.xsd removed it fails to load and halts with just 500 lines of logging. Looking at the logging, determine what classes/methods are being called. ( Another way to work with this instead of removing the database.xsd is to introduce a copy with syntax errors to your test environment. )

3) With your study in step 2 add more logging and try/catches to capture more information. If this does not allow you to narrow down the target. Repeat, focusing on the "250 logging line" point. Continue cutting the problem space in half each time until you have found the target classes.

Many Java programs I have seen just code for the "happy path" and rely on top level exception handling to catch and log errors, but this can lead to very thick (huge number of lines) and hard to read logging entrails files.

Answer 2

It's Hibernate, because temporarily removing database.xsd and trying to rebuild, resulted in numerous compilation errors that led to a principle XML2SQL.java file using a package referenced by *.hbm.xml DTO files only. (see update above)