Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AMQNET-631: Restore session extensions api #11

Closed
wants to merge 1 commit into from

Conversation

Havret
Copy link
Contributor

@Havret Havret commented Nov 28, 2019

This PR addresses a change requested via mailing list. Waiting for jira Issue.

I have tried updating the Apache.ActiveMQ.NMS Nuget package to 1.8.0 in my
project, and am getting build errors indicating that the GetDestination
method is not available on ISession.

This method is defined in the SessionExtensions class, but it is
conditionally compiled only if the symbol MONO or NET_3_5 is defined.

I assume that this was defined previously, but is now inadvertently omitted
as part of the restructuring that was done for 1.8. Probably, the extension
methods could be defined for any supported version of .NET at this point,
as .NET < 3.5 is no longer supported by the project.

The extension method simply delegates to SessionUtil.GetDestination, which
is exposed to public as well, so for my immediate need I just called that
directly.
However, I assume this should not have been necessary and that the
extension methods should still be provided as before, rather than have a
breaking change.

@michaelpearce-gain
Copy link
Contributor

michaelpearce-gain commented Jan 22, 2020

These were not part of 4.x and above builds so its been removed in later language versions, as its a extension its not really something that should be in API, as well they dont exist in JMS apis.
As such it isnt a breaking change in 1.8, its been removed for some time technically.

@Havret Havret changed the title Restore session extensions api AMQNET-631: Restore session extensions api Jan 23, 2020
@Havret
Copy link
Contributor Author

Havret commented Jan 23, 2020

I believe it was breaking for the folks who were using old versions of .net framework or mono.

@michaelandrepearce
Copy link
Contributor

michaelandrepearce commented Jan 23, 2020

But it would have been broken for them as soon as they move on from 3.5 (this wasnt a change when netstd support added) its always been intended to be removed after 3.5 its a legacy

@HavretGC
Copy link
Contributor

I don't know what was the intent of the original authors of the API, probably we should ask them. If I was calling the shots I would remove concrete implementation altogether from here, as this lib should only define interfaces.

@michaelandrepearce
Copy link
Contributor

id vote with remove also.

@Havret Havret closed this Apr 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants