[
https://issues.apache.org/jira/browse/CXF-7289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248811#comment-16248811
]
Niels Bertram commented on CXF-7289:
------------------------------------
@[~dkulp], I propose the following fix using Option 1 from above. If anyone
could tell me if there are impacts outside of what I can ascertain from reading
the code, that would be fantastic.
I coded a simple XJC module and add the known episode references during the XJC
binding generation processing into the injected cxf ClassCollector
[here|https://github.com/bertramn/cxf-wsdlgen-issue/blob/56ab4f05f8b76d80b979ec51647ab8bd366cc732/plugin/src/main/java/org/apache/cxf/tools/wsdlto/databinding/jaxb/TypeHarvesterPlugin.java#L67].
To tie this together with the CXF binding module following needs to happen. The
method {{JAXBDataBinding.getType()}} is consulted by
{{ProcessorUtil.getFullClzName()}} to produce a fully qualified classname when
constructing the message parts. This method only looks at the raw class model
generated by the XJC compiler which is not including the episode classes. At
this point we could also inspect the content of the {{ClassCollector}}. If the
{{JAXBDataBinding.getType()}} method returns null (QName unknown) the
{{ProcessorUtil.resolvePartType()}} method is called. This method is only
having a wild guess about the full classname anyhow (this logic should be
removed/moved to the getType function - utils are code smell anyways). Also to
note, this util function looks a bit like a previous attempt to prevent a NPE
when the referenced body element/type in the WSDL is unknown by the XJC
generated model (caused by this issue we are trying to fix here).
Thoughts:
{{JAXBDataBinding.getType()}} should never return null because if the class is
unknown from either generated XJC code model or prior episode file(s), the WSDL
is invalid.
Enhancing {{JAXBDataBinding.getType()}} to also return a class name for any
types known from a prior compilation episode will be sufficient to fix this
issue reliably. The fix would be local to the JAXB binding context.
Given the solution is quite complex resorting to a XJC plugin, we should submit
a patch to JAXB project to implement an XJC interface to also extract a list of
prior known model types from compilation episodes.
> CXF wsdl2java fails when using existing compilation expisodes of schemata
> -------------------------------------------------------------------------
>
> Key: CXF-7289
> URL: https://issues.apache.org/jira/browse/CXF-7289
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
> Affects Versions: 3.1.10
> Reporter: Niels Bertram
>
> Including a schema from an earlier compilation episode in a wsdl schema with
> the same namespace will cause to CXF fail when resolving the Java type when
> constructing the wsdl operation parameter.
> the issue is rather complex to demonstrate so I created a fully functioning
> compilation project at https://github.com/bertramn/cxf-wsdlgen-issue
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
