Ok,
I'm closing the vote until the necessary amendments are made.
Thanks,
Krzysztof
On Tue, Jun 14, 2022 at 9:14 PM W B D wrote:
> -1 (non-binding)
>
> Glad to see this moving forward to 2.0.x.
>
> However, I agree, we should not be defaulting to TLS 1.0 now. It should be
> at least 1.2 - or b
-1 (non-binding)
Glad to see this moving forward to 2.0.x.
However, I agree, we should not be defaulting to TLS 1.0 now. It should be
at least 1.2 - or better yet defer to the OS default as recommended by
Microsoft,
and still allow that to be overridden.
I guess this might be a simple matter of
-1
I wasnt actually going to vote given the below and as I hadn't
actually tried the client out, but on giving the archives a basic once
over for checksums etc and looking at the src licenses/notice etc
anyway...the same source file now used to configure the bits
referenced below is actually missi
It seems quite strange to even consider doing a new major release of
this client with it still defaulting to TLS 1.0, which has been
disabled on JDK releases (inc 7,8,11,17 etc) for over a year now, so
this wont even be able to connect with TLS to a broker running on a
remotely up to date JVM witho
+1
Jeff
> On Jun 11, 2022, at 1:55 PM, Havret wrote:
>
> Hi all,
>
> I have put together a release of activemq-nms-openwire, please check it and
> vote accordingly.
>
> This release contains the following changes:
> - https://issues.apache.org/jira/browse/AMQNET-637
> - https://issues.apache.
