Announcement Announcement Module
Collapse
No announcement yet.
Duplicate beans of type - Proxy clashes with implementation. Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Duplicate beans of type - Proxy clashes with implementation.

    I have a number of service interfaces that are implemented and wired together through spring on a type basis. I.e. within the service implementation layer I expect to define/provide a single implementation of each interface.

    Sat on top of the service implementation is a very thin proxy layer that allows for the service interfaces to be exposed externally as a web services in order to bridge a physical separation.The web service interface simply extends and overrides the service interface in order to annotate it as a web service with web methods. An implementation of the web service interface then merely delegates to the implementation of the service interface.

    Clients are then defined for these web services using a Port Proxy that declares itself to be an implementation of the web service interface. Since this web service interface extends the service interface the Port Proxy clients can also be seen as an implementation of the service interface. As such consumers of the service interface can be agnostic as to which side of a physical separation they sit.

    This all works unless I encounter the situation where the implementer of a service interface is dependent on another service interface. This is obviously fine within the implementation layer, but in the thin web service proxy layer a second implementation of the service interface (the web service one) is created. This is then visible within the application context resulting in duplicate beans being found when wiring the service implementations together.

    I looked at 2 options to resolve this
    • A qualifier to ensure only the 'real' implementation rather than the web proxy was seen. However this does not solve the problem when the consumer of the service interface can sit either side of the physical separation (cross cutting components for example) since the qualifier is side dependent.
    • Wiring by name. This feels wrong since the dependency is really one of type, plus it introduces a naming strategy that needs to be managed.

    Logically (in my mind anyway) the web service interface implementations should not be visible to the jars it depends on, only upwards to those that depend on it. I want the web service to load from, and not add to, an isolated context that provides the dependencies which it relies on. The context it exposes then effectively replaces that which it loaded (it proxies the context in it's entirety). I just can't seem to find a way of achieving this - am I missing something?

  • #2
    <<bump>>

    I am still looking for a clean way to achieve this.

    If my description is nonsensical then let me know and I will see if I can reword it.

    Comment

    Working...
    X