I've added a couple of hooks to give some access to the data structures generated by JiBX from schema. In order to make this work correctly with both full and modular code generation I've designed it to use the binding definitions.
After you've run the CodeGen.generate() method to actually generate a data model and bindings, you can call the getRootBinding() method to retrieve the generated root binding definition. This binding definition should include, directly or indirectly, all the other binding definitions either supplied as input or generated. You can then call the new org.jibx.binding.model.BindingUtils.getDefinitions() method, which will populate the passed-in maps with pairs consisting of org.jibx.runtime.QName keys and org.jibx.binding.model.MappingElement values. The MappingElement getClassName() method will then return the fully-qualified class name of the class corresponding to the type or element. Getting at the internal structure of the type or element definition is also possible, but takes a little more work. You need to walk through the child elements of the MappingElement, looking for either StructureElement, CollectionElement, or ValueElement children. Each of these may define a child element (or, in the case of ValueElement, potentially an attribute) name within the definition. If the child element corresponds to a property of the mapped class, you can also get the field name or get/set methods used to access this property. However, the code generation performs only a partial validation of the bindings, and because of this some information will be missing from the child elements - in particular, neither their namespace nor their type information will be set, unless specified in the binding definition. The primary motivation for providing this information is for adding JiBX support to CXF code generation. CXF needs to know the type information for the child elements within a wrapped-style message element. For this case, the lack of namespace information on the child elements should not be a problem, since AFAIK wrapped conventions always use the same namespace for the child elements as for the message element. The lack of type information *would* be a problem, though. To get around this issue, I've added a new schema customization for CodeGen. This customization is the 'force-types' attribute, which tells CodeGen to always include explicit type information (rather than using types implied by the field or get/set method definitions) in the binding generated for that schema. To make use of this customization in code generation, you'll need to create the customization as usual (either reading in a customization file supplied by the user, or generating a default customization) and then find or add a customization for the schema defining the WSDL messages and call setForceTypes(Boolean.TRUE) on that SchemaCustom before executing the code generation. - Dennis ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ jibx-devs mailing list jibx-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jibx-devs
