Generated classes are not compileable for simpleTypes with list-elements

I tested it again with the 'old' castor version 0.9.5.2. ... the class "MyType.java" was generated.

I think that this problem should be fixed.

Hi all,
i found out hte 'possible' source of the problem.....
in SourceFactory.processAttributes code is as follows

private void processAttributes(ComplexType complexType, FactoryState state) {

if (complexType == null)
return;

Enumeration enumeration = complexType.getAttributeDecls ();
XMLBindingComponent component = new XMLBindingComponent(_config);
if (_binding != null) component.setBinding(_binding);
while (enumeration.hasMoreElements()) {
AttributeDecl attr = (AttributeDecl)enumeration.nextElement();

component.setView(attr);

//-- if we have a new SimpleType...generate ClassInfo
SimpleType sType = attr.getSimpleType();
if (sType != null) {
if ( ! (SimpleTypesFactory.isBuiltInType(sType.getTypeCode())) )

if (sType.getSchema() == component.getSchema())
{ System.err.println("...Fine. it is in same schema...");
if (state.resolve(sType) == null) {
if (sType.hasFacet(Facet.ENUMERATION))

}
}
}
FieldInfo fieldInfo = memberFactory.createFieldInfo(component, state);
handleField(fieldInfo, state);
}
return;
}

so if an attribute of a SimpleType does not have 'hasFacet(Facet.ENUMERATION)' no class will be generated for the attribute..
any particular reason for that?

regards
marco

Marco, it looks like support for <xs:list> has not been implemented yet. The attached patch (tries to) add(s) the relevant changes to the source code base. I'd like to see a XML document which could be used to unmarshal against the generated sources.

Improved patch, with some cleanup performed in sub-classes of XSList.

Andreas, I know it's been a long time since you created this issue .. ;-(, but what's the chances of attaching a sample XML document as asked above ?

Anybody willing to spend just a little time to make our life easier ?

Patch holding a JUnit test case for this scenario (relative to src/bugs).

New patch, incl. generated classes.

After figuring out that there's a lot of work to do to get support for <xs:list> implemented, I'd rather ask some questions before going about this.

a) Does everybody agree that the type of the attribute for the schema given above should be of 'MyType'.
b) Does everybody agree that 'MyType' should hold a member which happens to be a collection with a component type 'BaseType'.
c) Does everybody agree that classes should be generated for 'MyType' and 'BaseType' ?

Now, if we agree on that, that's the easy part. Let's have a look at the field handler for the attribute (of type 'MyType') within TestType. Here's some questions:

a) What should the setValue(Object) implementation look like. Does it do any type conversion ?
b) What's the real type of the input parameter for the setValue() method in this case ?
c) What method should be called on the actual MyType instance ?

Any input appreciated ...

On the first a, b, c, I agree on all three points.

On the second three, I think it should be setValue(String) with no type conversion. Maybe as a future enhancement we can add code to detect simpletypes based on restriction string that have a pattern containing entirely digits, and add type conversion code to convert byte/short/int/long/LongDecimal/whatever. But that seems to be an enhancement, not a requirement. Is that the kind of type conversion you were asking about?

On the 2nd c), I'm not sure exactly what you're asking.

Edward, I was just wondering aloud what object instance will/should be passed into the setValue() method of the FieldHandler for lists ?

I can imagine that we'd accept an array of Strings or a Collection of Strings.

Somehow I am about to change my mind. Somehow I think (start thinking) that no MyType class should be generated at all (as normally Castor does not create classes for simple types. If that's the case, what should be generated instead. In my view, whatever the list's item type is; in this case, something derived from the type definition for BaseType. I know that something is not really precise in this context, but I am actually thinking about how Castor normally resolves simply type definitions in the context of restrictions, by e.g. deriving the member's type from the (most) base type, and adding all restrictions to the validator code to make sure that all facets are met.

In my view, a similar approach could (and should) be implemented, giving the parameter of the addMyAttr() method a type of 'java.lang.String', as that's what 'BaseType' is derived from.

Comments appreciated.

Completely revised patch, highlighting the new approach towards building this. Please use the test case included in one of the previous patches to have a look at the sources generated. The CTF seems to have five problems - all of them in the same area.

hello, seems like i faced this issue today at work.
this is my schema file:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://myapp/commons2_bbp"
xmlns="http://myapp/commons2_bbp">
<xs:simpleType name="TIPO_CAUSALE">
<xs:restriction base="xs:string">
<xs:pattern value="*|[A-Za-z0-9][A-Za-z0-9][A-Za-z0-9]"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>

this schema is imported in another big schema, and i use a lot of times the type "TIPO_CAUSALE"
i told the sourceGenerator to put the .java files in \src\commons2 while other files (from the big schema) are in \src\project
i saw no classes are created in \src\commons2,
also i noticed the getters/setters in the class that has an element whose type is "TIPO_CAUSALE"
are like:
public Object getTIPO_CAUSALE() and public void setTIPO_CAUSALE(Object input).

they dont have TIPO_CAUSALE type...

why castor dont create a class TIPO_CAUSALE ?

Francesco, can you attach two schemas that I can use to replay your problem. Please try to attach XML schemas that are minimal but still showcase the issue at hand (to ease our work). And please don't forget to add information that shows how you are calling the source generator (of which Castor version).

using castor 1.1.2.1

as u can see in the DataOrdine.java:

private java.lang.String _causale;
private types.TIPO_MACCHINA _macchina;

for my previous test i uses a old castor that didnt put String and used Object for _causale
this is ok.

but the question is still up:
why castor didnt generate TIPO_CAUSALE.java in \src\types and its descriptor in \src\types\descriptors ?

Thanks, but your patch does not show how you are calling the source generator. And are you using custom builder properties ? If so, can you please attach as well ?