Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-09-07 Thread Christoph John

Thanks, Jonathan.



On 27.08.22 20:05, Jonathan Valliere wrote:

https://github.com/apache/mina/blob/7893dfc29bb37dcef1345ffb482709902b6b6c9f/mina-core/src/main/java/org/apache/mina/transport/socket/nio/NioSocketSession.java#L94

On Aug 26, 2022 at 5:15:42 AM, Christoph John  wrote:

The constant PEER_ADDRESS is no longer present in the code in 2.2.x

I can see however that in 
https://github.com/apache/mina/blob/7893dfc29bb37dcef1345ffb482709902b6b6c9f/mina-core/src/main/java/org/apache/mina/filter/ssl/SslFilter.java#L272 
and 
https://github.com/apache/mina/blob/7893dfc29bb37dcef1345ffb482709902b6b6c9f/mina-core/src/main/java/org/apache/mina/filter/ssl/SslFilter.java#L239 
the remoteAddress is used if it is not NULL.

But I am not able to find out where the remoteAddress is set on the IoSession.

Cheers,
Chris.

On 25.08.22 12:27, Jonathan Valliere wrote:

It should be either doing it automatically or is a configurable option in
the filter.

I’m far away from my computer right now so I can’t check.

On Wed, Aug 24, 2022 at 6:44 AM Christoph John
wrote:


Hi Jonathan,

are you able to help me with the last item on the list (see quote below)?

Thank you in advance and best regards,
Chris.

On 28.07.22 16:42, Emmanuel Lécharny wrote:

3. to use SNI we formerly set the "PEER_ADDRESS". Is this still possible?
Please see here:
https://github.com/quickfix-j/quickfixj/blob/c4c963cdb2a6c4f1942f12bcfd890bff166788c2/quickfixj-core/src/main/java/quickfix/mina/ssl/SSLFilter.java#L66-L78

Good question. I don't know... Jonathan ?






--
Christoph John
Software Engineering
T +49 241557080-28christoph.j...@macd.com

MACD GmbHOppenhoffallee 103
52066 Aachen, 
Germanywww.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald




--
Christoph John
Software Engineering
T +49 241 557080-28
christoph.j...@macd.com

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald


--
Christoph John
Software Engineering
T +49 241 557080-28
christoph.j...@macd.com

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald


Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-08-27 Thread Jonathan Valliere
https://github.com/apache/mina/blob/7893dfc29bb37dcef1345ffb482709902b6b6c9f/mina-core/src/main/java/org/apache/mina/transport/socket/nio/NioSocketSession.java#L94

On Aug 26, 2022 at 5:15:42 AM, Christoph John 
wrote:

> The constant PEER_ADDRESS is no longer present in the code in 2.2.x
>
> I can see however that in
> https://github.com/apache/mina/blob/7893dfc29bb37dcef1345ffb482709902b6b6c9f/mina-core/src/main/java/org/apache/mina/filter/ssl/SslFilter.java#L272
> and
> https://github.com/apache/mina/blob/7893dfc29bb37dcef1345ffb482709902b6b6c9f/mina-core/src/main/java/org/apache/mina/filter/ssl/SslFilter.java#L239
> the remoteAddress is used if it is not NULL.
> But I am not able to find out where the remoteAddress is set on the
> IoSession.
>
> Cheers,
> Chris.
>
> On 25.08.22 12:27, Jonathan Valliere wrote:
>
> It should be either doing it automatically or is a configurable option in
> the filter.
>
> I’m far away from my computer right now so I can’t check.
>
> On Wed, Aug 24, 2022 at 6:44 AM Christoph John  
> 
> wrote:
>
>
> Hi Jonathan,
>
> are you able to help me with the last item on the list (see quote below)?
>
> Thank you in advance and best regards,
> Chris.
>
> On 28.07.22 16:42, Emmanuel Lécharny wrote:
>
> 3. to use SNI we formerly set the "PEER_ADDRESS". Is this still possible?
> Please see 
> here:https://github.com/quickfix-j/quickfixj/blob/c4c963cdb2a6c4f1942f12bcfd890bff166788c2/quickfixj-core/src/main/java/quickfix/mina/ssl/SSLFilter.java#L66-L78
>
> Good question. I don't know... Jonathan ?
>
>
>
>
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557080-28christoph.j...@macd.com
>
> MACD GmbHOppenhoffallee 103
> 52066 Aachen, Germany 
> 
>  
> www.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557080-28christoph.j...@macd.com
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>


Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-08-26 Thread Christoph John

The constant PEER_ADDRESS is no longer present in the code in 2.2.x

I can see however that in 
https://github.com/apache/mina/blob/7893dfc29bb37dcef1345ffb482709902b6b6c9f/mina-core/src/main/java/org/apache/mina/filter/ssl/SslFilter.java#L272 
and 
https://github.com/apache/mina/blob/7893dfc29bb37dcef1345ffb482709902b6b6c9f/mina-core/src/main/java/org/apache/mina/filter/ssl/SslFilter.java#L239 
the remoteAddress is used if it is not NULL.

But I am not able to find out where the remoteAddress is set on the IoSession.

Cheers,
Chris.

On 25.08.22 12:27, Jonathan Valliere wrote:

It should be either doing it automatically or is a configurable option in
the filter.

I’m far away from my computer right now so I can’t check.

On Wed, Aug 24, 2022 at 6:44 AM Christoph John
wrote:


Hi Jonathan,

are you able to help me with the last item on the list (see quote below)?

Thank you in advance and best regards,
Chris.

On 28.07.22 16:42, Emmanuel Lécharny wrote:

3. to use SNI we formerly set the "PEER_ADDRESS". Is this still possible?
Please see here:
https://github.com/quickfix-j/quickfixj/blob/c4c963cdb2a6c4f1942f12bcfd890bff166788c2/quickfixj-core/src/main/java/quickfix/mina/ssl/SSLFilter.java#L66-L78

Good question. I don't know... Jonathan ?






--
Christoph John
Software Engineering
T +49 241557080-28christoph.j...@macd.com

MACD GmbHOppenhoffallee 103
52066 Aachen, 
Germanywww.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald




--
Christoph John
Software Engineering
T +49 241 557080-28
christoph.j...@macd.com

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald


Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-08-25 Thread Jonathan Valliere
It should be either doing it automatically or is a configurable option in
the filter.

I’m far away from my computer right now so I can’t check.

On Wed, Aug 24, 2022 at 6:44 AM Christoph John 
wrote:

> Hi Jonathan,
>
> are you able to help me with the last item on the list (see quote below)?
>
> Thank you in advance and best regards,
> Chris.
>
> On 28.07.22 16:42, Emmanuel Lécharny wrote:
>
> 3. to use SNI we formerly set the "PEER_ADDRESS". Is this still possible?
> Please see here:
> https://github.com/quickfix-j/quickfixj/blob/c4c963cdb2a6c4f1942f12bcfd890bff166788c2/quickfixj-core/src/main/java/quickfix/mina/ssl/SSLFilter.java#L66-L78
>
> Good question. I don't know... Jonathan ?
>
>
>
>
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557080-28christoph.j...@macd.com
>
> MACD GmbHOppenhoffallee 103
> 52066 Aachen, Germany 
> www.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>


Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-08-24 Thread Christoph John

Hi Jonathan,

are you able to help me with the last item on the list (see quote below)?

Thank you in advance and best regards,
Chris.

On 28.07.22 16:42, Emmanuel Lécharny wrote:
3. to use SNI we formerly set the "PEER_ADDRESS". Is this still possible? Please see here: 
https://github.com/quickfix-j/quickfixj/blob/c4c963cdb2a6c4f1942f12bcfd890bff166788c2/quickfixj-core/src/main/java/quickfix/mina/ssl/SSLFilter.java#L66-L78


Good question. I don't know... Jonathan ?







--
Christoph John
Software Engineering
T +49 241 557080-28
christoph.j...@macd.com

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald


Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-28 Thread Emmanuel Lécharny

Hi Christoph,

answers inline

On 28/07/2022 14:48, Christoph John wrote:

Hi Emmanuel,




I took a look at this and it seems the two latches were a red 
herring. One is for the initiator (connector) and the other one for 
the acceptor that are used in the unit test.


I must admit I haven't spent enough time to unerstand what was going 
on ;-)




No problem, thank you for your time to narrow the problem down. I for 
one am no expert in MINA. :)


When trying to use MINA 2.2.0 I made the following changes to QFJ to 
make it compile. Could you (or Jonathan) please tell me if the changes 
are safe?


https://github.com/quickfix-j/quickfixj/pull/441/files

Especially I have the following questions:
1. setUseClientMode() should be no longer necessary


No. It's automatically deduced.


2. the "initiateHandshake" and "autoStart" stuff of the SSLFilter is no > 
longer necessary??


I think it' snow spurious. I have to check

3. to use SNI we formerly set the "PEER_ADDRESS". Is this still 
possible? Please see here: 
https://github.com/quickfix-j/quickfixj/blob/c4c963cdb2a6c4f1942f12bcfd890bff166788c2/quickfixj-core/src/main/java/quickfix/mina/ssl/SSLFilter.java#L66-L78


Good question. I don't know... Jonathan ?


--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-28 Thread Christoph John

Hi Emmanuel,




I took a look at this and it seems the two latches were a red herring. One is for the initiator 
(connector) and the other one for the acceptor that are used in the unit test.


I must admit I haven't spent enough time to unerstand what was going on ;-)



No problem, thank you for your time to narrow the problem down. I for one am no 
expert in MINA. :)

When trying to use MINA 2.2.0 I made the following changes to QFJ to make it compile. Could you (or 
Jonathan) please tell me if the changes are safe?


https://github.com/quickfix-j/quickfixj/pull/441/files

Especially I have the following questions:
1. setUseClientMode() should be no longer necessary
2. the "initiateHandshake" and "autoStart" stuff of the SSLFilter is no longer 
necessary??
3. to use SNI we formerly set the "PEER_ADDRESS". Is this still possible? Please see here: 
https://github.com/quickfix-j/quickfixj/blob/c4c963cdb2a6c4f1942f12bcfd890bff166788c2/quickfixj-core/src/main/java/quickfix/mina/ssl/SSLFilter.java#L66-L78


Many thanks in advance and best regards
Chris

--
Christoph John
Software Engineering
T +49 241 557080-28
christoph.j...@macd.com

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald


Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-21 Thread Emmanuel Lécharny




On 21/07/2022 15:38, Christoph John wrote:

Hi Emmanuel,

I took a look at this and it seems the two latches were a red herring. 
One is for the initiator (connector) and the other one for the acceptor 
that are used in the unit test.


I must admit I haven't spent enough time to unerstand what was going on ;-)



However, I think I found the root cause for the failing unit tests. We 
have an AbstractIoHandler which extends IoHandlerAdapter. In its 
exceptionCaught() method we do some magic and in the end disconnect the 
session. You can see that here: 
https://github.com/quickfix-j/quickfixj/pull/441/files#diff-ecbb4c6b07934a11f46ceae43478dc258e7dfcaedad8c67881c7441848f8909d
Now when I exchange the closeNow() with closeOnFlush() the unit tests 
succeed, meaning that the registered filter is notified of the Exception.
Is this expected? 


The closeNow is pretty brutal. In case of a TLS failure, the SSLEngine 
generates a message that *must* be sent to the remote peer. This message 
is a TLS alert, and it cntains the rooot cause of the failure.


Closing the connection brutally will not allow this message to be sent, 
so doing a close n flush will guarantee that *every* message stored in 
the queue qill be sent.


So, yes, this is the way to go.


Did this behaviour change intentionally?

No.

Is it safe to
always use closeOnFlush()? 


It should be.

(probably I should wait for the returned

CloseFuture to complete for a sensible amount of time)

Thanks in advance and best regards
Chris.


On 16.07.22 05:30, Emmanuel Lécharny wrote:

Hi Christoph,

after further analysis, it appears that we have 2 countdown latch 
instances (exceptionThrownLatch) at play:

* one that is decremented in the exceptionCaught event,

[Count1]>:1]--->PKIX path validation failed: 
java.security.cert.CertPathValidatorException: signature check failed
[Count0]>:0<]---


* and the other one that is checked for the exfeption being received:

[Count:1 in 
assert


As you can see, the instances ID are different: b9ed2fa and 8458f04.

Seems like the handler you have added in teh chain is not owning the 
same latch that the one being checked in the assert, now to see why...



On 13/07/2022 17:43, Emmanuel Lécharny wrote:

Hi Christoph,

actually, there is a kind of race condition in your test.

I have added some logs:

 @Override
 public void exceptionCaught(NextFilter nextFilter, 
IoSession session, Throwable cause)

 throws Exception {

System.out.println("[Count:"+exceptionThrownLatch.getCount()+"]--->" 
+ cause.getMessage());

 //LOGGER.info("exceptionCaught", cause);
 exceptionThrownLatch.countDown();

System.out.println("[Count:"+exceptionThrownLatch.getCount()+"<]---"); 


 nextFilter.exceptionCaught(session, cause);
 }


which generates:

[Count:1]--->PKIX path validation failed: 
java.security.cert.CertPathValidatorException: signature check failed

[Count:0<]---

after the initiator.start() call. So the latch is properly 
decremented and the initiator.assertSslExceptionThrown() should be 
valid:


 public void assertSslExceptionThrown() throws Exception {

System.out.println("[Count:"+exceptionThrownLatch.getCount()+" in 
assert");
 boolean reachedZero = 
exceptionThrownLatch.await(TIMEOUT_SECONDS, TimeUnit.SECONDS);


 if (!reachedZero) {
 throw new AssertionError("No SSL exception thrown");
 }

and weird enough, the latch counter is  1 ! (ie, the counter is 
*not* decremented)



Here are the complete logs (check the 'Count' string):


juil. 13, 2022 5:33:12 PM 
quickfix.mina.ssl.SSLCertificateTest$TestAcceptor createConnector

INFOS: Creating acceptor: [DEFAULT]
SocketUseSSL=Y
EndTime=00:00:00
ReconnectInterval=2
SocketAcceptPort=50957
SocketTrustStore=single-session/server.truststore
NeedClientAuth=Y
EnabledProtocols=TLSv1.2
SocketAcceptHost=localhost
CipherSuites=TLS_RSA_WITH_AES_128_CBC_SHA
ConnectionType=acceptor
StartTime=00:00:00
SocketKeyStorePassword=password
SocketConnectProtocol=SOCKET
KeyStoreType=JKS
SocketKeyStore=single-session/server.keystore
SocketTrustStorePassword=password
TrustStoreType=JKS
HeartBtInt=30
[SESSION]
BeginString=FIX.4.4
SenderCompID=ALFA
TargetCompID=ZULU
DataDictionary=FIX44.xml

juil. 13, 2022 5:33:14 PM quickfix.DefaultSessionSchedule 
INFOS: [FIX.4.4:ALFA->ZULU] daily, 00:00:00-UTC - 00:00:00-UTC
<20220713-15:33:14, FIX.4.4:ALFA->ZULU, event> (Session 
FIX.4.4:ALFA->ZULU schedule is daily, 00:00:00-UTC - 00:00:00-UTC)
<20220713-15:33:14, FIX.4.4:ALFA->ZULU, event> (Created session: 
FIX.4.4:ALFA->ZULU)
juil. 13, 2022 5:33:14 PM quickfix.mina.SessionConnector 
startSessionTimer

INFOS: SessionTimer started
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: Soc

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-21 Thread Christoph John

Hi Emmanuel,

I took a look at this and it seems the two latches were a red herring. One is for the initiator 
(connector) and the other one for the acceptor that are used in the unit test.


However, I think I found the root cause for the failing unit tests. We have an AbstractIoHandler 
which extends IoHandlerAdapter. In its exceptionCaught() method we do some magic and in the end 
disconnect the session. You can see that here: 
https://github.com/quickfix-j/quickfixj/pull/441/files#diff-ecbb4c6b07934a11f46ceae43478dc258e7dfcaedad8c67881c7441848f8909d
Now when I exchange the closeNow() with closeOnFlush() the unit tests succeed, meaning that the 
registered filter is notified of the Exception.
Is this expected? Did this behaviour change intentionally? Is it safe to always use closeOnFlush()? 
(probably I should wait for the returned CloseFuture to complete for a sensible amount of time)


Thanks in advance and best regards
Chris.


On 16.07.22 05:30, Emmanuel Lécharny wrote:

Hi Christoph,

after further analysis, it appears that we have 2 countdown latch instances (exceptionThrownLatch) 
at play:

* one that is decremented in the exceptionCaught event,

[Count:1]--->PKIX path 
validation failed: java.security.cert.CertPathValidatorException: signature check failed

[Count:0<]---

* and the other one that is checked for the exfeption being received:

[Count:1 in assert

As you can see, the instances ID are different: b9ed2fa and 8458f04.

Seems like the handler you have added in teh chain is not owning the same latch that the one being 
checked in the assert, now to see why...



On 13/07/2022 17:43, Emmanuel Lécharny wrote:

Hi Christoph,

actually, there is a kind of race condition in your test.

I have added some logs:

 @Override
 public void exceptionCaught(NextFilter nextFilter, IoSession session, Throwable 
cause)

 throws Exception {

System.out.println("[Count:"+exceptionThrownLatch.getCount()+"]--->" + 
cause.getMessage());

 //LOGGER.info("exceptionCaught", cause);
 exceptionThrownLatch.countDown();

System.out.println("[Count:"+exceptionThrownLatch.getCount()+"<]---");
 nextFilter.exceptionCaught(session, cause);
 }


which generates:

[Count:1]--->PKIX path validation failed: 
java.security.cert.CertPathValidatorException: signature check failed

[Count:0<]---

after the initiator.start() call. So the latch is properly decremented and the 
initiator.assertSslExceptionThrown() should be valid:


 public void assertSslExceptionThrown() throws Exception {

System.out.println("[Count:"+exceptionThrownLatch.getCount()+" in assert");
 boolean reachedZero = exceptionThrownLatch.await(TIMEOUT_SECONDS, 
TimeUnit.SECONDS);

 if (!reachedZero) {
 throw new AssertionError("No SSL exception thrown");
 }

and weird enough, the latch counter is  1 ! (ie, the counter is *not* 
decremented)


Here are the complete logs (check the 'Count' string):


juil. 13, 2022 5:33:12 PM quickfix.mina.ssl.SSLCertificateTest$TestAcceptor 
createConnector
INFOS: Creating acceptor: [DEFAULT]
SocketUseSSL=Y
EndTime=00:00:00
ReconnectInterval=2
SocketAcceptPort=50957
SocketTrustStore=single-session/server.truststore
NeedClientAuth=Y
EnabledProtocols=TLSv1.2
SocketAcceptHost=localhost
CipherSuites=TLS_RSA_WITH_AES_128_CBC_SHA
ConnectionType=acceptor
StartTime=00:00:00
SocketKeyStorePassword=password
SocketConnectProtocol=SOCKET
KeyStoreType=JKS
SocketKeyStore=single-session/server.keystore
SocketTrustStorePassword=password
TrustStoreType=JKS
HeartBtInt=30
[SESSION]
BeginString=FIX.4.4
SenderCompID=ALFA
TargetCompID=ZULU
DataDictionary=FIX44.xml

juil. 13, 2022 5:33:14 PM quickfix.DefaultSessionSchedule 
INFOS: [FIX.4.4:ALFA->ZULU] daily, 00:00:00-UTC - 00:00:00-UTC
<20220713-15:33:14, FIX.4.4:ALFA->ZULU, event> (Session FIX.4.4:ALFA->ZULU schedule is daily, 
00:00:00-UTC - 00:00:00-UTC)

<20220713-15:33:14, FIX.4.4:ALFA->ZULU, event> (Created session: 
FIX.4.4:ALFA->ZULU)
juil. 13, 2022 5:33:14 PM quickfix.mina.SessionConnector startSessionTimer
INFOS: SessionTimer started
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketTcpNoDelay=true
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketSynchronousWrites=false
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketSynchronousWriteTimeout=3
juil. 13, 2022 5:33:14 PM quickfix.mina.acceptor.AbstractSocketAcceptor 
installSSL
INFOS: Installing SSL filter for 0.0.0.0/0.0.0.0:50957
juil. 13, 2022 5:33:14 PM quickfix.mina.acceptor.AbstractSocketAcceptor 
startAcceptingConnections
INFOS: Listening for connections at 0.0.0.0/0.0.0.0:50957 for session(s) 
[FIX.4.4:A

Re: [Vote] MINA 2.2.0 release

2022-07-17 Thread Guillaume Nodet
+1

Le lun. 4 juil. 2022 à 23:43, Emmanuel Lécharny  a
écrit :

> Hi!
>
>
> it has been a couple of months now that I cut a version of MINA 2.2.0,
> but haven't started a vote, because I wanted to test that exception were
> properly handled when generated from the SslFilter. It took may way
> longer to check that, mainly due to external factors).
>
> Anyway, I'm done with the test, all is nominal, so here is a formal vote
> for MINA 2.2.0.
>
> This version comes with a complete rewrite of the SSL layer, thanks for
> Jonathan hard work !
>
>
> A temporary tag has been created (it can be removed if the vote is not
> approved) :
>
>
> https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4
>
>
>
> The newly approved Nexus has been used for the preparation of this
> release and all final artifacts are stored in a staging repository:
> https://repository.apache.org/content/repositories/orgapachemina-1051
>
>
> The distributions are available for download on :
> https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0
>
> Let us vote :
> [ ] +1 | Release MINA 2.2.0
> [ ] ± | Abstain
> [ ] -1 | Do *NOT*   release MINA 2.2.0
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

-- 

Guillaume Nodet


result: was [Vote] MINA 2.2.0 release

2022-07-17 Thread Emmanuel Lécharny

Thanks for the votes!

I therefore close this vote with 3 binding +1 and o,ne non binding +1:

- Christoph John (non binding)
- Jeff (Genender)
- Jonathan
- and me

I will push the packages, update the site and announce the release in 
the coming hours !


On 04/07/2022 23:43, Emmanuel Lécharny wrote:

Hi!


it has been a couple of months now that I cut a version of MINA 2.2.0, 
but haven't started a vote, because I wanted to test that exception were 
properly handled when generated from the SslFilter. It took may way 
longer to check that, mainly due to external factors).


Anyway, I'm done with the test, all is nominal, so here is a formal vote 
for MINA 2.2.0.


This version comes with a complete rewrite of the SSL layer, thanks for 
Jonathan hard work !



A temporary tag has been created (it can be removed if the vote is not 
approved) :


https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4 





The newly approved Nexus has been used for the preparation of this
release and all final artifacts are stored in a staging repository:
https://repository.apache.org/content/repositories/orgapachemina-1051


The distributions are available for download on :
https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0

Let us vote :
[ ] +1 | Release MINA 2.2.0
[ ] ± | Abstain
[ ] -1 | Do *NOT*   release MINA 2.2.0



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



Re: [Vote] MINA 2.2.0 release

2022-07-16 Thread Jonathan Valliere
 mine is binding so we should be over the threshold now


On Jul 16, 2022 at 11:54:40 AM, Jeff Genender  wrote:

> I dont remember if I voted or not…but if not… here it is…
>
> Jeff
>
>
> On Jul 16, 2022, at 8:49 AM, Emmanuel Lécharny 
> wrote:
>
>
>
>
> On 16/07/2022 11:31, Christoph John wrote:
>
> > +1
>
>
> Thanks!
>
>
> > But don't know if my vote counts.
>
>
> Every vote *do* count, even if not all the votes are binding. The idea is
> that if someone casts a -1, that means there is something that requires
> some investigation.
>
>
> Typically, when I started the vote last week, you correctly asked if the
> pb you had was fixed, and we had to spend some extra time verifying that it
> was indeed the case.
>
>
>
> So please, feel free to vote :-)
>
>
> > Thanks for your investigation. I will take a closer look next week.
>
> > Cheers
>
> > Chris
>
> > Jul 16, 2022 10:32:02 Emmanuel Lécharny :
>
> >> Hi,
>
> >>
>
> >> I need one more vote at least to get the release out.
>
> >>
>
> >> I'm confident the pb Christoph had was due to some bad test, not to a
> MINA issue.
>
> >>
>
> >> Thanks !
>
> >>
>
> >> On 05/07/2022 09:38, Christoph John wrote:
>
> >>> Hi Emmanuel
>
> >>> Did you manage to fix the bug which we talked about in the mail thread
> from May regarding the M1 milestone?
>
> >>> Thanks
>
> >>> Chris
>
> >>> 04.07.2022 23:43:37 Emmanuel Lécharny :
>
> >>> Hi!
>
> 
>
> 
>
>  it has been a couple of months now that I cut a version of MINA
> 2.2.0, but haven't started a vote, because I wanted to test that exception
> were properly handled when generated from the SslFilter. It took may way
> longer to check that, mainly due to external factors).
>
> 
>
>  Anyway, I'm done with the test, all is nominal, so here is a formal
> vote for MINA 2.2.0.
>
> 
>
>  This version comes with a complete rewrite of the SSL layer, thanks
> for Jonathan hard work !
>
> 
>
> 
>
>  A temporary tag has been created (it can be removed if the vote is
> not approved) :
>
> 
>
> 
> https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4
>
> 
>
> 
>
> 
>
>  The newly approved Nexus has been used for the preparation of this
>
>  release and all final artifacts are stored in a staging repository:
>
>  https://repository.apache.org/content/repositories/orgapachemina-1051
>
> 
>
> 
>
>  The distributions are available for download on :
>
>  https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0
>
> 
>
>  Let us vote :
>
>  [ ] +1 | Release MINA 2.2.0
>
>  [ ] ± | Abstain
>
>  [ ] -1 | Do *NOT*  release MINA 2.2.0
>
> 
>
>  -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>
>  T. +33 (0)4 89 97 36 50
>
>  P. +33 (0)6 08 33 32 61
>
>  emmanuel.lecha...@busit.com https://www.busit.com/
>
> 
>
>  -
>
>  To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
>
>  For additional commands, e-mail: dev-h...@mina.apache.org
>
> >>
>
> >> --
>
> >> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>
> >> T. +33 (0)4 89 97 36 50
>
> >> P. +33 (0)6 08 33 32 61
>
> >> emmanuel.lecha...@busit.com https://www.busit.com/
>
>
> --
>
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>
> T. +33 (0)4 89 97 36 50
>
> P. +33 (0)6 08 33 32 61
>
> emmanuel.lecha...@busit.com 
> https://www.busit.com/ 
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org  dev-unsubscr...@mina.apache.org>
>
> For additional commands, e-mail: dev-h...@mina.apache.org  dev-h...@mina.apache.org>
>
>


Re: [Vote] MINA 2.2.0 release

2022-07-16 Thread Jeff Genender
I dont remember if I voted or not…but if not… here it is…

Jeff


> On Jul 16, 2022, at 8:49 AM, Emmanuel Lécharny  wrote:
> 
> 
> 
> On 16/07/2022 11:31, Christoph John wrote:
>> +1
> 
> Thanks!
> 
>> But don't know if my vote counts.
> 
> Every vote *do* count, even if not all the votes are binding. The idea is 
> that if someone casts a -1, that means there is something that requires some 
> investigation.
> 
> Typically, when I started the vote last week, you correctly asked if the pb 
> you had was fixed, and we had to spend some extra time verifying that it was 
> indeed the case.
> 
> 
> So please, feel free to vote :-)
> 
>> Thanks for your investigation. I will take a closer look next week.
>> Cheers
>> Chris
>> Jul 16, 2022 10:32:02 Emmanuel Lécharny :
>>> Hi,
>>> 
>>> I need one more vote at least to get the release out.
>>> 
>>> I'm confident the pb Christoph had was due to some bad test, not to a MINA 
>>> issue.
>>> 
>>> Thanks !
>>> 
>>> On 05/07/2022 09:38, Christoph John wrote:
 Hi Emmanuel
 Did you manage to fix the bug which we talked about in the mail thread 
 from May regarding the M1 milestone?
 Thanks
 Chris
 04.07.2022 23:43:37 Emmanuel Lécharny :
 Hi!
> 
> 
> it has been a couple of months now that I cut a version of MINA 2.2.0, 
> but haven't started a vote, because I wanted to test that exception were 
> properly handled when generated from the SslFilter. It took may way 
> longer to check that, mainly due to external factors).
> 
> Anyway, I'm done with the test, all is nominal, so here is a formal vote 
> for MINA 2.2.0.
> 
> This version comes with a complete rewrite of the SSL layer, thanks for 
> Jonathan hard work !
> 
> 
> A temporary tag has been created (it can be removed if the vote is not 
> approved) :
> 
> https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4
> 
> 
> 
> The newly approved Nexus has been used for the preparation of this
> release and all final artifacts are stored in a staging repository:
> https://repository.apache.org/content/repositories/orgapachemina-1051
> 
> 
> The distributions are available for download on :
> https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0
> 
> Let us vote :
> [ ] +1 | Release MINA 2.2.0
> [ ] ± | Abstain
> [ ] -1 | Do *NOT*  release MINA 2.2.0
> 
> -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>>> 
>>> -- 
>>> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>>> T. +33 (0)4 89 97 36 50
>>> P. +33 (0)6 08 33 32 61
>>> emmanuel.lecha...@busit.com https://www.busit.com/
> 
> -- 
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com  
> https://www.busit.com/ 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org 
> 
> For additional commands, e-mail: dev-h...@mina.apache.org 
> 


Re: [Vote] MINA 2.2.0 release

2022-07-16 Thread Emmanuel Lécharny




On 16/07/2022 11:31, Christoph John wrote:

+1


Thanks!


But don't know if my vote counts.


Every vote *do* count, even if not all the votes are binding. The idea 
is that if someone casts a -1, that means there is something that 
requires some investigation.


Typically, when I started the vote last week, you correctly asked if the 
pb you had was fixed, and we had to spend some extra time verifying that 
it was indeed the case.



So please, feel free to vote :-)


Thanks for your investigation. I will take a closer look next week.
Cheers
Chris

Jul 16, 2022 10:32:02 Emmanuel Lécharny :


Hi,

I need one more vote at least to get the release out.

I'm confident the pb Christoph had was due to some bad test, not to a MINA 
issue.

Thanks !

On 05/07/2022 09:38, Christoph John wrote:

Hi Emmanuel
Did you manage to fix the bug which we talked about in the mail thread from May 
regarding the M1 milestone?
Thanks
Chris
04.07.2022 23:43:37 Emmanuel Lécharny :
Hi!



it has been a couple of months now that I cut a version of MINA 2.2.0, but 
haven't started a vote, because I wanted to test that exception were properly 
handled when generated from the SslFilter. It took may way longer to check 
that, mainly due to external factors).

Anyway, I'm done with the test, all is nominal, so here is a formal vote for 
MINA 2.2.0.

This version comes with a complete rewrite of the SSL layer, thanks for 
Jonathan hard work !


A temporary tag has been created (it can be removed if the vote is not 
approved) :

https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4



The newly approved Nexus has been used for the preparation of this
release and all final artifacts are stored in a staging repository:
https://repository.apache.org/content/repositories/orgapachemina-1051


The distributions are available for download on :
https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0

Let us vote :
[ ] +1 | Release MINA 2.2.0
[ ] ± | Abstain
[ ] -1 | Do *NOT*   release MINA 2.2.0

-- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org


--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/


--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



Re: [Vote] MINA 2.2.0 release

2022-07-16 Thread Jonathan Valliere
 +1

CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.


On Jul 16, 2022 at 4:31:51 AM, Emmanuel Lécharny 
wrote:

> Hi,
>
> I need one more vote at least to get the release out.
>
> I'm confident the pb Christoph had was due to some bad test, not to a
> MINA issue.
>
> Thanks !
>
> On 05/07/2022 09:38, Christoph John wrote:
>
> Hi Emmanuel
>
>
> Did you manage to fix the bug which we talked about in the mail thread
> from May regarding the M1 milestone?
>
>
> Thanks
>
> Chris
>
>
> 04.07.2022 23:43:37 Emmanuel Lécharny :
>
>
> > Hi!
>
> >
>
> >
>
> > it has been a couple of months now that I cut a version of MINA 2.2.0,
> but haven't started a vote, because I wanted to test that exception were
> properly handled when generated from the SslFilter. It took may way longer
> to check that, mainly due to external factors).
>
> >
>
> > Anyway, I'm done with the test, all is nominal, so here is a formal vote
> for MINA 2.2.0.
>
> >
>
> > This version comes with a complete rewrite of the SSL layer, thanks for
> Jonathan hard work !
>
> >
>
> >
>
> > A temporary tag has been created (it can be removed if the vote is not
> approved) :
>
> >
>
> >
> https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4
>
> >
>
> >
>
> >
>
> > The newly approved Nexus has been used for the preparation of this
>
> > release and all final artifacts are stored in a staging repository:
>
> > https://repository.apache.org/content/repositories/orgapachemina-1051
>
> >
>
> >
>
> > The distributions are available for download on :
>
> > https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0
>
> >
>
> > Let us vote :
>
> > [ ] +1 | Release MINA 2.2.0
>
> > [ ] ± | Abstain
>
> > [ ] -1 | Do *NOT*   release MINA 2.2.0
>
> >
>
> > --
>
> > *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>
> > T. +33 (0)4 89 97 36 50
>
> > P. +33 (0)6 08 33 32 61
>
> > emmanuel.lecha...@busit.com https://www.busit.com/
>
> >
>
> > -
>
> > To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
>
> > For additional commands, e-mail: dev-h...@mina.apache.org
>
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>


Re: [Vote] MINA 2.2.0 release

2022-07-16 Thread Christoph John
+1
But don't know if my vote counts.
Thanks for your investigation. I will take a closer look next week.
Cheers
Chris

Jul 16, 2022 10:32:02 Emmanuel Lécharny :

> Hi,
> 
> I need one more vote at least to get the release out.
> 
> I'm confident the pb Christoph had was due to some bad test, not to a MINA 
> issue.
> 
> Thanks !
> 
> On 05/07/2022 09:38, Christoph John wrote:
>> Hi Emmanuel
>> Did you manage to fix the bug which we talked about in the mail thread from 
>> May regarding the M1 milestone?
>> Thanks
>> Chris
>> 04.07.2022 23:43:37 Emmanuel Lécharny :
>> Hi!
>>> 
>>> 
>>> it has been a couple of months now that I cut a version of MINA 2.2.0, but 
>>> haven't started a vote, because I wanted to test that exception were 
>>> properly handled when generated from the SslFilter. It took may way longer 
>>> to check that, mainly due to external factors).
>>> 
>>> Anyway, I'm done with the test, all is nominal, so here is a formal vote 
>>> for MINA 2.2.0.
>>> 
>>> This version comes with a complete rewrite of the SSL layer, thanks for 
>>> Jonathan hard work !
>>> 
>>> 
>>> A temporary tag has been created (it can be removed if the vote is not 
>>> approved) :
>>> 
>>> https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4
>>> 
>>> 
>>> 
>>> The newly approved Nexus has been used for the preparation of this
>>> release and all final artifacts are stored in a staging repository:
>>> https://repository.apache.org/content/repositories/orgapachemina-1051
>>> 
>>> 
>>> The distributions are available for download on :
>>> https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0
>>> 
>>> Let us vote :
>>> [ ] +1 | Release MINA 2.2.0
>>> [ ] ± | Abstain
>>> [ ] -1 | Do *NOT*   release MINA 2.2.0
>>> 
>>> -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>>> T. +33 (0)4 89 97 36 50
>>> P. +33 (0)6 08 33 32 61
>>> emmanuel.lecha...@busit.com https://www.busit.com/
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
>>> For additional commands, e-mail: dev-h...@mina.apache.org
> 
> -- 
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



Re: [Vote] MINA 2.2.0 release

2022-07-16 Thread Emmanuel Lécharny

Hi,

I need one more vote at least to get the release out.

I'm confident the pb Christoph had was due to some bad test, not to a 
MINA issue.


Thanks !

On 05/07/2022 09:38, Christoph John wrote:

Hi Emmanuel

Did you manage to fix the bug which we talked about in the mail thread from May 
regarding the M1 milestone?

Thanks
Chris

04.07.2022 23:43:37 Emmanuel Lécharny :


Hi!


it has been a couple of months now that I cut a version of MINA 2.2.0, but 
haven't started a vote, because I wanted to test that exception were properly 
handled when generated from the SslFilter. It took may way longer to check 
that, mainly due to external factors).

Anyway, I'm done with the test, all is nominal, so here is a formal vote for 
MINA 2.2.0.

This version comes with a complete rewrite of the SSL layer, thanks for 
Jonathan hard work !


A temporary tag has been created (it can be removed if the vote is not 
approved) :

https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4



The newly approved Nexus has been used for the preparation of this
release and all final artifacts are stored in a staging repository:
https://repository.apache.org/content/repositories/orgapachemina-1051


The distributions are available for download on :
https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0

Let us vote :
[ ] +1 | Release MINA 2.2.0
[ ] ± | Abstain
[ ] -1 | Do *NOT*   release MINA 2.2.0

--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org


--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-15 Thread Emmanuel Lécharny

Hi Christoph,

after further analysis, it appears that we have 2 countdown latch 
instances (exceptionThrownLatch) at play:

* one that is decremented in the exceptionCaught event,

[Count1]>:1]--->PKIX path validation failed: 
java.security.cert.CertPathValidatorException: signature check failed
[Count0]>:0<]---


* and the other one that is checked for the exfeption being received:

[Count:1 in assert

As you can see, the instances ID are different: b9ed2fa and 8458f04.

Seems like the handler you have added in teh chain is not owning the 
same latch that the one being checked in the assert, now to see why...



On 13/07/2022 17:43, Emmanuel Lécharny wrote:

Hi Christoph,

actually, there is a kind of race condition in your test.

I have added some logs:

     @Override
     public void exceptionCaught(NextFilter nextFilter, 
IoSession session, Throwable cause)

     throws Exception {

System.out.println("[Count:"+exceptionThrownLatch.getCount()+"]--->" 
+ cause.getMessage());

     //LOGGER.info("exceptionCaught", cause);
     exceptionThrownLatch.countDown();

System.out.println("[Count:"+exceptionThrownLatch.getCount()+"<]---"); 


     nextFilter.exceptionCaught(session, cause);
     }


which generates:

[Count:1]--->PKIX path validation failed: 
java.security.cert.CertPathValidatorException: signature check failed

[Count:0<]---

after the initiator.start() call. So the latch is properly decremented 
and the initiator.assertSslExceptionThrown() should be valid:


     public void assertSslExceptionThrown() throws Exception {

System.out.println("[Count:"+exceptionThrownLatch.getCount()+" in assert");
     boolean reachedZero = 
exceptionThrownLatch.await(TIMEOUT_SECONDS, TimeUnit.SECONDS);


     if (!reachedZero) {
     throw new AssertionError("No SSL exception thrown");
     }

and weird enough, the latch counter is  1 ! (ie, the counter is 
*not* decremented)



Here are the complete logs (check the 'Count' string):


juil. 13, 2022 5:33:12 PM 
quickfix.mina.ssl.SSLCertificateTest$TestAcceptor createConnector

INFOS: Creating acceptor: [DEFAULT]
SocketUseSSL=Y
EndTime=00:00:00
ReconnectInterval=2
SocketAcceptPort=50957
SocketTrustStore=single-session/server.truststore
NeedClientAuth=Y
EnabledProtocols=TLSv1.2
SocketAcceptHost=localhost
CipherSuites=TLS_RSA_WITH_AES_128_CBC_SHA
ConnectionType=acceptor
StartTime=00:00:00
SocketKeyStorePassword=password
SocketConnectProtocol=SOCKET
KeyStoreType=JKS
SocketKeyStore=single-session/server.keystore
SocketTrustStorePassword=password
TrustStoreType=JKS
HeartBtInt=30
[SESSION]
BeginString=FIX.4.4
SenderCompID=ALFA
TargetCompID=ZULU
DataDictionary=FIX44.xml

juil. 13, 2022 5:33:14 PM quickfix.DefaultSessionSchedule 
INFOS: [FIX.4.4:ALFA->ZULU] daily, 00:00:00-UTC - 00:00:00-UTC
<20220713-15:33:14, FIX.4.4:ALFA->ZULU, event> (Session 
FIX.4.4:ALFA->ZULU schedule is daily, 00:00:00-UTC - 00:00:00-UTC)
<20220713-15:33:14, FIX.4.4:ALFA->ZULU, event> (Created session: 
FIX.4.4:ALFA->ZULU)

juil. 13, 2022 5:33:14 PM quickfix.mina.SessionConnector startSessionTimer
INFOS: SessionTimer started
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketTcpNoDelay=true
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketSynchronousWrites=false
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketSynchronousWriteTimeout=3
juil. 13, 2022 5:33:14 PM quickfix.mina.acceptor.AbstractSocketAcceptor 
installSSL

INFOS: Installing SSL filter for 0.0.0.0/0.0.0.0:50957
juil. 13, 2022 5:33:14 PM quickfix.mina.acceptor.AbstractSocketAcceptor 
startAcceptingConnections
INFOS: Listening for connections at 0.0.0.0/0.0.0.0:50957 for session(s) 
[FIX.4.4:ALFA->ZULU]
juil. 13, 2022 5:33:14 PM 
quickfix.mina.ssl.SSLCertificateTest$TestInitiator createConnector

INFOS: Creating initiator: [DEFAULT]
SocketConnectPort=50957
SocketUseSSL=Y
EndTime=00:00:00
ReconnectInterval=2
SocketTrustStore=single-session/client.truststore
EnabledProtocols=TLSv1.2
CipherSuites=TLS_RSA_WITH_AES_128_CBC_SHA
ConnectionType=initiator
StartTime=00:00:00
SocketConnectHost=localhost
SocketKeyStorePassword=password
SocketConnectProtocol=SOCKET
KeyStoreType=JKS
SocketKeyStore=single-session/server.keystore
SocketTrustStorePassword=password
TrustStoreType=JKS
HeartBtInt=30
[SESSION]
BeginString=FIX.4.4
SenderCompID=ZULU
TargetCompID=ALFA
DataDictionary=FIX44.xml

juil. 13, 2022 5:33:14 PM quickfix.DefaultSessionSchedule 
INFOS: [FIX.4.4:ZULU->ALFA] daily, 00:00:00-UTC - 00:00:00-UTC
<20220713-15:33:14, FIX.4.4:ZULU->ALFA, event> (Session 
FIX.4.4:ZULU->ALFA schedule is daily, 00:00:00-UTC - 00:00:00-UTC)
<20220713-15:33:14, FIX.4.4:ZULU->ALFA, eve

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-13 Thread Emmanuel Lécharny

Hi Christoph,

actually, there is a kind of race condition in your test.

I have added some logs:

@Override
public void exceptionCaught(NextFilter nextFilter, 
IoSession session, Throwable cause)

throws Exception {

System.out.println("[Count:"+exceptionThrownLatch.getCount()+"]--->" 
+ cause.getMessage());

//LOGGER.info("exceptionCaught", cause);
exceptionThrownLatch.countDown();

System.out.println("[Count:"+exceptionThrownLatch.getCount()+"<]---");
nextFilter.exceptionCaught(session, cause);
}


which generates:

[Count:1]--->PKIX path validation failed: 
java.security.cert.CertPathValidatorException: signature check failed

[Count:0<]---

after the initiator.start() call. So the latch is properly decremented 
and the initiator.assertSslExceptionThrown() should be valid:


public void assertSslExceptionThrown() throws Exception {

System.out.println("[Count:"+exceptionThrownLatch.getCount()+" in assert");
boolean reachedZero = 
exceptionThrownLatch.await(TIMEOUT_SECONDS, TimeUnit.SECONDS);


if (!reachedZero) {
throw new AssertionError("No SSL exception thrown");
}

and weird enough, the latch counter is  1 ! (ie, the counter is 
*not* decremented)



Here are the complete logs (check the 'Count' string):


juil. 13, 2022 5:33:12 PM 
quickfix.mina.ssl.SSLCertificateTest$TestAcceptor createConnector

INFOS: Creating acceptor: [DEFAULT]
SocketUseSSL=Y
EndTime=00:00:00
ReconnectInterval=2
SocketAcceptPort=50957
SocketTrustStore=single-session/server.truststore
NeedClientAuth=Y
EnabledProtocols=TLSv1.2
SocketAcceptHost=localhost
CipherSuites=TLS_RSA_WITH_AES_128_CBC_SHA
ConnectionType=acceptor
StartTime=00:00:00
SocketKeyStorePassword=password
SocketConnectProtocol=SOCKET
KeyStoreType=JKS
SocketKeyStore=single-session/server.keystore
SocketTrustStorePassword=password
TrustStoreType=JKS
HeartBtInt=30
[SESSION]
BeginString=FIX.4.4
SenderCompID=ALFA
TargetCompID=ZULU
DataDictionary=FIX44.xml

juil. 13, 2022 5:33:14 PM quickfix.DefaultSessionSchedule 
INFOS: [FIX.4.4:ALFA->ZULU] daily, 00:00:00-UTC - 00:00:00-UTC
<20220713-15:33:14, FIX.4.4:ALFA->ZULU, event> (Session 
FIX.4.4:ALFA->ZULU schedule is daily, 00:00:00-UTC - 00:00:00-UTC)
<20220713-15:33:14, FIX.4.4:ALFA->ZULU, event> (Created session: 
FIX.4.4:ALFA->ZULU)

juil. 13, 2022 5:33:14 PM quickfix.mina.SessionConnector startSessionTimer
INFOS: SessionTimer started
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketTcpNoDelay=true
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketSynchronousWrites=false
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketSynchronousWriteTimeout=3
juil. 13, 2022 5:33:14 PM quickfix.mina.acceptor.AbstractSocketAcceptor 
installSSL

INFOS: Installing SSL filter for 0.0.0.0/0.0.0.0:50957
juil. 13, 2022 5:33:14 PM quickfix.mina.acceptor.AbstractSocketAcceptor 
startAcceptingConnections
INFOS: Listening for connections at 0.0.0.0/0.0.0.0:50957 for session(s) 
[FIX.4.4:ALFA->ZULU]
juil. 13, 2022 5:33:14 PM 
quickfix.mina.ssl.SSLCertificateTest$TestInitiator createConnector

INFOS: Creating initiator: [DEFAULT]
SocketConnectPort=50957
SocketUseSSL=Y
EndTime=00:00:00
ReconnectInterval=2
SocketTrustStore=single-session/client.truststore
EnabledProtocols=TLSv1.2
CipherSuites=TLS_RSA_WITH_AES_128_CBC_SHA
ConnectionType=initiator
StartTime=00:00:00
SocketConnectHost=localhost
SocketKeyStorePassword=password
SocketConnectProtocol=SOCKET
KeyStoreType=JKS
SocketKeyStore=single-session/server.keystore
SocketTrustStorePassword=password
TrustStoreType=JKS
HeartBtInt=30
[SESSION]
BeginString=FIX.4.4
SenderCompID=ZULU
TargetCompID=ALFA
DataDictionary=FIX44.xml

juil. 13, 2022 5:33:14 PM quickfix.DefaultSessionSchedule 
INFOS: [FIX.4.4:ZULU->ALFA] daily, 00:00:00-UTC - 00:00:00-UTC
<20220713-15:33:14, FIX.4.4:ZULU->ALFA, event> (Session 
FIX.4.4:ZULU->ALFA schedule is daily, 00:00:00-UTC - 00:00:00-UTC)
<20220713-15:33:14, FIX.4.4:ZULU->ALFA, event> (Created session: 
FIX.4.4:ZULU->ALFA)

juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketTcpNoDelay=true
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketSynchronousWrites=false
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketSynchronousWriteTimeout=3
<20220713-15:33:14, FIX.4.4:ZULU->ALFA, event> (Configured socket 
addresses for session: [localhost/127.0.0.1:50957])

juil. 13, 2022 5:33:14 PM quickfix.mina.SessionConnector startSessionTimer
INFOS: SessionTimer started
[Count:1 in assert
juil. 13, 2022 5:33:14 PM quickfix.mina.acceptor.AcceptorIoHandler 
sess

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-13 Thread Emmanuel Lécharny




On 13/07/2022 09:37, Christoph John wrote:

Hi Emmanuel,

thanks for your analysis. The filter that should catch the exception is added 
as last part in the chain. Could it be that the chain is not fully iterated 
somehow? Just guessing, I don't have enough MINA experience to make an educated 
guess. :)


This is what I'm going to check :-)

Stay tuned !


Cheers
Chris

Jul 13, 2022 06:38:00 Emmanuel Lécharny :


Here are some of my current findings.

For the (failing) test shouldFailWhenUsingBadClientCertificate, here are the 
traces we get:

juil. 13, 2022 6:28:42 AM org.apache.mina.filter.ssl.SSLHandlerG0 execute_task
GRAVE: SSLHandlerG0@ae273e3[mode=server, connected=false] task() - storing 
error {}
javax.net.ssl.SSLHandshakeException: PKIX path validation failed: 
java.security.cert.CertPathValidatorException: signature check failed
     at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
     at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:349)
     at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
     at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:287)
     at 
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkClientCerts(CertificateMessage.java:700)
     at 
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:411)
     at 
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:375)
     at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
     at 
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
     at 
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074)
     at 
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
     at java.base/java.security.AccessController.doPrivileged(Native Method)
     at 
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008)
     at 
org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
     at 
org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)
     at org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
     at org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
     at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
     at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
     at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
     at 
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
     at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
     at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
     at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
     at 
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
     at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
     at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:643)
     at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
     at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
     at 
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1224)
     at 
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1213)
     at 
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
     at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
     at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
     at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
     at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: sun.security.validator.ValidatorException: PKIX path validation 
failed: java.security.cert.CertPathValidatorException: signature check failed
     at 
java.base/sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:369)
     at 
java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:275)
     at java.base/sun.security.validator.Validator.validate(Validator.java:264)
     at 
java.base/sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:313)
  

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-13 Thread Christoph John
Hi Emmanuel,

thanks for your analysis. The filter that should catch the exception is added 
as last part in the chain. Could it be that the chain is not fully iterated 
somehow? Just guessing, I don't have enough MINA experience to make an educated 
guess. :)

Cheers
Chris

Jul 13, 2022 06:38:00 Emmanuel Lécharny :

> Here are some of my current findings.
>
> For the (failing) test shouldFailWhenUsingBadClientCertificate, here are the 
> traces we get:
>
> juil. 13, 2022 6:28:42 AM org.apache.mina.filter.ssl.SSLHandlerG0 execute_task
> GRAVE: SSLHandlerG0@ae273e3[mode=server, connected=false] task() - storing 
> error {}
> javax.net.ssl.SSLHandshakeException: PKIX path validation failed: 
> java.security.cert.CertPathValidatorException: signature check failed
>     at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
>     at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:349)
>     at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
>     at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:287)
>     at 
> java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkClientCerts(CertificateMessage.java:700)
>     at 
> java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:411)
>     at 
> java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:375)
>     at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
>     at 
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
>     at 
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074)
>     at 
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
>     at java.base/java.security.AccessController.doPrivileged(Native Method)
>     at 
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008)
>     at 
> org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
>     at 
> org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)
>     at org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
>     at 
> org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
>     at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
>     at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
>     at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
>     at 
> org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
>     at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
>     at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
>     at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
>     at 
> org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
>     at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
>     at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:643)
>     at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
>     at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
>     at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1224)
>     at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1213)
>     at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
>     at 
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
>     at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>     at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>     at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: sun.security.validator.ValidatorException: PKIX path validation 
> failed: java.security.cert.CertPathValidatorException: signature check failed
>     at 
> java.base/sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:369)
>     at 
> java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:275)
>     at java.base/sun.security.validator.Validator.validate(Validator.java:264)
>     at 
> java.base/sun.security.ssl.X509TrustManagerImpl.validate(X509

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-12 Thread Emmanuel Lécharny

Here are some of my current findings.

For the (failing) test shouldFailWhenUsingBadClientCertificate, here are 
the traces we get:


juil. 13, 2022 6:28:42 AM org.apache.mina.filter.ssl.SSLHandlerG0 
execute_task
GRAVE: SSLHandlerG0@ae273e3[mode=server, connected=false] task() - 
storing error {}
javax.net.ssl.SSLHandshakeException: PKIX path validation failed: 
java.security.cert.CertPathValidatorException: signature check failed

at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
	at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:349)
	at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
	at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:287)
	at 
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkClientCerts(CertificateMessage.java:700)
	at 
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:411)
	at 
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:375)

at 
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
	at 
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
	at 
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074)
	at 
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)

at java.base/java.security.AccessController.doPrivileged(Native Method)
	at 
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008)
	at 
org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
	at 
org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)

at 
org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
at 
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
	at 
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
	at 
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:643)
	at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
	at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
	at 
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1224)
	at 
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1213)
	at 
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
	at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
	at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)

at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: sun.security.validator.ValidatorException: PKIX path 
validation failed: java.security.cert.CertPathValidatorException: 
signature check failed
	at 
java.base/sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:369)
	at 
java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:275)

at 
java.base/sun.security.validator.Validator.validate(Validator.java:264)
	at 
java.base/sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:313)
	at 
java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:233)
	at 
java.base/sun.security.ssl.X509TrustManagerImpl.checkClientTrusted(X509TrustManagerImpl.java:104)
	at 
quickfix.mina.ssl.X509TrustManagerWrapper.checkClientTrusted(X509TrustManagerWrapper.java:60)
	at 
java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkClientTrusted(SSLContextImpl.java:1517)
	at 
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkClientCerts(CertificateMessage.java:6

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-12 Thread Emmanuel Lécharny

Never mind, I'm set up now, and in debug mode. All is good !

On 13/07/2022 00:47, Emmanuel Lécharny wrote:

Hi Christoph,

I'm trying to  ran the failing tests on my machine (eclipse with Java 8 
and Java 11), and I'll probably need some assistance.



I'm using the chrjohn-mina-2.2.0 branch. It seems that the generated 
code is not stored at the proper place.


Any clue?


On 09/07/2022 11:49, Christoph John wrote:
Thanks. Anything I can do to assist? Although I might only find time 
the week after next because am currently on vacation.


Jul 9, 2022 09:00:21 Emmanuel Lécharny :

I do think we need to have a look at it (and I may find some time to 
do it too, as I'm in vacation in the coming week)


However, I think we should get this 2.0 out. Ther eis no problem in 
releasing a fix if needed.


Thanks !

On 09/07/2022 07:17, Jonathan Valliere wrote:

Sooo… do I need to look into this or was this resolved?
On Fri, Jul 8, 2022 at 11:51 PM Emmanuel Lécharny 
mailto:elecha...@gmail.com>> wrote:

 The changes I did were to ensure that any ouutbound data are sent
 when a
 TLS erroroccurs, because the Alert must be sent no matter what. 
This is

 critical for a client to know what is the cause of the failure
 (typically when a bad certificate is provided - expired, revoked,
 etc -):
 https://datatracker.ietf.org/doc/html/rfc5246#section-7.2
 
 I also checked that in this case an exception is propagated up 
to the

 IoHandler for teh server to be informed about the situuation.

 On 06/07/2022 12:42, Jonathan Valliere wrote:
  >   What test are you trying?  Emmanuel made changes from the
 original design
  > to cause it to throw on the filter.  My original design 
threw on

 the filter
  > but only during a subsequent read or write action thereby
 enforcing strong
  > concurrency within the pipeline.
  >
  > On Jul 6, 2022 at 3:53:57 AM, Christoph John
  > mailto:christoph.j...@macd.com>.invalid> wrote:
  >
  >> Ok, the tests in QuickFIX/J which expect the exception to be
 caught in a
  >> filter still don't work.
  >> I recall that you also did some changes in other Apache 
projects

 to make
  >> it work with MINA 2.2.0. Could it be that I also need to adapt
 something in
  >> this regard?
  >>
  >> Thanks
  >> Chris
  >>
  >> Jul 5, 2022 18:47:09 Emmanuel Lécharny mailto:elecha...@gmail.com>>:
  >>
  >> I have tested that the exception gets propagated before
 launching the vote
  >> to be clear :-)
  >>
  >>
  >> On 05/07/2022 18:17, Christoph John wrote:
  >>
  >>> Sorry, no. The last message regarding this was:
  >>
  >>>
  >>
  >>> --snip-
  >>
  >>>
  >>
  >>> 11.04.2022 09:37:30 Emmanuel Lécharny mailto:elecha...@gmail.com>>:
  >>
  >>> Hi Christophe,
  >>
  >>> sorry, my late mail was off base.
  >>
  >>> The pb here is that the SSLEngine excpeiton is not propagated
 to the
  >> handler, when it should.
  >>
  >>> My guess is that we have some missing call somewhere in the
 stack. I'm
  >> going to check that out.
  >>
  >>> On 11/04/2022 00:15, Christoph John wrote:
  >>
   Hi,
  >>
   thanks Jonathan and Emmanuel for working on this!
  >>
   I tried to integrate this into QuickFIX/J and it compiles
 successfully.
  >> However there are some tests failing that expect an Exception.
 For example
  >> we have
  >>
  
  >>
 
https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54 

 
 


  >>
   Up to now it was tried to get the Exception via a filter in
 the chain.
  >> This no longer seems to work but I think I can see the error
 getting thrown
  >> in the log:
  >>
   SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false]
 task() -
  >> storing error {}
  >>
   javax.net.ssl.SSLHandshakeException: No available
 authentication scheme
  >>
        at
  >> 
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)

  >>
        at
  >> 
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)

  >>
        at
  >>
 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358) 


  >>
        at
  >>
 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314) 


  >>
        at
  >>
 
java.base/sun.security.ssl.TransportContext.

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-12 Thread Emmanuel Lécharny

Hi Christoph,

I'm trying to  ran the failing tests on my machine (eclipse with Java 8 
and Java 11), and I'll probably need some assistance.



I'm using the chrjohn-mina-2.2.0 branch. It seems that the generated 
code is not stored at the proper place.


Any clue?


On 09/07/2022 11:49, Christoph John wrote:

Thanks. Anything I can do to assist? Although I might only find time the week 
after next because am currently on vacation.

Jul 9, 2022 09:00:21 Emmanuel Lécharny :


I do think we need to have a look at it (and I may find some time to do it too, 
as I'm in vacation in the coming week)

However, I think we should get this 2.0 out. Ther eis no problem in releasing a 
fix if needed.

Thanks !

On 09/07/2022 07:17, Jonathan Valliere wrote:

Sooo… do I need to look into this or was this resolved?
On Fri, Jul 8, 2022 at 11:51 PM Emmanuel Lécharny mailto:elecha...@gmail.com>> wrote:
     The changes I did were to ensure that any ouutbound data are sent
     when a
     TLS erroroccurs, because the Alert must be sent no matter what. This is
     critical for a client to know what is the cause of the failure
     (typically when a bad certificate is provided - expired, revoked,
     etc -):
     https://datatracker.ietf.org/doc/html/rfc5246#section-7.2
     
     I also checked that in this case an exception is propagated up to the
     IoHandler for teh server to be informed about the situuation.

     On 06/07/2022 12:42, Jonathan Valliere wrote:
  >   What test are you trying?  Emmanuel made changes from the
     original design
  > to cause it to throw on the filter.  My original design threw on
     the filter
  > but only during a subsequent read or write action thereby
     enforcing strong
  > concurrency within the pipeline.
  >
  > On Jul 6, 2022 at 3:53:57 AM, Christoph John
  > mailto:christoph.j...@macd.com>.invalid> wrote:
  >
  >> Ok, the tests in QuickFIX/J which expect the exception to be
     caught in a
  >> filter still don't work.
  >> I recall that you also did some changes in other Apache projects
     to make
  >> it work with MINA 2.2.0. Could it be that I also need to adapt
     something in
  >> this regard?
  >>
  >> Thanks
  >> Chris
  >>
  >> Jul 5, 2022 18:47:09 Emmanuel Lécharny mailto:elecha...@gmail.com>>:
  >>
  >> I have tested that the exception gets propagated before
     launching the vote
  >> to be clear :-)
  >>
  >>
  >> On 05/07/2022 18:17, Christoph John wrote:
  >>
  >>> Sorry, no. The last message regarding this was:
  >>
  >>>
  >>
  >>> --snip-
  >>
  >>>
  >>
  >>> 11.04.2022 09:37:30 Emmanuel Lécharny mailto:elecha...@gmail.com>>:
  >>
  >>> Hi Christophe,
  >>
  >>> sorry, my late mail was off base.
  >>
  >>> The pb here is that the SSLEngine excpeiton is not propagated
     to the
  >> handler, when it should.
  >>
  >>> My guess is that we have some missing call somewhere in the
     stack. I'm
  >> going to check that out.
  >>
  >>> On 11/04/2022 00:15, Christoph John wrote:
  >>
   Hi,
  >>
   thanks Jonathan and Emmanuel for working on this!
  >>
   I tried to integrate this into QuickFIX/J and it compiles
     successfully.
  >> However there are some tests failing that expect an Exception.
     For example
  >> we have
  >>
  
  >>
     
https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
     

  >>
   Up to now it was tried to get the Exception via a filter in
     the chain.
  >> This no longer seems to work but I think I can see the error
     getting thrown
  >> in the log:
  >>
   SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false]
     task() -
  >> storing error {}
  >>
   javax.net.ssl.SSLHandshakeException: No available
     authentication scheme
  >>
        at
  >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
  >>
        at
  >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
  >>
        at
  >>
     
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
  >>
        at
  >>
     
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
  >>
        at
  >>
     
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
  >>
        at
  >>
     
java.base/sun.security.ssl.CertificateMessage$T13Certificat

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-11 Thread Emmanuel Lécharny

Hi Christoph,

I think we should have the exact same tests in MINA. Poerting them 
should not take too long.



On 06/07/2022 22:51, Christoph John wrote:

Hi
You could see the failing tests here: 
https://github.com/quickfix-j/quickfixj/runs/7201285514?check_suite_focus=true
Basically these are tests that should fail when using a bad certificate.
As an example here is one test that registers a filter that should get an 
exception but it doesn't: 
https://github.com/quickfix-j/quickfixj/blob/da21d92c32c37265ee1d4e20519832fb13a26d05/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L67

Thanks in advance and cheers
Chris

Jul 6, 2022 12:42:15 Jonathan Valliere :


What test are you trying?  Emmanuel made changes from the original design
to cause it to throw on the filter.  My original design threw on the filter
but only during a subsequent read or write action thereby enforcing strong
concurrency within the pipeline.

On Jul 6, 2022 at 3:53:57 AM, Christoph John
 wrote:


Ok, the tests in QuickFIX/J which expect the exception to be caught in a
filter still don't work.
I recall that you also did some changes in other Apache projects to make
it work with MINA 2.2.0. Could it be that I also need to adapt something in
this regard?

Thanks
Chris

Jul 5, 2022 18:47:09 Emmanuel Lécharny :

I have tested that the exception gets propagated before launching the vote
to be clear :-)


On 05/07/2022 18:17, Christoph John wrote:


Sorry, no. The last message regarding this was:







--snip-







11.04.2022 09:37:30 Emmanuel Lécharny :



Hi Christophe,



sorry, my late mail was off base.



The pb here is that the SSLEngine excpeiton is not propagated to the

handler, when it should.


My guess is that we have some missing call somewhere in the stack. I'm

going to check that out.


On 11/04/2022 00:15, Christoph John wrote:



Hi,



thanks Jonathan and Emmanuel for working on this!



I tried to integrate this into QuickFIX/J and it compiles successfully.

However there are some tests failing that expect an Exception. For example
we have




https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54


Up to now it was tried to get the Exception via a filter in the chain.

This no longer seems to work but I think I can see the error getting thrown
in the log:


SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false] task() -

storing error {}


javax.net.ssl.SSLHandshakeException: No available authentication scheme



     at

java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)


     at

java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)


     at

java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)


     at

java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)


     at

java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)


     at

java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)


     at

java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)


     at

java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)


     at

java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)


     at

java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1182)


     at

java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:840)


     at

java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:801)


     at

java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)


     at

java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)


     at

java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1277)


     at

java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1264)


     at

java.base/java.security.AccessController.doPrivileged(AccessController.java:712)


     at

java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1209)


     at

org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)


     at

org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)


     at

org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)


     at

org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)


     at

org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)


     at

org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)


     at

org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageRec

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-09 Thread Christoph John
Thanks. Anything I can do to assist? Although I might only find time the week 
after next because am currently on vacation.

Jul 9, 2022 09:00:21 Emmanuel Lécharny :

> I do think we need to have a look at it (and I may find some time to do it 
> too, as I'm in vacation in the coming week)
> 
> However, I think we should get this 2.0 out. Ther eis no problem in releasing 
> a fix if needed.
> 
> Thanks !
> 
> On 09/07/2022 07:17, Jonathan Valliere wrote:
>> Sooo… do I need to look into this or was this resolved?
>> On Fri, Jul 8, 2022 at 11:51 PM Emmanuel Lécharny > > wrote:
>>     The changes I did were to ensure that any ouutbound data are sent
>>     when a
>>     TLS erroroccurs, because the Alert must be sent no matter what. This is
>>     critical for a client to know what is the cause of the failure
>>     (typically when a bad certificate is provided - expired, revoked,
>>     etc -):
>>     https://datatracker.ietf.org/doc/html/rfc5246#section-7.2
>>     
>>     I also checked that in this case an exception is propagated up to the
>>     IoHandler for teh server to be informed about the situuation.
>> 
>>     On 06/07/2022 12:42, Jonathan Valliere wrote:
>>  >   What test are you trying?  Emmanuel made changes from the
>>     original design
>>  > to cause it to throw on the filter.  My original design threw on
>>     the filter
>>  > but only during a subsequent read or write action thereby
>>     enforcing strong
>>  > concurrency within the pipeline.
>>  >
>>  > On Jul 6, 2022 at 3:53:57 AM, Christoph John
>>  > >     .invalid> wrote:
>>  >
>>  >> Ok, the tests in QuickFIX/J which expect the exception to be
>>     caught in a
>>  >> filter still don't work.
>>  >> I recall that you also did some changes in other Apache projects
>>     to make
>>  >> it work with MINA 2.2.0. Could it be that I also need to adapt
>>     something in
>>  >> this regard?
>>  >>
>>  >> Thanks
>>  >> Chris
>>  >>
>>  >> Jul 5, 2022 18:47:09 Emmanuel Lécharny >     >:
>>  >>
>>  >> I have tested that the exception gets propagated before
>>     launching the vote
>>  >> to be clear :-)
>>  >>
>>  >>
>>  >> On 05/07/2022 18:17, Christoph John wrote:
>>  >>
>>  >>> Sorry, no. The last message regarding this was:
>>  >>
>>  >>>
>>  >>
>>  >>> --snip-
>>  >>
>>  >>>
>>  >>
>>  >>> 11.04.2022 09:37:30 Emmanuel Lécharny >     >:
>>  >>
>>  >>> Hi Christophe,
>>  >>
>>  >>> sorry, my late mail was off base.
>>  >>
>>  >>> The pb here is that the SSLEngine excpeiton is not propagated
>>     to the
>>  >> handler, when it should.
>>  >>
>>  >>> My guess is that we have some missing call somewhere in the
>>     stack. I'm
>>  >> going to check that out.
>>  >>
>>  >>> On 11/04/2022 00:15, Christoph John wrote:
>>  >>
>>   Hi,
>>  >>
>>   thanks Jonathan and Emmanuel for working on this!
>>  >>
>>   I tried to integrate this into QuickFIX/J and it compiles
>>     successfully.
>>  >> However there are some tests failing that expect an Exception.
>>     For example
>>  >> we have
>>  >>
>>  
>>  >>
>>     
>> https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
>>     
>> 
>>  >>
>>   Up to now it was tried to get the Exception via a filter in
>>     the chain.
>>  >> This no longer seems to work but I think I can see the error
>>     getting thrown
>>  >> in the log:
>>  >>
>>   SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false]
>>     task() -
>>  >> storing error {}
>>  >>
>>   javax.net.ssl.SSLHandshakeException: No available
>>     authentication scheme
>>  >>
>>        at
>>  >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
>>  >>
>>        at
>>  >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>>  >>
>>        at
>>  >>
>>     
>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
>>  >>
>>        at
>>  >>
>>     
>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>>  >>
>>        at
>>  >>
>>     
>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
>>  >>
>>        at
>>  >>
>>     
>> java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onPro

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-09 Thread Emmanuel Lécharny
I do think we need to have a look at it (and I may find some time to do 
it too, as I'm in vacation in the coming week)


However, I think we should get this 2.0 out. Ther eis no problem in 
releasing a fix if needed.


Thanks !

On 09/07/2022 07:17, Jonathan Valliere wrote:

Sooo… do I need to look into this or was this resolved?

On Fri, Jul 8, 2022 at 11:51 PM Emmanuel Lécharny > wrote:


The changes I did were to ensure that any ouutbound data are sent
when a
TLS erroroccurs, because the Alert must be sent no matter what. This is
critical for a client to know what is the cause of the failure
(typically when a bad certificate is provided - expired, revoked,
etc -):
https://datatracker.ietf.org/doc/html/rfc5246#section-7.2


I also checked that in this case an exception is propagated up to the
IoHandler for teh server to be informed about the situuation.


On 06/07/2022 12:42, Jonathan Valliere wrote:
 >   What test are you trying?  Emmanuel made changes from the
original design
 > to cause it to throw on the filter.  My original design threw on
the filter
 > but only during a subsequent read or write action thereby
enforcing strong
 > concurrency within the pipeline.
 >
 > On Jul 6, 2022 at 3:53:57 AM, Christoph John
 > mailto:christoph.j...@macd.com>.invalid> wrote:
 >
 >> Ok, the tests in QuickFIX/J which expect the exception to be
caught in a
 >> filter still don't work.
 >> I recall that you also did some changes in other Apache projects
to make
 >> it work with MINA 2.2.0. Could it be that I also need to adapt
something in
 >> this regard?
 >>
 >> Thanks
 >> Chris
 >>
 >> Jul 5, 2022 18:47:09 Emmanuel Lécharny mailto:elecha...@gmail.com>>:
 >>
 >> I have tested that the exception gets propagated before
launching the vote
 >> to be clear :-)
 >>
 >>
 >> On 05/07/2022 18:17, Christoph John wrote:
 >>
 >>> Sorry, no. The last message regarding this was:
 >>
 >>>
 >>
 >>> --snip-
 >>
 >>>
 >>
 >>> 11.04.2022 09:37:30 Emmanuel Lécharny mailto:elecha...@gmail.com>>:
 >>
 >>> Hi Christophe,
 >>
 >>> sorry, my late mail was off base.
 >>
 >>> The pb here is that the SSLEngine excpeiton is not propagated
to the
 >> handler, when it should.
 >>
 >>> My guess is that we have some missing call somewhere in the
stack. I'm
 >> going to check that out.
 >>
 >>> On 11/04/2022 00:15, Christoph John wrote:
 >>
  Hi,
 >>
  thanks Jonathan and Emmanuel for working on this!
 >>
  I tried to integrate this into QuickFIX/J and it compiles
successfully.
 >> However there are some tests failing that expect an Exception.
For example
 >> we have
 >>
 
 >>

https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54


 >>
  Up to now it was tried to get the Exception via a filter in
the chain.
 >> This no longer seems to work but I think I can see the error
getting thrown
 >> in the log:
 >>
  SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false]
task() -
 >> storing error {}
 >>
  javax.net.ssl.SSLHandshakeException: No available
authentication scheme
 >>
       at
 >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
 >>
       at
 >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
 >>
       at
 >>
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
 >>
       at
 >>
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
 >>
       at
 >>
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
 >>
       at
 >>

java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)
 >>
       at
 >>

java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)
 >>
       at
 >>
java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
 >>
       at
 >>

java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)
 >>
       at
 >>

java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1182)
 >>
 

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-08 Thread Jonathan Valliere
Sooo… do I need to look into this or was this resolved?

On Fri, Jul 8, 2022 at 11:51 PM Emmanuel Lécharny 
wrote:

> The changes I did were to ensure that any ouutbound data are sent when a
> TLS erroroccurs, because the Alert must be sent no matter what. This is
> critical for a client to know what is the cause of the failure
> (typically when a bad certificate is provided - expired, revoked, etc -):
> https://datatracker.ietf.org/doc/html/rfc5246#section-7.2
>
> I also checked that in this case an exception is propagated up to the
> IoHandler for teh server to be informed about the situuation.
>
>
> On 06/07/2022 12:42, Jonathan Valliere wrote:
> >   What test are you trying?  Emmanuel made changes from the original
> design
> > to cause it to throw on the filter.  My original design threw on the
> filter
> > but only during a subsequent read or write action thereby enforcing
> strong
> > concurrency within the pipeline.
> >
> > On Jul 6, 2022 at 3:53:57 AM, Christoph John
> >  wrote:
> >
> >> Ok, the tests in QuickFIX/J which expect the exception to be caught in a
> >> filter still don't work.
> >> I recall that you also did some changes in other Apache projects to make
> >> it work with MINA 2.2.0. Could it be that I also need to adapt
> something in
> >> this regard?
> >>
> >> Thanks
> >> Chris
> >>
> >> Jul 5, 2022 18:47:09 Emmanuel Lécharny :
> >>
> >> I have tested that the exception gets propagated before launching the
> vote
> >> to be clear :-)
> >>
> >>
> >> On 05/07/2022 18:17, Christoph John wrote:
> >>
> >>> Sorry, no. The last message regarding this was:
> >>
> >>>
> >>
> >>> --snip-
> >>
> >>>
> >>
> >>> 11.04.2022 09:37:30 Emmanuel Lécharny :
> >>
> >>> Hi Christophe,
> >>
> >>> sorry, my late mail was off base.
> >>
> >>> The pb here is that the SSLEngine excpeiton is not propagated to the
> >> handler, when it should.
> >>
> >>> My guess is that we have some missing call somewhere in the stack. I'm
> >> going to check that out.
> >>
> >>> On 11/04/2022 00:15, Christoph John wrote:
> >>
>  Hi,
> >>
>  thanks Jonathan and Emmanuel for working on this!
> >>
>  I tried to integrate this into QuickFIX/J and it compiles
> successfully.
> >> However there are some tests failing that expect an Exception. For
> example
> >> we have
> >>
> 
> >>
> https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
> >>
>  Up to now it was tried to get the Exception via a filter in the chain.
> >> This no longer seems to work but I think I can see the error getting
> thrown
> >> in the log:
> >>
>  SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false] task() -
> >> storing error {}
> >>
>  javax.net.ssl.SSLHandshakeException: No available authentication
> scheme
> >>
>   at
> >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
> >>
>   at
> >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
> >>
>   at
> >>
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
> >>
>   at
> >>
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
> >>
>   at
> >>
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
> >>
>   at
> >>
> java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)
> >>
>   at
> >>
> java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)
> >>
>   at
> >> java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
> >>
>   at
> >>
> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)
> >>
>   at
> >>
> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1182)
> >>
>   at
> >>
> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:840)
> >>
>   at
> >>
> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:801)
> >>
>   at
> >> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
> >>
>   at
> >>
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
> >>
>   at
> >>
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1277)
> >>
>   at
> >>
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1264)
> >>
>   at
> >>
> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
> >>
>   at
> >>
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1209)
> >>
>   at
> >>
> org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
>

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-08 Thread Emmanuel Lécharny
The changes I did were to ensure that any ouutbound data are sent when a 
TLS erroroccurs, because the Alert must be sent no matter what. This is 
critical for a client to know what is the cause of the failure 
(typically when a bad certificate is provided - expired, revoked, etc -):

https://datatracker.ietf.org/doc/html/rfc5246#section-7.2

I also checked that in this case an exception is propagated up to the 
IoHandler for teh server to be informed about the situuation.



On 06/07/2022 12:42, Jonathan Valliere wrote:

  What test are you trying?  Emmanuel made changes from the original design
to cause it to throw on the filter.  My original design threw on the filter
but only during a subsequent read or write action thereby enforcing strong
concurrency within the pipeline.

On Jul 6, 2022 at 3:53:57 AM, Christoph John
 wrote:


Ok, the tests in QuickFIX/J which expect the exception to be caught in a
filter still don't work.
I recall that you also did some changes in other Apache projects to make
it work with MINA 2.2.0. Could it be that I also need to adapt something in
this regard?

Thanks
Chris

Jul 5, 2022 18:47:09 Emmanuel Lécharny :

I have tested that the exception gets propagated before launching the vote
to be clear :-)


On 05/07/2022 18:17, Christoph John wrote:


Sorry, no. The last message regarding this was:







--snip-







11.04.2022 09:37:30 Emmanuel Lécharny :



Hi Christophe,



sorry, my late mail was off base.



The pb here is that the SSLEngine excpeiton is not propagated to the

handler, when it should.


My guess is that we have some missing call somewhere in the stack. I'm

going to check that out.


On 11/04/2022 00:15, Christoph John wrote:



Hi,



thanks Jonathan and Emmanuel for working on this!



I tried to integrate this into QuickFIX/J and it compiles successfully.

However there are some tests failing that expect an Exception. For example
we have




https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54


Up to now it was tried to get the Exception via a filter in the chain.

This no longer seems to work but I think I can see the error getting thrown
in the log:


SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false] task() -

storing error {}


javax.net.ssl.SSLHandshakeException: No available authentication scheme



 at

java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)


 at

java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)


 at

java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)


 at

java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)


 at

java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)


 at

java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)


 at

java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)


 at

java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)


 at

java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)


 at

java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1182)


 at

java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:840)


 at

java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:801)


 at

java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)


 at

java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)


 at

java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1277)


 at

java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1264)


 at

java.base/java.security.AccessController.doPrivileged(AccessController.java:712)


 at

java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1209)


 at

org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)


 at

org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)


 at

org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)


 at

org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)


 at

org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)


 at

org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)


 at

org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)


 at

org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)


 at

org.apache.

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-06 Thread Christoph John
Hi
You could see the failing tests here: 
https://github.com/quickfix-j/quickfixj/runs/7201285514?check_suite_focus=true
Basically these are tests that should fail when using a bad certificate.
As an example here is one test that registers a filter that should get an 
exception but it doesn't: 
https://github.com/quickfix-j/quickfixj/blob/da21d92c32c37265ee1d4e20519832fb13a26d05/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L67

Thanks in advance and cheers
Chris

Jul 6, 2022 12:42:15 Jonathan Valliere :

> What test are you trying?  Emmanuel made changes from the original design
> to cause it to throw on the filter.  My original design threw on the filter
> but only during a subsequent read or write action thereby enforcing strong
> concurrency within the pipeline.
> 
> On Jul 6, 2022 at 3:53:57 AM, Christoph John
>  wrote:
> 
>> Ok, the tests in QuickFIX/J which expect the exception to be caught in a
>> filter still don't work.
>> I recall that you also did some changes in other Apache projects to make
>> it work with MINA 2.2.0. Could it be that I also need to adapt something in
>> this regard?
>> 
>> Thanks
>> Chris
>> 
>> Jul 5, 2022 18:47:09 Emmanuel Lécharny :
>> 
>> I have tested that the exception gets propagated before launching the vote
>> to be clear :-)
>> 
>> 
>> On 05/07/2022 18:17, Christoph John wrote:
>> 
>>> Sorry, no. The last message regarding this was:
>> 
>>> 
>> 
>>> --snip-
>> 
>>> 
>> 
>>> 11.04.2022 09:37:30 Emmanuel Lécharny :
>> 
>>> Hi Christophe,
>> 
>>> sorry, my late mail was off base.
>> 
>>> The pb here is that the SSLEngine excpeiton is not propagated to the
>> handler, when it should.
>> 
>>> My guess is that we have some missing call somewhere in the stack. I'm
>> going to check that out.
>> 
>>> On 11/04/2022 00:15, Christoph John wrote:
>> 
 Hi,
>> 
 thanks Jonathan and Emmanuel for working on this!
>> 
 I tried to integrate this into QuickFIX/J and it compiles successfully.
>> However there are some tests failing that expect an Exception. For example
>> we have
>> 
 
>> https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
>> 
 Up to now it was tried to get the Exception via a filter in the chain.
>> This no longer seems to work but I think I can see the error getting thrown
>> in the log:
>> 
 SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false] task() -
>> storing error {}
>> 
 javax.net.ssl.SSLHandshakeException: No available authentication scheme
>> 
     at
>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
>> 
     at
>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>> 
     at
>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
>> 
     at
>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>> 
     at
>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
>> 
     at
>> java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)
>> 
     at
>> java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)
>> 
     at
>> java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
>> 
     at
>> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)
>> 
     at
>> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1182)
>> 
     at
>> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:840)
>> 
     at
>> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:801)
>> 
     at
>> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
>> 
     at
>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
>> 
     at
>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1277)
>> 
     at
>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1264)
>> 
     at
>> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
>> 
     at
>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1209)
>> 
     at
>> org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
>> 
     at
>> org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)
>> 
     at
>> org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
>> 
     at
>> org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
>> 
     at
>> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain

Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-06 Thread Jonathan Valliere
 What test are you trying?  Emmanuel made changes from the original design
to cause it to throw on the filter.  My original design threw on the filter
but only during a subsequent read or write action thereby enforcing strong
concurrency within the pipeline.

On Jul 6, 2022 at 3:53:57 AM, Christoph John
 wrote:

> Ok, the tests in QuickFIX/J which expect the exception to be caught in a
> filter still don't work.
> I recall that you also did some changes in other Apache projects to make
> it work with MINA 2.2.0. Could it be that I also need to adapt something in
> this regard?
>
> Thanks
> Chris
>
> Jul 5, 2022 18:47:09 Emmanuel Lécharny :
>
> I have tested that the exception gets propagated before launching the vote
> to be clear :-)
>
>
> On 05/07/2022 18:17, Christoph John wrote:
>
> > Sorry, no. The last message regarding this was:
>
> >
>
> > --snip-
>
> >
>
> > 11.04.2022 09:37:30 Emmanuel Lécharny :
>
> > Hi Christophe,
>
> > sorry, my late mail was off base.
>
> > The pb here is that the SSLEngine excpeiton is not propagated to the
> handler, when it should.
>
> > My guess is that we have some missing call somewhere in the stack. I'm
> going to check that out.
>
> > On 11/04/2022 00:15, Christoph John wrote:
>
> >> Hi,
>
> >> thanks Jonathan and Emmanuel for working on this!
>
> >> I tried to integrate this into QuickFIX/J and it compiles successfully.
> However there are some tests failing that expect an Exception. For example
> we have
>
> >>
> https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
>
> >> Up to now it was tried to get the Exception via a filter in the chain.
> This no longer seems to work but I think I can see the error getting thrown
> in the log:
>
> >> SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false] task() -
> storing error {}
>
> >> javax.net.ssl.SSLHandshakeException: No available authentication scheme
>
> >> at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
>
> >> at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>
> >> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
>
> >> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>
> >> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
>
> >> at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)
>
> >> at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)
>
> >> at
> java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
>
> >> at
> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)
>
> >> at
> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1182)
>
> >> at
> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:840)
>
> >> at
> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:801)
>
> >> at
> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
>
> >> at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
>
> >> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1277)
>
> >> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1264)
>
> >> at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
>
> >> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1209)
>
> >> at
> org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
>
> >> at
> org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)
>
> >> at
> org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
>
> >> at
> org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
>
> >> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
>
> >> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
>
> >> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
>
> >> at
> org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
>
> >> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
>
> >> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:643)
>
> >> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor.read(A

Exception in filter (was: Re: [Vote] MINA 2.2.0 release)

2022-07-06 Thread Christoph John
Ok, the tests in QuickFIX/J which expect the exception to be caught in a filter 
still don't work.
I recall that you also did some changes in other Apache projects to make it 
work with MINA 2.2.0. Could it be that I also need to adapt something in this 
regard?

Thanks
Chris

Jul 5, 2022 18:47:09 Emmanuel Lécharny :

> I have tested that the exception gets propagated before launching the vote to 
> be clear :-)
> 
> On 05/07/2022 18:17, Christoph John wrote:
>> Sorry, no. The last message regarding this was:
>> 
>> --snip-
>> 
>> 11.04.2022 09:37:30 Emmanuel Lécharny :
>> Hi Christophe,
>> sorry, my late mail was off base.
>> The pb here is that the SSLEngine excpeiton is not propagated to the 
>> handler, when it should.
>> My guess is that we have some missing call somewhere in the stack. I'm going 
>> to check that out.
>> On 11/04/2022 00:15, Christoph John wrote:
>>> Hi,
>>> thanks Jonathan and Emmanuel for working on this!
>>> I tried to integrate this into QuickFIX/J and it compiles successfully. 
>>> However there are some tests failing that expect an Exception. For example 
>>> we have
>>> https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
>>> Up to now it was tried to get the Exception via a filter in the chain. This 
>>> no longer seems to work but I think I can see the error getting thrown in 
>>> the log:
>>> SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false] task() - 
>>> storing error {}
>>> javax.net.ssl.SSLHandshakeException: No available authentication scheme
>>>     at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
>>>     at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>>>     at 
>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
>>>     at 
>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>>>     at 
>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
>>>     at 
>>> java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)
>>>     at 
>>> java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)
>>>     at 
>>> java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
>>>     at 
>>> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)
>>>     at 
>>> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1182)
>>>     at 
>>> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:840)
>>>     at 
>>> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:801)
>>>     at 
>>> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
>>>     at 
>>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
>>>     at 
>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1277)
>>>     at 
>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1264)
>>>     at 
>>> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
>>>     at 
>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1209)
>>>     at 
>>> org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
>>>     at 
>>> org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)
>>>     at 
>>> org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
>>>     at 
>>> org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
>>>     at 
>>> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
>>>     at 
>>> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
>>>     at 
>>> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
>>>     at 
>>> org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
>>>     at 
>>> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
>>>     at 
>>> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:643)
>>>     at 
>>> org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
>>>     at 
>>> org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
>>>     at 
>>> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1224)
>>>     at 
>>> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.proces

Re: [Vote] MINA 2.2.0 release

2022-07-05 Thread Jeff Genender
+1

Jeff

> On Jul 4, 2022, at 3:43 PM, Emmanuel Lécharny  wrote:
> 
> Hi!
> 
> 
> it has been a couple of months now that I cut a version of MINA 2.2.0, but 
> haven't started a vote, because I wanted to test that exception were properly 
> handled when generated from the SslFilter. It took may way longer to check 
> that, mainly due to external factors).
> 
> Anyway, I'm done with the test, all is nominal, so here is a formal vote for 
> MINA 2.2.0.
> 
> This version comes with a complete rewrite of the SSL layer, thanks for 
> Jonathan hard work !
> 
> 
> A temporary tag has been created (it can be removed if the vote is not 
> approved) :
> 
> https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4
> 
> 
> 
> The newly approved Nexus has been used for the preparation of this
> release and all final artifacts are stored in a staging repository:
> https://repository.apache.org/content/repositories/orgapachemina-1051
> 
> 
> The distributions are available for download on :
> https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0
> 
> Let us vote :
> [ ] +1 | Release MINA 2.2.0
> [ ] ± | Abstain
> [ ] -1 | Do *NOT*   release MINA 2.2.0
> 
> -- 
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



Re: [Vote] MINA 2.2.0 release

2022-07-05 Thread Emmanuel Lécharny
I have tested that the exception gets propagated before launching the 
vote to be clear :-)


On 05/07/2022 18:17, Christoph John wrote:

Sorry, no. The last message regarding this was:


--snip-


11.04.2022 09:37:30 Emmanuel Lécharny :

Hi Christophe,

sorry, my late mail was off base.

The pb here is that the SSLEngine excpeiton is not propagated to the handler, 
when it should.

My guess is that we have some missing call somewhere in the stack. I'm going to 
check that out.

On 11/04/2022 00:15, Christoph John wrote:

Hi,
thanks Jonathan and Emmanuel for working on this!
I tried to integrate this into QuickFIX/J and it compiles successfully. However 
there are some tests failing that expect an Exception. For example we have
https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
Up to now it was tried to get the Exception via a filter in the chain. This no 
longer seems to work but I think I can see the error getting thrown in the log:
SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false] task() - storing 
error {}
javax.net.ssl.SSLHandshakeException: No available authentication scheme
     at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
     at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
     at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
     at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
     at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
     at 
java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)
     at 
java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)
     at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
     at 
java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)
     at 
java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1182)
     at 
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:840)
     at 
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:801)
     at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
     at 
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
     at 
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1277)
     at 
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1264)
     at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
     at 
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1209)
     at 
org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
     at 
org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)
     at org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
     at org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
     at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
     at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
     at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
     at 
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
     at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
     at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:643)
     at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
     at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
     at 
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1224)
     at 
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1213)
     at 
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
     at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
     at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
     at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
     at java.base/java.lang.Thread.run(Thread.java:833)
What is the new way to get this Exception?
NB: I recall discussing this with Jonathan some months ago but seem to have 
lost 

Re: [Vote] MINA 2.2.0 release

2022-07-05 Thread Christoph John
Sorry, no. The last message regarding this was:


--snip-


11.04.2022 09:37:30 Emmanuel Lécharny :

Hi Christophe,

sorry, my late mail was off base.

The pb here is that the SSLEngine excpeiton is not propagated to the handler, 
when it should.

My guess is that we have some missing call somewhere in the stack. I'm going to 
check that out.

On 11/04/2022 00:15, Christoph John wrote:
> Hi,
> thanks Jonathan and Emmanuel for working on this!
> I tried to integrate this into QuickFIX/J and it compiles successfully. 
> However there are some tests failing that expect an Exception. For example we 
> have
> https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
> Up to now it was tried to get the Exception via a filter in the chain. This 
> no longer seems to work but I think I can see the error getting thrown in the 
> log:
> SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false] task() - storing 
> error {}
> javax.net.ssl.SSLHandshakeException: No available authentication scheme
>     at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
>     at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>     at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
>     at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>     at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
>     at 
> java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)
>     at 
> java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)
>     at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
>     at 
> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)
>     at 
> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1182)
>     at 
> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:840)
>     at 
> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:801)
>     at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
>     at 
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
>     at 
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1277)
>     at 
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1264)
>     at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
>     at 
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1209)
>     at 
> org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
>     at 
> org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)
>     at org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
>     at 
> org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
>     at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
>     at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
>     at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
>     at 
> org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
>     at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
>     at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:643)
>     at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
>     at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
>     at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1224)
>     at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1213)
>     at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
>     at 
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
>     at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>     at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>     at java.base/java.lang.Thread.run(Thread.java:833)
> What is the new way to get this Exception?
> NB: I recall discussing this with Jonathan some months ago but seem to have 
> lost track o

Re: [Vote] MINA 2.2.0 release

2022-07-05 Thread Emmanuel Lécharny

Hi Christoph,

yes. I guess you tested it already.


On 05/07/2022 09:38, Christoph John wrote:

Hi Emmanuel

Did you manage to fix the bug which we talked about in the mail thread from May 
regarding the M1 milestone?

Thanks
Chris

04.07.2022 23:43:37 Emmanuel Lécharny :


Hi!


it has been a couple of months now that I cut a version of MINA 2.2.0, but 
haven't started a vote, because I wanted to test that exception were properly 
handled when generated from the SslFilter. It took may way longer to check 
that, mainly due to external factors).

Anyway, I'm done with the test, all is nominal, so here is a formal vote for 
MINA 2.2.0.

This version comes with a complete rewrite of the SSL layer, thanks for 
Jonathan hard work !


A temporary tag has been created (it can be removed if the vote is not 
approved) :

https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4



The newly approved Nexus has been used for the preparation of this
release and all final artifacts are stored in a staging repository:
https://repository.apache.org/content/repositories/orgapachemina-1051


The distributions are available for download on :
https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0

Let us vote :
[ ] +1 | Release MINA 2.2.0
[ ] ± | Abstain
[ ] -1 | Do *NOT*   release MINA 2.2.0

--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org


--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



Re: [Vote] MINA 2.2.0 release

2022-07-05 Thread Emmanuel Lécharny

Ah, sorry, copy/paste error:

https://repository.apache.org/content/repositories/orgapachemina-1070/


On 05/07/2022 08:02, Jeff MAURY wrote:

Staging repo is not available

On Mon, Jul 4, 2022 at 11:43 PM Emmanuel Lécharny > wrote:


Hi!


it has been a couple of months now that I cut a version of MINA 2.2.0,
but haven't started a vote, because I wanted to test that exception
were
properly handled when generated from the SslFilter. It took may way
longer to check that, mainly due to external factors).

Anyway, I'm done with the test, all is nominal, so here is a formal
vote
for MINA 2.2.0.

This version comes with a complete rewrite of the SSL layer, thanks for
Jonathan hard work !


A temporary tag has been created (it can be removed if the vote is not
approved) :


https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4





The newly approved Nexus has been used for the preparation of this
release and all final artifacts are stored in a staging repository:
https://repository.apache.org/content/repositories/orgapachemina-1051 



The distributions are available for download on :
https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0


Let us vote :
[ ] +1 | Release MINA 2.2.0
[ ] ± | Abstain
[ ] -1 | Do *NOT*   release MINA 2.2.0

-- 
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE

T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com 
https://www.busit.com/ 

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org

For additional commands, e-mail: dev-h...@mina.apache.org




--
"Legacy code" often differs from its suggested alternative by actually 
working and scaling.

  - Bjarne Stroustrup

http://www.jeffmaury.com 
http://riadiscuss.jeffmaury.com 
http://www.twitter.com/jeffmaury 


--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



Re: [Vote] MINA 2.2.0 release

2022-07-05 Thread Christoph John
Hi Emmanuel

Did you manage to fix the bug which we talked about in the mail thread from May 
regarding the M1 milestone?

Thanks
Chris

04.07.2022 23:43:37 Emmanuel Lécharny :

> Hi!
> 
> 
> it has been a couple of months now that I cut a version of MINA 2.2.0, but 
> haven't started a vote, because I wanted to test that exception were properly 
> handled when generated from the SslFilter. It took may way longer to check 
> that, mainly due to external factors).
> 
> Anyway, I'm done with the test, all is nominal, so here is a formal vote for 
> MINA 2.2.0.
> 
> This version comes with a complete rewrite of the SSL layer, thanks for 
> Jonathan hard work !
> 
> 
> A temporary tag has been created (it can be removed if the vote is not 
> approved) :
> 
> https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4
> 
> 
> 
> The newly approved Nexus has been used for the preparation of this
> release and all final artifacts are stored in a staging repository:
> https://repository.apache.org/content/repositories/orgapachemina-1051
> 
> 
> The distributions are available for download on :
> https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0
> 
> Let us vote :
> [ ] +1 | Release MINA 2.2.0
> [ ] ± | Abstain
> [ ] -1 | Do *NOT*   release MINA 2.2.0
> 
> -- 
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



Re: [Vote] MINA 2.2.0 release

2022-07-04 Thread Jeff MAURY
Staging repo is not available

On Mon, Jul 4, 2022 at 11:43 PM Emmanuel Lécharny 
wrote:

> Hi!
>
>
> it has been a couple of months now that I cut a version of MINA 2.2.0,
> but haven't started a vote, because I wanted to test that exception were
> properly handled when generated from the SslFilter. It took may way
> longer to check that, mainly due to external factors).
>
> Anyway, I'm done with the test, all is nominal, so here is a formal vote
> for MINA 2.2.0.
>
> This version comes with a complete rewrite of the SSL layer, thanks for
> Jonathan hard work !
>
>
> A temporary tag has been created (it can be removed if the vote is not
> approved) :
>
>
> https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4
>
>
>
> The newly approved Nexus has been used for the preparation of this
> release and all final artifacts are stored in a staging repository:
> https://repository.apache.org/content/repositories/orgapachemina-1051
>
>
> The distributions are available for download on :
> https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0
>
> Let us vote :
> [ ] +1 | Release MINA 2.2.0
> [ ] ± | Abstain
> [ ] -1 | Do *NOT*   release MINA 2.2.0
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

-- 
"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


[Vote] MINA 2.2.0 release

2022-07-04 Thread Emmanuel Lécharny

Hi!


it has been a couple of months now that I cut a version of MINA 2.2.0, 
but haven't started a vote, because I wanted to test that exception were 
properly handled when generated from the SslFilter. It took may way 
longer to check that, mainly due to external factors).


Anyway, I'm done with the test, all is nominal, so here is a formal vote 
for MINA 2.2.0.


This version comes with a complete rewrite of the SSL layer, thanks for 
Jonathan hard work !



A temporary tag has been created (it can be removed if the vote is not 
approved) :


https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4



The newly approved Nexus has been used for the preparation of this
release and all final artifacts are stored in a staging repository:
https://repository.apache.org/content/repositories/orgapachemina-1051


The distributions are available for download on :
https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0

Let us vote :
[ ] +1 | Release MINA 2.2.0
[ ] ± | Abstain
[ ] -1 | Do *NOT*   release MINA 2.2.0

--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org