Is it possible to have xsd.exe add "IsNullable=false" to XmlAttributes for fields/properties that are defined in the schema as being required?
Xjc adds it to the Java annotation, but I haven't found a way to get Xsd.exe to do something similar.
I'm trying to use reflection to do a merge of our configuration files that isn't configuration file type dependent. I want to use the required attributes of an element to determine if that element exists in both files or just one.
Related
usually, JAXB is used to generate code from an xsd, which generates java classes for xsd complexType with annotations to convert it to xml and vice-versa.
I am trying to achieve something different. I want, to generate a data mapper class for each such xsd element. The mapper will map each field of the generated class with values from another datatype (say from database, or other stream)
so i need to: for every user-defined datatype in xsd, add a method in a DataMapper class map-<XSD-ComplexDataType-Class>() and generate method body.
to achieve this, i think it is not possible to generate this class in a Plugin extending com.sun.tools.internal.xjc.Plugin as in the run method, i wont be able to create a new JDefinedClass
is there any way to add a hook method before Model invokes Plugins ?
thanks,
There are a few things you can do. In my other answer I specificaly meant these:
In a plugin you can write and set your own com.sun.tools.xjc.generator.bean.field.FieldRendererFactory. Field renderers generate a FieldOutlines from CPropertyInfos. This is a step between the model and the outline. So if you want different code generated out of the model, consider implementing your own FieldRendererFactory. You can register a FieldRendererFactory via XJC plugin (see Options.setFieldRendererFactory(...)).
On the class level, you can write your own com.sun.tools.xjc.generator.bean.BeanGenerator and use it for code generation.
You can just use model and generate the code completely on your own. I do this in Jsonix when I produce JavaScript mappings for XML<->JSON.
As for your specific task, I would actually just postprocess the code model in the run method of your plugin. You have everything there - the model, the outline and also the code model (see outline.getCodeModel()). And you can definitely create your JDefinedClasses there, the code model exists already.
How to get the description field on a type populated in the generated enunciate documentation?
We are generating classes from jaxb using jaxb2-maven-plugin. No matter how I document a element either using the <xsd:documentation></xsd:documentation> or the
<xsd:appinfo>
<jaxb:class>
<jaxb:javadoc>
</jaxb:javadoc>
</jaxb:class>
</xsd:appinfo>
it is overwritten in the generated classes. Can I somehow disable the this auto-generated javadoc from this plugin? Or what does enunciate really expect me to do let me document on a field level?
Note that the comment I write on class-level/type does show up in the generated class and in the enunciated generated documentation.
We are using enunciate (v.1.26.2) and jaxb2-maven-plugin (v. 1.5)
So you're wondering how to get Enunciate to not use the Javadocs on the class?
One way might be to compile the JAXB-generated classes and run Enunciate against the compiled classes instead of the source code.
My XML files have restrictions on the child elements, but it really doesn't matter what the name of the root element is. How can I incorporate this into my XSD? I've tried using <xs:any> but I get:
"S4s-elt-invalid-content.1: The Content Of 'schema' Is Invalid. Element 'any' Is Invalid, Misplaced, Or Occurs Too Often."
So I tried missing the name off the element tag like this: <xs:element> but then I get:
"S4s-att-must-appear: Attribute 'name' Must Appear In Element 'element'."
Use a named type, and tell your validator to start validation at the root element using that type.
(There is one possible hitch with this: XSD 1.0 suggests that as one possible invocation option, but does not require validators to provide it, so there's no guarantee the validator interface you use will support it. Depends on your validator. Worth trying, at least.)
Another way to put this: you already have what you are asking for, because your XSD schema never cares what the root element of your document instance is called. An XSD schema provides a set of element and type declarations (among other things). A validator can be requested to start the validation at any point in the document, not just the root, and with either an element declaration or a type declaration, or in 'lax wildcard mode' (the most common default). If your validator doesn't offer the invocation options you want, it's a flaw in your choice of validator, not a gap in XSD.
I think I might just make the requirement stricter and insist on using a particular tag as the root element. The fact that the application doesn't care is not really a problem.
It seems (to me) strange that this limitation exists, but I am new to XSDs.
I have a Core Data model with a single transformable attribute. I also have this attribute use a custom NSValueTransformer, setup in the model properly.
When I use mogenerator to generate/update my machine and human files, the machine files for the entity containing this attribute always type the attribute to NSObject. In order for Core Data to use my custom value transformer, this type needs to be the type the transformer understands. Right now, I manually do this in the human file by redefining the property with the proper type. This does the job and gets the transformer working. However, I end up with several compile warnings regarding redefinition of the attribute.
One of the more recent releases of mogenerator specified in the release notes that transformable attributes are now supported. However, I haven't found any example syntax to enable this feature.
This should be better documented.
To set your generated attributes's type, select your desired attribute in the modeler and switch to the User Info tab. Then create a new element with a key of attributeValueClassName and a value of whatever you'd like.
Here's a screenshot:
Using JAXB I can create an XSD using code like:
JAXBContext ctx = JAXBContext.newInstance(classes);
ctx.generateSchema(new MySchemaOutputResolver());
That makes a goods XSD describing the structure of all the JAXB objects in the list of classes I pass in, however, I can't figure out how to add other types of XSD restrictions like minOccurs, maxOccurs, pattern, etc.
Is it possible to add annotations which indicate that additional information so that the XSD will include it?
You can use the #XmlElement(required = true) annotation to make an item required. Similar annotations exist for repetition, etc.
See here for annotation classes, the Javadoc has details.