When I try to generate the classes, the source generator simply hangs.

Added failling test case

1. Cmd line options
   org.exolab.castor.builder.SourceGenerator -i dist/ml-pb-1-0.xsd -dest builtCode -binding-file properties/binding.xml

#Bind file
<binding xmlns="http://www.castor.org/SourceGenerator/Binding"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.castor.org/SourceGenerator/Binding"
defaultBinding="type">

<namingXML>
<complexTypeName>
<suffix>Type</suffix>
</complexTypeName>
<elementName>
<suffix>Element</suffix>
</elementName>
<modelGroupName>
<suffix>Model</suffix>
</modelGroupName>
</namingXML>
</binding>

--CASTERBUILDER.PROPERTIES

1. This property specifies whether the sources generated
2. should comply with java 1.4 or 5.0; defaults to 1.4
   org.exolab.castor.builder.javaVersion=1.4

1. Java class mapping of <xsd:element>'s and <xsd:complexType>'s
   #
   org.exolab.castor.builder.javaclassmapping=type

1. Set to true if you want to generate the equals method
2. for each generated class.
3. false by default
   org.exolab.castor.builder.equalsmethod=false

1. XML namespace mapping to Java packages
   #
   org.exolab.castor.builder.nspackages=http://www.fpml.org/2005/FpML-4-2=fpml
   org.exolab.castor.builder.nspackages=http://www.w3.org/2000/09/xmldsig#=xmlsig
   org.exolab.castor.builder.nspackages=http://www.ml.com/FpML/2006/ML-1-0=com.ml.trade

1. Set to true if you want to use Object Wrappers instead
2. of primitives (e.g Float instead of float).
3. false by default.
   org.exolab.castor.builder.primitivetowrapper=false

I try to build the classes from ml-pb-1-0.xsd. This file includes ml-shared-1-0.xsd and imports fpml-main-4-2.xsd. When I attempt to build, I get the following output:
Warning: Do not forget to generate source code for the following imported schema: file:///C:/trade/castor-1.0.3/castor-1.0.3/dist/fpml-main-4-2.xsd

And then the application SourceGenerater hangs...

I can successfully use SourceGenerator to build classes for ml-shared-1-0.xsd and fpml-main-4-2.xsd.

Any idea what could be wrong? I know that if I comment out the
<xsd:complexType name="PBTrade">
node from ml-pb-1-0.xsd then everything works fine.

PLEASE HELP.

As a quick work-around, what happens if you set setGenerateImportedSchemas(boolesan) to 'true' when invoking code generation on ml-pb-1-0.xsd ?

I'm running this at the cmd line. Is there a cmd line option for this?

-generateImportedSchemas true should do the trick. I'll update the documentation as well ....

Same problem.... It just hangs forever.

Here is the stdout.
– Imported XML Schemas will be processed automatically.

builtCode\SettlementRateSourceType.java already exists. overwrite(y|n|a|?)a

Warning: The facet 'pattern' is not currently supported for XSTime.

builtCode\com\ml\trade\StrategyType.java already exists. overwrite(y|n|a|?)a

Is there any more information I can provide to help address this issue?

I'l be having a closer look then ..

When changing the namespace mapping in the castorbuilder.properties to

org.exolab.castor.builder.nspackages=\
http://www.fpml.org/2005/FpML-4-2=fpml,\
http://www.w3.org/2000/09/xmldsig#=xmlsig,\
http://www.ml.com/FpML/2006/ML-1-0=com.ml.trade

things work out of the box. In other words, the code generator finishes within a few seconds, and the generated classes seem to compile just fine.

Actually, there's a few compilation problems, but some of these issues are known and dealt with as part of existing issues.

At least a partial overlap, as the generated classes carry incorrect (un)marshal methods.

Just looking at the classes generated in more detail:

a) Incorrect unmarshal() methods are being generated (CASTOR-1566).
b) Some assignments to _choiceValue membrs are (still) wrong, despite a recent patch.
c) Some new issues that right now do not make sense.

Actually, the problem with the incorrect assignments to choice values will be resolved through CASTOR-1335.

Any comments appreciated .. ;.-), especially after CASTOR-1566 has been committed.

Well, let's see what we get now that CASTOR-1335 has been committed as well ...

Just re-generated the classes from the XML schemas given, and there's about 34 compiler errors left. I just had a brief look at them, and it looks like the majority (if not all of them) are a result of incorrent instantiation of Java classes generated from abstract complex type definitions. I will create a separate sub-task for this ...

Complete (standardized) test case relative to src/bugs.

Werner, Thanks for your assistance.
Using the newest codebase, will the code generator produce a set of classes that compile?

Just closed CASTOR-1600 as 'Fixed', leaving one issue to deal with. I have opened a thread on the dev mailing list, so let's wait for some input.

Btw, this brings the number of compilation errors down to 17, all in one file only.

Reading the complete issue again, it just beates me as to why the code generator hangs (ad infinitum) when the namespace mapping is not compete .. .

The infinite loop is the following while loop in SourceFactory in the method:

private void createUnmarshalMethods(final JClass parent, final SGStateInfo sgState) {

JClass returnType = parent;
while (returnType.getSuperClassQualifiedName() != null) {
String superClassName = returnType.getSuperClassQualifiedName();
JClass superClass = sgState.getSourceCode(superClassName);

if (superClass == null)

if ((superClass == null) && (superClassName.indexOf('.') < 0)) {
String pkgName = returnType.getPackageName();
if ((pkgName != null) && (pkgName.length() > 0))

}

if (superClass == null)

returnType = superClass;
}

Attaching a patch that exposes the problem. There's an infinite loop, as shown in my comment above. The hack in the patch short circuits the infinite loop, which involves some classes that have themselves as their superclass and other classes that have themselves as their super-superclass. The hack also allows generation of the class Math. This hack allows class generation to complete (I don't know if it is accurate or not) but on the compliation step I get a lot of cyclic inheritence and complaints about "private not allowed here" before I get an out of memory error.

I don't understand this code well enough to understand how to fix this problem, but hopefully this helps you solve it!

Thanks, Edward. It's actually quite odd that I don't get the loop anymore after fixing the namespace to package mapping. As a aworkaround this should be sufficient, but I agree that we should look at this loop more carefully.

Attaching a minimal schema that produces this problem.. Reproducing this problem (the infinite loop) requires two instaces of the same element (in two different complex types) where the name and type are the same except for case. I imagine that the fpml schema as the same sort of tihng where an element becomes its own grandparent. The schema attached shows where an element becomes its own parent.

I don't know how to prevent the cyclic inheritence loops that are causing the problem, but here is a patch that catches the inheritence loops and prevents them from causing an infinite loop.

This doesn't fix the root problem, which is why it's called "partial-patch"

As I have just committed a patch fixing the issue with incorrent member naming for element references that point to global element defs in 'type' mode (CASTOR-1645), I will be closing this as resolved. Edward, can I please ask you to move the 'looping business' to a new issue and assign it to 1.0.5, pretty please ?