Hey Daniel,
Thanks for your interesting reply.
Thus, to get it working for CXF, you would need to modify the schema
to
put the proper <s:import> in place to import the schema schema, then
include the binding file to deal with the duplicate classes.
Alternatively, use the workround on that blog with wsgen to
generated the
code, then use CXF at runtime. It's just straight JAX-WS code so it
should work.
Ideally im looking for a solution that lets me generate the classes
without needing to modify the WSDL, as that syntax is used through a
whole bunch of services that I need to consume so im reluctant to
monkey patch the service.
Is it not possible to include the binding files (as shown on the blog)
directly with cxf's wsdl2java tool? I gave it a whirl but with no
luck. Is there a solution similar to that we can fashion? Otherwise,
when I generate using wsimport, I get the following warnings:
[WARNING] src-resolve.4.2: Error resolving component 's:schema'. It
was detected that 's:schema' is in namespace 'http://www.w3.org/2001/XMLSchema'
, but components from this namespace are not referenceable from schema
document 'icp.wsdl#types?schema1'. If this is the incorrect namespace,
perhaps the prefix of 's:schema' needs to be changed. If this is the
correct namespace, then an appropriate 'import' tag should be added to
'icp.wsdl#types?schema1'.
line 113 of icp.wsdl#types?schema1
[WARNING] Ignoring SOAP port "InteractiveCampaign_SSPSoap12": it uses
non-standard SOAP 1.2 binding.
You must specify the "-extension" option to use this binding.
I appreciate these are not CXF error directly, but how can I work
around this with wsdl2java? If thats even at all possible?
Many thanks for any advice you guys can give
Cheers
Tim