You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Niels Bertram (JIRA)" <ji...@apache.org> on 2017/11/11 16:38:00 UTC

[jira] [Commented] (CXF-7289) CXF wsdl2java fails when using existing compilation expisodes of schemata

    [ https://issues.apache.org/jira/browse/CXF-7289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248587#comment-16248587 ] 

Niels Bertram commented on CXF-7289:
------------------------------------

Need to get this fixed so got off the couch and had another go.

In {{org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize}} we have a CXF parsed list of schema types available under {{this.context.get("xmlSchemaCollection")}} but we don't know what Java classes they are mapped to. The mapping of Java classes to schema types is only known by XJC as the processor of episode files and newly generated code.

The {{org.apache.cxf.tools.util.ClassCollector}} is "injected" into the XJC via the {{org.apache.cxf.tools.wsdlto.databinding.jaxb.ClassNameAllocatorImpl}} and collects the class names that are generated by XJC. This does neither collect inner classes (see comment in {{com.sun.tools.xjc.api.ClassNameAllocator}} javadocs) nor does it have any exposure to the mapped classes from prior schema episodes.

*Option 1*: Complex but reliable

Inject a "harvester" plugin into the XJC compiler to process the parsed schemata in {{Plugin#postProcessModel}} method. Here we simply iterate the schemata and element declarations. An episode referenced element declaration will carry bind info accordingly. This information can then be stored and used during the SEI generation.

The [TypeHarvesterPlugin|https://github.com/bertramn/cxf-wsdlgen-issue/blob/master/plugin/src/main/java/org/apache/cxf/tools/wsdlto/databinding/jaxb/TypeHarvesterPlugin.java] can successfully retrieve following type information from the example:

{code}
{urn:util}Fault => util.Fault
{urn:model}SomeDomainEntity => model.SomeDomainEntity
{urn:model}HomeContact => model.HomeContact
{urn:model}BusinessContact => model.BusinessContact
{urn:service}Dummy => util.Fault
{code}

*Option 2*: Simple but not exact

The other much simpler alternative is to just parse the episode files supplied to the XJC context and assume it would have used those to resolve {{namespace:Type}} types to Java names.

I'll have a look how best to incorporate the Harvester plugin into the CXF code.

> 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)