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!

Jinny

Looks like a tough cookie because grepping Google doesn't yield anything relevant: "database.xsd" site:grepcode.com. Are you sure this is a hard-coded value? – Impenetrable

Could you please post the maven part the referencing this file and this file's location within your project as well? – Hufford

@Hufford If I had a reference to this file anywhere in my project (including pom.xml), I wouldn't be asking this question. :) I grep-ed the entire project directory structure (recursively!) for the string database.xsd -- to no avail. This is why it is such a mystery to me. Is it truly hardcoded in one of the frameworks I am using? Is it up to the project's author and an implied .xsd extension is appended somewhere? I don't know. +1 for chiming in. – Jinny

Answer 1

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)

Jinny

Answer 2

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.

Tarragona

+1 for providing the idea to (temporarily) remove database.xsd and see what happens... Well, the project wouldn't build successfully so log4j logging isn't relevant. Instead, the build shows numerous COMPILATION ERRORS in which a certain table's package does not exist (too application-specific to go into detail here). Only 3 Java files produce this either "package does not exist" or "cannot find symbol" error. Due to the CXF/Spring way of wiring XML to POJOs, it is still very difficult for me to tell which framework causes this. Additional ideas? – Jinny

I would go ahead and let it build successfully, then run it in a test environment with "bad syntax" in the xsd file. The errors you get should let you narrow it down a bit more. – Tarragona