Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.8.0
    • Fix Version/s: None
    • Component/s: camel-cxf
    • Labels:
      None
    • Estimated Complexity:
      Unknown

      Description

      This is a nasty one.

      We currently support URIs of the following form in camel-cxf:

      "cxf://http://localhost:9000/CxfEndpointTest/helloworld?wsdlURL=classpath:person.wsdl&serviceName={http://camel.apache.org/wsdl-first}PersonService&portName={http://camel.apache.org/wsdl-first}soap"
      

      As curly brackets are not valid, URIs like above are invalid. Unfortunately I suspect there are too many users who use this format now to just fix it so we need to deprecate this format, find a workaround and a solution.

      The solution I am proposing is to use another parameter: targetNamespace to replace the value between the curlies for the serviceName. The portName should not be a QName actually either. As such, the example above would become:

      "cxf://http://localhost:9000/CxfEndpointTest/helloworld?wsdlURL=classpath:person.wsdl&targetNamespace=http://camel.apache.org/wsdl-first&serviceName=PersonService&portName=soap"
      

      I will look for a workaround too, to not break existing code too much.

        Activity

        Hide
        Claus Ibsen added a comment -

        People have been using this for years with no general problem at all. Why suddenly all the fuzz and marking it as critical and whatnot?

        Show
        Claus Ibsen added a comment - People have been using this for years with no general problem at all. Why suddenly all the fuzz and marking it as critical and whatnot?
        Hide
        Hadrian Zbarcea added a comment -

        @Willem, as per the wsdl spec, the port @name is an 'nmtoken' not a 'qname'. Being part of a service it shares its namespace. Does CXF interpret this differently?

        Even if that were the case, we'd define two parameters then, something like serviceNamespace, and endpointNamespace, as you suggest, so it's not a biggie.

        I agree we need to support the current way, flawed as it is until 3.0 and I agree with the suggestion to fix and deprecate. I will not comment on the reason why we didn't catch it until now, I am as guilty as anyone.

        We can expect URIs to be UTF-8 encoded. Supporting other encodings would be a feature we could consider for the future, but I am not too worried about that now. If a URI not properly encoded is passed now, it's a toss up. After looking into the details of the code I can give examples that are invalid, yet work, and I can give examples that fail miserably (without even an clear explanation of what went wrong). It's fixable though in a few ways and I think I have a solution.

        Show
        Hadrian Zbarcea added a comment - @Willem, as per the wsdl spec , the port @name is an 'nmtoken' not a 'qname'. Being part of a service it shares its namespace. Does CXF interpret this differently? Even if that were the case, we'd define two parameters then, something like serviceNamespace, and endpointNamespace, as you suggest, so it's not a biggie. I agree we need to support the current way, flawed as it is until 3.0 and I agree with the suggestion to fix and deprecate. I will not comment on the reason why we didn't catch it until now, I am as guilty as anyone. We can expect URIs to be UTF-8 encoded. Supporting other encodings would be a feature we could consider for the future, but I am not too worried about that now. If a URI not properly encoded is passed now, it's a toss up. After looking into the details of the code I can give examples that are invalid, yet work, and I can give examples that fail miserably (without even an clear explanation of what went wrong). It's fixable though in a few ways and I think I have a solution.
        Hide
        Willem Jiang added a comment -

        "

        {" and "}

        " are not URI safe character, we did some work in Camel when it parsers endpoint URI to support it.
        If you are passing the URI which is encoded to camel, you may face that kind of trouble.
        As most user don't do it, we don't get this kind of alarm before.
        There is a question just comes into my mind, what if the user just pass a URI which is not encoded with UTF-8, or it is not be encoded.

        Show
        Willem Jiang added a comment - " {" and "} " are not URI safe character, we did some work in Camel when it parsers endpoint URI to support it. If you are passing the URI which is encoded to camel, you may face that kind of trouble. As most user don't do it, we don't get this kind of alarm before. There is a question just comes into my mind, what if the user just pass a URI which is not encoded with UTF-8, or it is not be encoded.
        Hide
        Willem Jiang added a comment - - edited

        The portName and serviceName may share difference namespace, we may need add options for this issue.
        In CxfEndpoint spring configuration we use the endpointName for the portName, we also unify the options definition.
        I suggest we use the endpointName for the portName, as the CXF is using the endpointName which is also used in WSDL2 definition.

        In CXFSpringEndpoint ,there are some method for set and get these options.
        like serviceNamespace, serviceLocalName, endpointNamespace, endpointLocalName
        If we move these method into CXFEndpoint, camel-cxf URI can be a good URI citizen.

        If we don't support the of serviceName and portName option for the camel-cxf URI, it will hurt the user.
        So I suggest to deprecate them in Camel 2.9 and remove the support of these option in URI in Camel 3.0.

        Show
        Willem Jiang added a comment - - edited The portName and serviceName may share difference namespace, we may need add options for this issue. In CxfEndpoint spring configuration we use the endpointName for the portName, we also unify the options definition. I suggest we use the endpointName for the portName, as the CXF is using the endpointName which is also used in WSDL2 definition. In CXFSpringEndpoint ,there are some method for set and get these options. like serviceNamespace, serviceLocalName, endpointNamespace, endpointLocalName If we move these method into CXFEndpoint, camel-cxf URI can be a good URI citizen. If we don't support the of serviceName and portName option for the camel-cxf URI, it will hurt the user. So I suggest to deprecate them in Camel 2.9 and remove the support of these option in URI in Camel 3.0.

          People

          • Assignee:
            Hadrian Zbarcea
            Reporter:
            Hadrian Zbarcea
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development