Mule
  1. Mule
  2. MULE-875

Expose xfire services using interfaces, rather than the implementation.

    Details

    • Type: Patch submission Patch submission
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.3
    • Component/s: Modules: CXF
    • Labels:
      None
    • Similar Issues:
      MULE-2108JSR181 annotations not used during service name lookup in XFire service registry.
      MULE-866Exposing XMLBean based services via the xfire provider could benefit from xfire's built-in type registry for XmlBeans
      MULE-1319XFire Jsr181 Annotations do not mix with property "serviceInterfaces"
      MULE-2111NestedInvocationHandler incorrectly uses only the first argument passed to the dynamic service interface proxy.
      MULE-3473CXF requires serviceClass attribute in echo example which uses different interface than what component implements
      MULE-3253PassthroughComponent should implement Component directly rather than be used with JavaComponent
      MULE-719ServiceProxy should looks for interfaces implemented by superclasses of the component as well.
      MULE-2814XFire message receiver doesn't handle object factory correctly when using jsr181 annotation
      MULE-2017Mule Integration with Xfire Web service
      MULE-843Refactor EventGroup to not expose the internal List of events

      Description

      Some method (either Auto-Discovering or component-property) of naming a service interface for exposing as the service should be used. This is akin to what the Axis provider does.

        Activity

          People

          • Assignee:
            Alan Cassar
            Reporter:
            Eric Schult
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development