Thanks Chris. I looked at the PR - looks good.
I hope nobody relies on our specific sub-classes of JMSException...
Art
On Tue, Jan 16, 2024 at 5:21 PM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:
> Art,
>
> For your first point, existing clients will run into this but they
It looks good to me.
Thanks,
Regards
JB
On Tue, Jan 16, 2024 at 3:38 PM Christopher Shannon
wrote:
>
> As background, last week it was discovered (thanks Justin) that there was
> an oversight with the Exception handling over OpenWire with the upgrade to
> Jakarta apis in the 6.0.x broker.
>
Art,
For your first point, existing clients will run into this but they already
properly handle the ClassNotFoundException fine so the client never sees
the error. The marshaller just converts to a generic Throwable exception
when it can't find the type given on the classpath and then the
Looks like the key points here are:
1. Existing clients will run into ClassNotFoundException when
unmarshalling an exception from a non-compatible broker. (Do broker's ever
create an instance of the class specified by the client?)
2. The proposed change will update clients to convert
I talked with Tim and Matt offline and will go with that approach, I have
PRs open. If needed we can backport to some older clients too.
On Tue, Jan 16, 2024 at 9:38 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:
> As background, last week it was discovered (thanks Justin) that
As background, last week it was discovered (thanks Justin) that there was
an oversight with the Exception handling over OpenWire with the upgrade to
Jakarta apis in the 6.0.x broker.
https://issues.apache.org/jira/browse/AMQ-9418
The problem is that OpenWire has a response type to return an
