Throwing Exception while transforming XML to Java

Updated patch, incl. a small patch to UnmarshallHandler amongst other things (that fixes a small problem related to (default) naming conventions when in introspection mode).

Sumit, please have a close look at the file attached. Apart from the patch, it contains several files in a directory xml.c1420, incl. a JUnit test case and three XML files. Basically, it looks like you have not been really familiar with the naming convention Castor by default applies when no mapping file is used (introspection mode).

I added a new XML file (for unmarshalling, used by one of the three test*() methods in the JUnit test case), to show you how the XML is meant to look like for introspection to work successfully. I have added two other XML files taht demonstrate that

a) the sequence of the XML elements within the INT_employee element is irrelevant, as long as the names of the XML elements matches Castor's expectations
b) that if you get an XML element name wrong (e.g. Department_id instead of the expected department_id), Castor will simply not be able to unmarshall this properties' state.

Let me know whether you have any further questions ....

I cannot seem to get these tests running at all using the following command:

$ ./bin/CTFRun.sh src/bugs/xml/c1420/

It's either way too late or I'm missing something because the following tests run just fine:

$ ./bin/CTFRun.sh src/tests/xml/MasterTestSuite/sourcegenerator/

Bruce, and bug report/test living in src/bugs is a plain (vanilla) JUnit test. In other words, these JUnit tests are not integrated with the CTF test suite. Simply use the JUnit facilities of any IDE, or add a main method to the test case itself calling a TestRunner with the test instance as an argument.

Can we run these tests from within the Ant build descriptor? This is a bare minimum requirement.

Bruce, of course you can, but that's not the original intention. We added src/bugs solely for communication between users (who file a bug) and us, and we have decided to use simply JUnit tests for this, as it is a hassle to ask users to have this integrated with our CTF just for us reviewing what they have.

In otehr words, if you want to execute the test case attached above, simply add a main() method and call this main method from within a <java> task from Ant. And don't forget to execute the included DDL script if it happens to be a JDO specific test.

I hacked up a quick target to execute this JUnit test, but it will not currently execute the rest of the CTF XML tests. I'll wait to commit this until this patch is committed.

As you might have noticed yourself, due to the 'absence' of beaver.codehaus.org (the machine at Codehaus hosting the the SVN repo) we (the committers) cannot access the SVN repo at the moment. As such, I am not capable of committing above patch at the moment.

Werner Hi

Could you tell me How to download the fix made for this issue?

Thanks
Devashish

Not sure what you actually mean. Above (in the attachment section), there's the original patch file I applied against trunk to fix this problem. If you are referring to binaries that incl. this particular fix (and others), you'll have to wait until tonight (as that's when I'll be realeasing 1.0.1). If you are to impatient to wait, but still need binaries that include this fix, you'll have to download the latest sources from the SVN repository and build the sources yourself.

Given that you are not really familiar with SVN et alias, why not wait for the 1.0.1 release which I will be maling available tonight ?

With regards to building sources yourself, have a look at http://castor.codehaus.org/scm.html for instructions upon how to connect to our SVN repository. From then on, it's simply a matter of using any IDE (like Eclipse), use its 'patch apply' feature ... et voila.