On 08/19/2010 12:52 AM, Nilupa Bandara wrote: > > > > > - The implementation of getWrapperType() method in > JiBXToolingDataBinding > > class looks at the only one (ValueElement) of child elements of > > BindingElement which contains binding/type information of > generated > > classes. It can certainly be improved to observe other child > elements > > namely StuctElement and CollectionElement when required (see > [2]). I am > > looking for some schema/wsdl artifacts which will help me on > that and it > > would be great if anyone can point me to such. > > Well, if you want some very complex things, you could use the > type test wsdl > in testutils: > > testutils/target/generated/src/main/resources/wsdl/type_test/type_test_doclit_soap.wsdl > > That's probably way overkill though. > > > > It seems that there are some problems with schema compilation when the > root schema in the WSDL contains several schema imports. When I ran > the jibx schema compiler command line feeding the same schema > (attached) , it gives the same error[1]. I will ask about this issue > in jibx-dev list and see whether they suggest any solution. >
I'll take a look at this problem, Nilupa. Can you create a JiBX Jira with attachments to make it easy for me to replicate? That aside, I think you've been focused on code generation at the time the CXF tool is being run. We're also going to need to also work with pre-existing JiBX bindings, which is why I set up the JiBX methods you're using to work both ways. So you'll need to have an option to get one or more pre-existing JiBX binding definitions as input, and be able to pass those in to the JiBX code generation so it knows what it's starting from. I gather you've also been focused mainly on wrapped style WSDLs. This is certainly a major use case, but a lot of organizations are also using plain doc/lit where the message elements have complex XML structure. The OTA schemas used by the JiBX/OTA subproject (http://jibx.sourceforge.net/jibxota/index.html) are a good example of this. The subproject includes Ant scripts to first use CodeGen to generate code and JiBX bindings from the schemas (either as a single lump build, or with modular builds where classes corresponding to the various groups of schemas are separately bound and bundled into separate jars). Once you've build the data model, you can then generate a WSDL from a code-first sample, and finally deploy that as a web service using either Axis2 or JiBX/WS. I'd love to include a CXF deployment example with this. So in this case, you'd need to take a supplied WSDL (which was generated, though there's no reason you'd need to care about that) and corresponding binding definitions, and just link the message elements referenced by the WSDL to the corresponding classes. Should be pretty easy, but it represents a different path through your code. - Dennis
