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
        Akitoshi Yoshida

        Issue Links

          Activity

          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          20d 21h 54m 1 Daniel Kulp 22/Dec/11 16:33
          Gavin made changes -
          Link This issue depends upon CXF-3947 [ CXF-3947 ]
          Gavin made changes -
          Link This issue depends on CXF-3947 [ CXF-3947 ]
          Daniel Kulp made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 2.8.4 [ 12319072 ]
          Fix Version/s 2.9.0 [ 12316374 ]
          Fix Version/s 2.9.1 [ 12319191 ]
          Resolution Fixed [ 1 ]
          Claus Ibsen made changes -
          Fix Version/s 2.9.1 [ 12319191 ]
          Fix Version/s 2.9.0 [ 12316374 ]
          Fix Version/s 2.8.4 [ 12319072 ]
          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
          Akitoshi 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
          Akitoshi 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
          Daniel Kulp made changes -
          Link This issue depends on CXF-3947 [ CXF-3947 ]
          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?
          Daniel Kulp made changes -
          Assignee Daniel Kulp [ dkulp ]
          Akitoshi Yoshida made changes -
          Field Original Value New Value
          Attachment patch.txt [ 12505785 ]
          Hide
          Akitoshi Yoshida added a comment -

          the following files are modified

          CxfEndpointBeanBusSettingTest.java
          CxfEndpointBeansBusSetting.xml
          CxfEndpointBeanDefinitionParser.java

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

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development