Elements of named complexType which are unbounded choice have incorrect classname generated which does not match complexType

This issue appears in Castor 1.0.2 as well.

I think this is a duplicate of an already existing issue, but let me first verify this.

PS It would be nice - more or less dreaming aloud .. - if anybody raising an issue in future could perform this 'duplicate investigation' before posting a query. Having said that; i think make this clear by e.g. pushing out an email .. .

I did search for an existing bug on this issue, and while I found some similar issues, I couldn't find the same problem reported by anyone.

We are trying to support one of our development teams using this newer version of Castor, so if this is in fact a known issue, please let us know the bug ID so we can track this issue as well.

PS: Thanks for the quick response!

No problem, at least an initial response should be quick, shouldn't it .. . Having said that, could you please link the other issue to this one (as e.g. related).

This issue seems to be related to:

http://jira.codehaus.org/browse/CASTOR-1146
http://jira.codehaus.org/browse/CASTOR-514

However, I think that this is a completely new problem, since this new bug does not occur in Castor 0.9.6 or 0.9.5.3 versions.

I've looked into the source code for Castor 1.0.2 and found the following possible issue:

[org/exolab/castor/builder/SourceFactory.java line 525]
When a choice with unbounded is encountered, a choiceItem class is created along with a state/ClassInfo object, which is associated with the xsType (schema type) for the choice. Before creating the class for the choice itself a new ClassInfo object is created, but the xsType is set to null instead of being associated with the same xsType as the choiceItem.

[org/exolab/castor/builder/SourceFactory.java line 647]
A ComplexType object for the choice type is bound to the ClassInfo with xsType == null.

[org/exolab/castor/builder/MemberFactory.java line 310]
An element defined with the choice type is encountered after the previous ClassInfo binding occurs and results in the xsType variable being set to null.

[org/exolab/castor/builder/MemberFactory.java line 340]
Since the xsType == null, the generator assumes that there is no type and that the definition is inline, resulting in the element name being used for the referenced class. The problem is that this class (hopefully) doesn't get generated.

I've created a possible fix for this issue: <see attached SourceFactory.java>

Possible fix for this issue. I'm not sure if this is where it needs to happen.

Simeon, thanks for your proposed fix. Would it be possible for you to create a patch against SVN ? If no, I'll try to integrate your Java source file attached above.

Werner, I'd love to help, especially if this will expediate the process.

Unfortunately I'm not sure what SVN is or your policy on patch releases. If you point me to some documentation i can do this myself.

Problem is that the file you provide has many changes to whitespace, and it's too hard for me to make out the real changes ....

I'll make an update using SVN and failing that i'll send you a diff of the file after my changes. Thanks.

If you do not have any objections against this, I'd like to take your sample schema and use it for an additional CTF test to be added to the Castor test suite. And let me know whether you need any help wrt checking out the code from SVN and/or building the patch.

Preliminary patch, basically putting the sample XML schema relative to src/bugs

Which branch should the patch be made against? trunk?

Patched against trunk. This is different from the original candidate, which compiled but failed on the unmarshal.

Thanks for the patch. I hope I will be able to review this today, but please be aware that I won't be making any substantial progress on this until the end of next week, as I will be in London for the next 6 days (provided that I will be able to actually fly to London tomorrow morning).

Much appreciated!

Do you have a release date for Castor 1.0.3? We have some applications going live the end of this month, so we are hoping to have this fix by then if possible.

No, I don't. I am away now for 7 days, and there's quite some issues that I would want to include.

In order to complete the addition of a new test to the CTF test suite (based upon your sample XML Schema), I'd need a valid XML document that I could use to unmarshall against the generated classes. Any chances of supplying me with such a sample XML document instance ?

Attached instance document corresponding to test schema.

Final patch. As I have got problems with authentication on https://svn.codehaus.org/castor, I will commit this patch later.