[
https://issues.apache.org/jira/browse/ARIES-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amichai Rothman updated ARIES-2211:
-----------------------------------
Summary: Add support for deprecated EndpointListener (was: Add support for
deprecated EndpointListener support)
> Add support for deprecated EndpointListener
> -------------------------------------------
>
> Key: ARIES-2211
> URL: https://issues.apache.org/jira/browse/ARIES-2211
> Project: Aries
> Issue Type: Bug
> Components: Remote Service Admin
> Affects Versions: rsa-1.16.1
> Reporter: Amichai Rothman
> Priority: Major
>
> The spec requires support for both the new EndpointEventListener and the
> deprecated EndpointListener. The current RSA components all use the newer
> EndpointEventListener.
> In practice, it's very unlikely that anywould would need this
> backwards-compatibility:
> - The new EventPointListener was introduced over a decade ago.
> - There is no issue when using only aries RSA, as all components use the new
> listener amongst themselves.
> - There is no issue across osgi containers, i.e. remotes, since the discovery
> providers are responsible for transporting events between the containers and
> each side has its own local event producers/consumers using whatever listener
> it supports. The issue is only of cross-compatibility within a single
> container, not between different systems.
> - So, for such compatibility issues to arise in practice, one would have to
> be using two different RSA implementations, within the same osgi container,
> where one of them is over a decade old and the other is more modern. That is
> exceedingly unlikely to happen in practice.
> That being said, such compatibility is needed for two reasons:
> - So we can be fully spec compliant.
> - For TCK tests to pass.
> The suggested solution is not to bring back unused deprecated interfaces into
> the many components and classes that deal with endpoint events, but rather to
> add an external bridge service that tracks event consumers and producers in
> the system and translates from one event type to the other as needed when
> events are published.
> Moreover, due to the above reasons, this component can be disabled by default
> to avoid complexity and preformance implications, with a configurable option
> to enable it only when needed, likely only for the TCK test environment, or
> for whomever runs such an unlikely configuration on their system.
> Once the deprecated interface is removed from a future spec/TCK, we can just
> delete this bridge implementation. All other code remains unaffected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
