Hi, I see that CodeGen.generate() method is no longer a static member. Is this intentional ?
Thanks, Nilupa On Sat, Aug 7, 2010 at 9:14 AM, Dennis Sosnoski <d...@sosnoski.com> wrote: > 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 > -- Nilupa Bandara
------------------------------------------------------------------------------ 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
