Also, I would appreciate if anyone knows any work-arounds that don't involve modification of the schema.

Thanks!

Thank you for the prompt responses.

This first INCOMPLETE patch generates a constructor like this (if we have an element that contains a complexType with a simpleContent):

public X(final java.lang.String defaultValue) {
this._content = defaultValue;
}

This patch is still incomplete because of the lack of type conversion inside the contructor. We need to cast from String to BigDecimal in your case.

I looked at the create(From/To)JavaObjectCode methods of XsType, but they don't do what we want here. I'm currently searching the sources to find some reusable piece of code that does the classcasting for us.

Please stand by, I will comment about my results soon.

The most fitting method for this wolud be imho XSType.createToJavaObjectCode(). This method is overridden by the sibclasses like XSInteger to produce this code. I thought I found the solution fpr our problem here, but having a closer look into all implementations of XSType, I discovered some inconsistency. There are several XSTypes that produce only

BigDecimal value = stringValue.

this is not a valid cast. Classes I found are XSDate, XSDatetime, XSG*, XSTime, XSDecimal, XSUnsignedLong.
In fact, all these classes are using either a castor specific Date wrapper class or java.math.BigDecimal. every other numeric type (eg. XSInteger) works ok.

So my question is: Is the createToJavaObjectCode in XSDecimal and XSUnsignedLong buggy or am I missing some point?

• adds the default value constructor (in SourceFactory)
• adds a createDefaultValueWithString to XSType
• per default, this method returns new " + getJType() + "(" + variableName + ")
• all subclasses that need special treatment (because no String constructor is avlailable, eg. primitive numeric types and boolean) override this method. see XSBoolean or XSInteger as example

The new patch fixes this as well as adds a new test to the xmlctf.