Camel
  1. Camel
  2. CAMEL-4731

simpler wiring of Camel CXF endpoints to named CXF buses in spring

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.8.3
    • Fix Version/s: 2.8.4, 2.9.0
    • Component/s: camel-cxf
    • Labels:
      None
    • Patch Info:
      Patch Available
    • Estimated Complexity:
      Unknown

      Description

      I think the current wiring configuration (used in those camel-cxf tests) for wiring CXF endpoints to specific cxf bus instances using spring is cumbersome and not appealing. So, I would like to suggest a patch for this problem.

      To start, here is how the the current configuration convention looks like:
      <beans ...>
      <bean id="cxf1" class="org.apache.cxf.bus.extension.ExtensionManagerBus"/>
      <bean id="cxf2" class="org.apache.cxf.bus.extension.ExtensionManagerBus"/>

      <cxfcore:bus bus="cxf1">
      ...
      </cxfcore:bus>

      <cxfcore:bus bus="cxf2">
      ....
      </cxfcore:bus>

      <cxf:cxfEndpoint id="routerEndpoint"
      serviceClass="..."
      ...
      bus="cxf1"/>

      <cxf:cxfEndpoint id="serviceEndpoint"
      serviceClass="..."
      ...
      bus="cxf2"/>
      </beans>

      I would like to get rid of the indirect wiring of the CXF endpoints using ExtensionManagerBus beans. The attached patch for camel/trunk should directly wire the endpoints to the named buses. I would appreciate if you can look at it.

      Thank you.

      regards, aki

      1. patch.txt
        4 kB
        Aki Yoshida

        Issue Links

          Activity

          Hide
          Daniel Kulp added a comment -

          I'll see if it's easy enough to support both. The attached patch causes a double setting of the bus property when used with the latest CXF code that has the fix in which has a different set of potential issues. I think we can just override the parseAttributes call and check if CXF has handled it (newer CXF versions will) and, if not, then handle it in Camel (older versions of CXF). I'll play around with it and see what we can do.

          Show
          Daniel Kulp added a comment - I'll see if it's easy enough to support both. The attached patch causes a double setting of the bus property when used with the latest CXF code that has the fix in which has a different set of potential issues. I think we can just override the parseAttributes call and check if CXF has handled it (newer CXF versions will) and, if not, then handle it in Camel (older versions of CXF). I'll play around with it and see what we can do.
          Hide
          Willem Jiang added a comment -

          +1 to support the old version of CXF.

          Show
          Willem Jiang added a comment - +1 to support the old version of CXF.
          Hide
          Aki Yoshida added a comment - - edited

          Hi Dan,
          the blueprint stuff is handled correctly in camel.

          Regarding your second comment, Initially, I also tried to fix it by modifying CXF's AbstractBeanDefinitionParser's bus attribute handling. But this lead to another issue that required a larger amount of changes. But I saw your fix and it looks simpler that I thought.

          The fix that I suggested is similar to what the current CXF jaxws endpoint implementation does to get this wiring working. Another benefit of this camel based fix is that you can run the fixed camel version against older CXF versions (so that we can stabilize the camel-cxf's endpoint wiring convention without dependency to a specific version of CXF).

          But as you said, the proper fix should go into CXF and with your fix that you already made in 2.5.1 and 2.4.5, I can live without this fix in Camel, as long as the camel-cxf's unit test (of the simple wiring) gets activated with the corrected cxf version soon to ensure the stability of this wiring convention.

          Thanks.
          regards, aki

          Show
          Aki Yoshida added a comment - - edited Hi Dan, the blueprint stuff is handled correctly in camel. Regarding your second comment, Initially, I also tried to fix it by modifying CXF's AbstractBeanDefinitionParser's bus attribute handling. But this lead to another issue that required a larger amount of changes. But I saw your fix and it looks simpler that I thought. The fix that I suggested is similar to what the current CXF jaxws endpoint implementation does to get this wiring working. Another benefit of this camel based fix is that you can run the fixed camel version against older CXF versions (so that we can stabilize the camel-cxf's endpoint wiring convention without dependency to a specific version of CXF). But as you said, the proper fix should go into CXF and with your fix that you already made in 2.5.1 and 2.4.5, I can live without this fix in Camel, as long as the camel-cxf's unit test (of the simple wiring) gets activated with the corrected cxf version soon to ensure the stability of this wiring convention. Thanks. regards, aki
          Hide
          Daniel Kulp added a comment -

          Actually, I think this is more of a bug in CXF and I'd rather get it fixed there. In the CXF, the AbstractBeanDefinitionParser thing SHOULD be setting the bus property if the parser returns true from the hasBusProperty. However, while doing so, in this case, it's losing the Bus name. Thus, it's getting default bus. The proper fix is to make sure the bus name isn't lost.

          Show
          Daniel Kulp added a comment - Actually, I think this is more of a bug in CXF and I'd rather get it fixed there. In the CXF, the AbstractBeanDefinitionParser thing SHOULD be setting the bus property if the parser returns true from the hasBusProperty. However, while doing so, in this case, it's losing the Bus name. Thus, it's getting default bus. The proper fix is to make sure the bus name isn't lost.
          Hide
          Daniel Kulp added a comment -

          Quick question: do you know of the blueprint stuff has similar issues?

          Show
          Daniel Kulp added a comment - Quick question: do you know of the blueprint stuff has similar issues?
          Hide
          Aki Yoshida added a comment -

          the following files are modified

          CxfEndpointBeanBusSettingTest.java
          CxfEndpointBeansBusSetting.xml
          CxfEndpointBeanDefinitionParser.java

          Show
          Aki Yoshida added a comment - the following files are modified CxfEndpointBeanBusSettingTest.java CxfEndpointBeansBusSetting.xml CxfEndpointBeanDefinitionParser.java

            People

            • Assignee:
              Daniel Kulp
              Reporter:
              Aki Yoshida
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development