CXF
  1. CXF
  2. CXF-2712

wsdl2java + jaxb episodes fails to generate service artifacts

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2.6
    • Fix Version/s: None
    • Component/s: Tooling
    • Labels:
      None
    • CXF Fields:
      Blocked on External

      Description

      When generating jaxb bindings with episodes for all schemas included/imported for a "wsdl" the "wsdl2java" fails when it tries to resolve the message parts on the wsdl to create the service artifacts.

        Activity

        Hide
        Marcel Casado added a comment -

        Created a helloworld with jaxb episodes and cxf-codegen-plugin. If episodes are used with <xjcarg>-b,$

        {basedir}

        /src/main/resources/episodes/helloworld.episode</xjcarg> then the codegen crashes. If episodes are not used the codegen succesfully finishes.

        Show
        Marcel Casado added a comment - Created a helloworld with jaxb episodes and cxf-codegen-plugin. If episodes are used with <xjcarg>-b,$ {basedir} /src/main/resources/episodes/helloworld.episode</xjcarg> then the codegen crashes. If episodes are not used the codegen succesfully finishes.
        Hide
        Daniel Kulp added a comment -

        OK. I can now see what is going on. It's technically a "bug" (or missing API) in JAXB. See:

        https://jaxb.dev.java.net/issues/show_bug.cgi?id=514

        Basically, for code generation, we need to know the class names that JAXB determined for the various wrappers and parameters. We call a method on the JAXB model passing the QName in and get a special object back with the classname in it. However, JAXB only passes back stuff it actually generated. In the case of episodes, it didn't generate anything. Thus, null is returned and we cannot proceed. Ideally, JAXB would return a proper object for us so we can get the information.

        I think this is why I've seen mixed results with episode files and CXF. The use cases I've seen before use episodes for their domain schemas, but not for the "wrapper" schemas used for the wsdl/soap interactions. For example, a "PurchaseOrder" object would be in the episode, but the "submitPO" and "submitPOResponse" schemas would be in the wsdl (which would import the domain schema). That use case WOULD work fine. JAXB would generate the SubmitPO object so null would not be returned.

        Without that fix in JAXB, I'm not sure what options we have. The ONLY thing I can think of is to parse and process the episode files ourselves and if jaxb returns null, start searching through them to see if a type is mapped or not. Quite a bit fragile.

        Show
        Daniel Kulp added a comment - OK. I can now see what is going on. It's technically a "bug" (or missing API) in JAXB. See: https://jaxb.dev.java.net/issues/show_bug.cgi?id=514 Basically, for code generation, we need to know the class names that JAXB determined for the various wrappers and parameters. We call a method on the JAXB model passing the QName in and get a special object back with the classname in it. However, JAXB only passes back stuff it actually generated. In the case of episodes, it didn't generate anything. Thus, null is returned and we cannot proceed. Ideally, JAXB would return a proper object for us so we can get the information. I think this is why I've seen mixed results with episode files and CXF. The use cases I've seen before use episodes for their domain schemas, but not for the "wrapper" schemas used for the wsdl/soap interactions. For example, a "PurchaseOrder" object would be in the episode, but the "submitPO" and "submitPOResponse" schemas would be in the wsdl (which would import the domain schema). That use case WOULD work fine. JAXB would generate the SubmitPO object so null would not be returned. Without that fix in JAXB, I'm not sure what options we have. The ONLY thing I can think of is to parse and process the episode files ourselves and if jaxb returns null, start searching through them to see if a type is mapped or not. Quite a bit fragile.
        Hide
        Daniel Kulp added a comment -

        The JAXB issue link is now:

        http://java.net/jira/browse/JAXB-514

        Show
        Daniel Kulp added a comment - The JAXB issue link is now: http://java.net/jira/browse/JAXB-514

          People

          • Assignee:
            Unassigned
            Reporter:
            Marcel Casado
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development