Re: [VOTE] Apache MINA 2.2.3, 2.1.8 and 2.0.25 releases

[Jeff MAURY]

+1.

2 remarks:

   - Does not build with Java 17
   - Build is failing on Windows


On Mon, Sep 11, 2023 at 8:11 AM Guillaume Nodet  wrote:

> +1
>
> Le jeu. 7 sept. 2023 à 05:30, Emmanuel Lecharny  a
> écrit :
>
> > hi!
> >
> > WARNING: there are 3 votes to cast!
> >
> >
> > This is a vote for a triple release:
> > * MINA 2.2.3
> > * MINA 2.1.8
> > * MINA 2.0.25
> >
> > Those versions are fixing a Datagram session bug:
> > DIRMINA-996:IoSessionRecycler RemoteAddress Collision
> > DIRMINA-1172:Multiple DatagramAcceptors and the creation of a session
> > object
> >
> >
> >
> > Temporary tags have been created (they can be removed if the vote is not
> > approved) :
> >
> > * MINA 2.2.3:
> >
> >
> https://github.com/apache/mina/commit/906884d52990b4fce119c462791abf1a5b577a83
> > * MINA 2.1.8:
> >
> >
> https://github.com/apache/mina/commit/c7f164cbeecedb4a4e32ba798e7cf435acdc471a
> > * MINA 2.0.25:
> >
> >
> https://github.com/apache/mina/commit/38ca5a9eb01461a7212b3904ff5010d0364d2f41
> >
> >
> >
> >
> > The final artifacts are stored in a staging repository:
> > * MINA 2.2.3:
> > https://repository.apache.org/content/repositories/orgapachemina-1086
> > * MINA 2.1.8:
> > https://repository.apache.org/content/repositories/orgapachemina-1085
> > * MINA 2.0.25:
> > https://repository.apache.org/content/repositories/orgapachemina-1087
> >
> >
> >
> > The distributions are available for download on :
> > * MINA 2.2.3: https://dist.apache.org/repos/dist/dev/mina/mina/2.2.3
> > * MINA 2.1.8: https://dist.apache.org/repos/dist/dev/mina/mina/2.1.8
> > * MINA 2.0.25: https://dist.apache.org/repos/dist/dev/mina/mina/2.0.25
> >
> >
> > Let us vote :
> > [ ] +1 | Release MINA 2.2.3
> > [ ] ± | Abstain
> > [ ] -1 | Do *NOT* release MINA 2.2.3
> >
> > [ ] +1 | Release MINA 2.1.8
> > [ ] ± | Abstain
> > [ ] -1 | Do *NOT* release MINA 2.1.8
> >
> >
> > [ ] +1 | Release MINA 2.0.25
> > [ ] ± | Abstain
> > [ ] -1 | Do *NOT* release MINA 2.0.25
> >
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> > For additional commands, e-mail: dev-h...@mina.apache.org
> >
> >
>
> --
> 
> Guillaume Nodet
>


-- 
"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

Re: [Vote] MINA 2.2.0 release

[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

Re: Has anyone ever used the HTTP Module?

[Jeff MAURY]

I remember I fixed a couple of issues submitted by someone using it

Le mer. 22 juin 2022 à 18:50, Jonathan Valliere  a
écrit :

> What HTTP module?
>
> On Wed, Jun 22, 2022 at 11:26 AM Emmanuel Lécharny 
> wrote:
>
> > Hi !
> >
> > Just wondering if anyone has ever used this module. To me, it seems
> > *really* like a proof of concept.
> >
> > Thanks !
> > --
> > *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> > <
> https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail=g
> >
> > 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: Removing Google Analytics from our web site

[Jeff MAURY]

+1

Shouldn't it be a general ASF concern ?

On Thu, Feb 10, 2022 at 5:06 PM Emmanuel Lécharny 
wrote:

> Hi !
>
> we have set up google analytics on MINA web site. It seems that it might
> cause issues with the european GDPR rules.
>
> I suggest we remove this feature we don't really use anyway.
>
> wdyt ?
> --
> *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

Re: [VOTE] Release Apache MINA 2.1.6

[Jeff MAURY]

+1

On Sun, Feb 6, 2022 at 9:18 AM Emmanuel Lecharny 
wrote:

> Hi,
>
> This is a bug fix release for MINA.
>
> Here is the list of fixed issues :
>
>
>* [DIRMINA-1152] IoServiceStatistics introduces huge latencies
>* [DIRMINA-1156]Inconsistent worker / idleWorker in
> OrderedThreadPoolExecutor
>
> It also contain some minor fixes (ignored tests being fixed, a minor
> infinite loop fixed in the Buffer toString() method if used in some
> corner case, etc)
>
>
> Here's the Jira link for this version if you'd like to review issues
> in more details:
>
> https://issues.apache.org/jira/projects/DIRMINA/versions/12351317
>
> 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=a58e68216d492f78d0341aef997ad3c78275cb65
>
> 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-1065/
>
>
> The distributions are available for download on :
> https://dist.apache.org/repos/dist/dev/mina/mina/2.1.6/
>
> Let us vote :
> [ ] +1 | Release MINA 2.1.6
> [ ] +/- | Abstain
> [ ] -1 | Do *NOT*  release MINA 2.1.6
>
> Thanks !
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.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

Re: Phasing out Java 8 for MINA 2.2 and further

[Jeff MAURY]

+1

On Wed, Nov 17, 2021 at 2:00 PM Emmanuel Lécharny 
wrote:

> Hi !
>
> Jonathan has started to implement a new version of SslFilter in the
> 2.2.0 branch, which is a good thing. However, this implementation
> requires a newer version of Java, namely Java 9.
>
> I suggest we switch to Java 11 for MINA 2.2+ while we keep Java 8 for
> the MINA 2.0 and 2.1 branches which will soon enter in maintenance mode.
>
> wdyt ?
>
> Thanks !
>
> --
> *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

Re: Development still alive?

[Jeff MAURY]

Feel free to provide patches and PRs if you don't see the community showing
up

Le sam. 20 févr. 2021 à 14:45, Jonathan Valliere 
a écrit :

> Alex,
>
> I think because of COVID everyone is just trying to keep their daily lives
> together right now.  I don't believe there are any current team members who
> are paid (as part of their jobs) to work on the framework.  Work would go a
> lot faster if there was.
>
> 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 Sat, Feb 20, 2021 at 4:52 AM Alex Buechel 
> wrote:
>
> > Hello guys,
> >
> > I would like to know, if the development of this framework is still alive
> > ...
> >
> > In JIRA I have posted several tickets, but get nearly no response.
> >
> > Thanks in advance
> > Alex
> >
>

Re: Enhancements to IoBufferHexDumper

[Jeff MAURY]

Add a new method getHexDump with a pretty flag and use the old one to call
with false

Le dim. 13 sept. 2020 à 01:23, Jonathan Valliere  a
écrit :

> I'm adding some additional methods to IoBufferHexDumper to produce pretty
> hex dumps for debugging purposes.
>
> Possible options to expose the new methods:
>
>1. Making IoBufferHexDumper class public instead of package local
>2. Add another public method to IoBuffer (e.g.
>IoBuffer#getPrettyHexDump() or #getVerboseHexDump()
>3. Overload IoBuffer#getHexDump() to include "boolean pretty" to enable
>pretty dumps.
>
> Anyone have any opinions?
>

Re: [VOTE] Release Apache MINA 2.1.4

[Jeff MAURY]

+1

On Mon, Aug 17, 2020 at 8:38 PM Christoph John
 wrote:

> +1
>
> Cheers,
> Chris.
>
> Am 17. August 2020 18:35:25 MESZ schrieb "Emmanuel Lécharny" <
> elecha...@gmail.com>:
> >Hi !
> >
> >I'm calling for a vote of Apache MINA 2.1.4 release.
> >
> >It fixes the following issues :
> >
> >
> >Bugs
> >
> > [DIRMINA-966] - NIO Datagram messages can get duplicated when
> >unable to be sent by the underlying DatagramChannel
> > [DIRMINA-1014] - SocketAcceptor doesn't unbind correctly
> > [DIRMINA-1115] - Filter ProfilerTimerFilter ArithmeticException
> > [DIRMINA-1123] - Receive buffer size is never set for NIO acceptor
> > [DIRMINA-1126] - filterWrite in ProtocolCodecFilter can send
> >corrupted writeRequest message to the next filter
> >
> >Improvements
> >
> >[DIRMINA-1064] - Implement cipher suites preference flag introduced
> >
> >in JDK 8
> > [DIRMINA-1105] - SSLHandler buffer handling
> >
> >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=8d1b14809f9277782756641fc85b6cc39b018734
> >
> >
> >
> >
> >
> >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.1.4/
> >
> >Let us vote :
> >[ ] +1 | Release MINA 2.1.4
> >[ ] ± | Abstain
> >[ ] -1 | Do *NOT*   release MINA 2.1.4
> >
> >Thanks !
> >
> >
> >-
> >To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> >For additional commands, e-mail: dev-h...@mina.apache.org
>


-- 
Jeff MAURY


"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

Re: [VOTE][LAZY] Move site from CMS/SVN to Hugo/Git

[Jeff MAURY]

+1

Le mer. 19 févr. 2020 16:56, Emmanuel Lécharny  a
écrit :

> +1 too.
>
> On 19/02/2020 16:03, Guillaume Nodet wrote:
> > +1
> >
> > Thx for pushing that.  The change will be a huge gain.
> >
> > Le mer. 19 févr. 2020 à 14:45, Roy Lenferink  a
> > écrit :
> >
> >> Hi MINA community,
> >>
> >> After last weeks proposal [1] I'd like to start a formal vote for moving
> >> over from the current Apache
> >> CMS (and SVN) to use Hugo and git.
> >>
> >> Short recap about Hugo: Hugo is a static site generator which is already
> >> having more stars on
> >> GitHub than Jekyll. It is easy to get started with (single static binary
> >> without dependencies) and it is
> >> really doing well performance wise.
> >>
> >> [ ] +1 for moving over from the Apache CMS / SVN to Hugo / Git.
> >> [ ] 0 I don't have a strong opinion on this
> >> [ ] -1 for not moving over, in this case please explain why
> >>
> >> This vote will be open for the usual 72 hour period. Lazy consensus
> >> applies: if no -1 votes are being
> >> cast within the voting period, the vote passes.
> >>
> >> ---
> >> Roy
> >>
> >> [1]
> >>
> https://lists.apache.org/thread.html/r20a75ad7f2509ba29413ef198d2a8d1aa3912367fd4f7921061fb060%40%3Cdev.mina.apache.org%3E
> >>
> >> -
> >> 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: Call to Vote on Branch Name Changes

[Jeff MAURY]

+1

Jeff

Le mer. 1 mai 2019 à 14:07, Jonathan Valliere  a écrit :

> Is that it? Just two votes?
>
> On Thu, Apr 25, 2019 at 2:13 PM Jonathan Valliere  >
> wrote:
>
> >
> >
> > On Thu, Apr 25, 2019 at 2:10 PM Emmanuel Lecharny 
> > wrote:
> >
> >> Le jeu. 25 avr. 2019 à 18:27, Jonathan Valliere  a
> >> écrit :
> >>
> >> > I'd like to call a vote on the following proposal for branch changes
> for
> >> > MINA.
> >> >
> >> >1. Rename 2.1 to 2.1.X because 2.1 is our root branch from which
> >> 2.1.1
> >> >and 2.1.2 spawn.  The HEAD of 2.1.X should represent the current
> >> > unreleased
> >> >version in the 2.1 track.
> >>
> >>
> >> +1
> >>
> >>
> >> >2. Rename 2.0 to 2.0.X because 2.0 is our root branch from which
> >> 2.0.16+
> >> >spawn.  The HEAD of 2.0.X should represent the current unreleased
> >> > version
> >> >in the 2.0 track.
> >>
> >>
> >> +1
> >>
> >>
> >> >3. Remove 2.1.0 because it tracks 2.1.X and prefer to use tags for
> >> >specific versions unless there is a specific reason why new
> >> maintenance
> >> >branches are
> >>
> >>
> >> Being far from my computer, I can’t check what this 2.1.0 is. >From the
> top
> >> of my head, it’s a tag, but if it’s a branch, then it’s bad. We need to
> >> clarify that.
> >
> >
> > 2.1.0 is a branch currently.  Update proposal to remove the 2.1.0 branch
> > after making sure 2.1 and 2.1.0 are at the same HEAD.
> >
> >
> >>
> >> Thanks for the proposals, they make a lot if sense.
> >>
> >> We probably should also decide something related to 3.X: I don’t think
> it
> >> will go any farther, and we may need this 3.X for the future evolutions.
> >> --
> >> Regards,
> >> Cordialement,
> >> Emmanuel Lécharny
> >> www.iktek.com
> >>
> > --
> >
> > 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.
> >
>

Re: MINA, Google Analytics and GDPR

[Jeff MAURY]

By default GA will automatically change settings to be gdpr compliant

Jeff

Le mer. 23 mai 2018 à 23:10, Jonathan Valliere  a
écrit :

> What was the point of having GA anyway? What was being tracked and what
> purpose did it serve?
>
> On Wed, May 23, 2018 at 5:01 PM Emmanuel Lécharny 
> wrote:
>
> > Hi,
> >
> > we currently are using Google Analytics on MINA web site. I'm not sure
> > many of us is looking at the results (I have access to the results, but
> > I must admit I haven't looked at it for years).
> >
> > In a GDPR compliance context, I think it's probably better to get rid of
> > GA. It's just a matter of removing the associated script in the
> > templates/foort.html page.
> >
> > It would take me 2 mins to do that.
> >
> > We have up to May, 25 to decide what to do :
> > - get rid of it
> > - or follow quite a complex process, that includes setting a IP
> > anonyisation flag, and a few other things.
> >
> >
> > Anyone wanting to keep GA up and running for MINA ?
> >
> > Thanks !
> >
> > --
> > Emmanuel Lecharny
> >
> > Symas.com
> > directory.apache.org
> >
> >
>

Re: Adding a secured() event in the IoHandler

[Jeff MAURY]

I always felt such an event was missing.

+1
ᐧ

On Thu, Apr 5, 2018 at 10:04 AM, Emmanuel Lécharny <elecha...@gmail.com>
wrote:

> Hi guys,
>
> as a follow up of a discussion we have had with Jonathan, I would like
> to suggest we add the 'secured()' event in the IoHandler. Th idea is to
> make it simpler for MINA users to be informed when teh TLS handshake has
> been completed.
>
> Currently, one need to add the USE_NOTIFICATION attribute in the session
> before adding the SslFilter in the chain, in order to receive a
> SESSION_SECURED message. This is kind of convoluted solution, which
> requires to check for every received message if it's a SESSION_SECURED
> message in the messageReceived() method.
>
> Having a secured() event would eliminate this attribute, and this
> message, making app implementers life easier.
>
> Typically, in the Apache LDAP API, we implement the startTLS extended
> operation, which allows the caller to setup a secured communication over
> an existing connection. That forces us to write such code :
>
> ...
> ldapSession.setAttribute( SslFilter.USE_NOTIFICATION, Boolean.TRUE );
> ldapSession.setAttribute( "HANDSHAKE_FUTURE", handshakeFuture );
> ldapSession.getFilterChain().addFirst( SSL_FILTER_KEY, sslFilter );
> ...
>
> (the future is used to be informed when the TLS handshake has been
> completed)
>
> and in order to process the SESSION_SECURED message, we have to do :
>
> public void messageReceived( IoSession session, Object message ) throws
> Exception
> {
> // Feed the response and store it into the session
> if ( message instanceof SslFilter.SslFilterMessage )
> {
> // This is a SSL message telling if the session has been
> secured or not
> HandshakeFuture handshakeFuture = ( HandshakeFuture )
> ldapSession.getAttribute( "HANDSHAKE_FUTURE" );
>
> if ( message == SslFilter.SESSION_SECURED )
> {
> // SECURED
> handshakeFuture.secured();
> }
> else
> {
> // UNSECURED
> handshakeFuture.cancel();
> }
>
> ldapSession.removeAttribute( "HANDSHAKE_FUTURE" );
>
> return;
> }
>
> which is kind of complicated...
>
> wdyt ?
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>


-- 
Jeff MAURY


"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

Re: [VOTE] Apache MINA 2.0.17

[Jeff MAURY]

+1
ᐧ

On Mon, Mar 12, 2018 at 7:59 AM, Guillaume Nodet <gno...@apache.org> wrote:

> +1
>
> 2018-03-06 15:09 GMT+01:00 Emmanuel Lécharny <elecha...@gmail.com>:
>
> > Hi,
> >
> >
> >
> > Here is the list of fixed issues :
> >
> > Bugs :
> > --
> >
> > [DIRMINA-844] - Http Proxy Authentication failed to complete (see
> > description for exact point of failure)
> > [DIRMINA-1002] - Mina IoHandlerEvents missing inputClosed enum item.
> > [DIRMINA-1051] - The MD5withRSA cipher is not anymore supported by
> > Java 8, and our tests certificates have been generated with it.
> > [DIRMINA-1052] - Fix the mvn-site command
> > [DIRMINA-1056] - IllegalArgumentException when setting max and
> > minReadBufferSize > 65536 (default)
> > [DIRMINA-1057] - AbstractIoSession getScheduledWriteMessages always
> > -negative?
> > [DIRMINA-1059] - NioProcessor's selector is synchronized but
> > accessed outside
> > [DIRMINA-1060] - Handle the spinning selectors in Socket/Datagram
> > Acceptor and Connector
> > [DIRMINA-1072] - SslFilter does not account for SSLEngine runtime
> > exceptions
> > [DIRMINA-1073] - NioSocketSession#isSecured does not comply with
> > interface contract
> > [DIRMINA-1076] - Leaking NioProcessors/NioSocketConnectors hanging
> > in call to dispose
> > [DIRMINA-1077] - Threads hanging in dispose() on
> SSLHandshakeException
> >
> > Improvement :
> > -
> >
> > [DIRMINA-1061] - When AbstractPollingIoProcessor read nothing, free
> > the temporary buffer should be better
> >
> > Task :
> > --
> >
> > [DIRMINA-1058] - Add the missing Javadoc
> >
> >
> > Here's the Jira link for this version if you'd like to review issues in
> > more details:
> >
> > https://issues.apache.org/jira/projects/DIRMINA/versions/12338623
> >
> > A temporary tag has been created (it can be removed if the vote is not
> > approved)
> >
> > 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-1034/
> >
> >
> > The distributions are available for download on :
> > https://dist.apache.org/repos/dist/dev/mina/mina/2.0.17/
> >
> > Let us vote :
> > [ ] +1 | Release MINA 2.0.17
> > [ ] +/- | Abstain
> > [ ] -1 | Do *NOT*  release MINA 2.0.17
> >
> > Thanks !
> >
> > --
> > Emmanuel Lecharny
> >
> > Symas.com
> > directory.apache.org
> >
> >
>
>
> --
> 
> Guillaume Nodet
>



-- 
Jeff MAURY


"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

Re: [RESULT] [VOTE] Apache Mina SSHD 1.6.0

[Jeff MAURY]

Just noticed while working on the board report that the web site still
advertise 1.2.0 as the latest release

Jeff
ᐧ

On Wed, Jul 5, 2017 at 8:35 AM, Guillaume Nodet <gno...@apache.org> wrote:

> Closing this vote with 4 +1s and no other votes.
> I'll publish the artifacts asap.
>
> Cheers,
> Guillaume
>
> 2017-06-29 11:36 GMT+02:00 Guillaume Nodet <gno...@apache.org>:
>
> > I've staged a release for SSHD 1.6.0 at:
> >   https://repository.apache.org/content/repositories/orgapachemina-1031
> >
> > I've moved issues targeted to 1.5.0 to 1.6.0, so we have the overall
> > following changes:
> >
> > Release Notes - MINA SSHD - Version 1.6.0
> > ** Bug
> > * [SSHD-85] - Port Forward closes connection before all bytes are
> sent
> > * [SSHD-728] - sshd-core sftp not working with FileZilla sftp client
> > * [SSHD-731] - Vulnerability in SimpleAccessControlSftpEventListener
> >  implementation
> > * [SSHD-732] - ClientIdentitiesWatcher should load keys one at a time
> > * [SSHD-734] - When ClientSessionImpl construction fails,
> > AbstractSessionIoHandler#exceptionCaught may throw NPE
> > * [SSHD-749] - SFTP client sends wrong open flags for protocol
> version
> > 4
> > * [SSHD-752] - HostConfigEntry can't parse tabbed SSH config files
> > * [SSHD-753] - SSHD cannot read its keyfile through a symlink
> > ** Improvement
> > * [SSHD-739] - A call to resolvePropertyValue can be very inefficient
> > * [SSHD-740] - Add default methods on PropertyResolver to actually do
> > the property resolution
> > * [SSHD-747] - Add support for non-standard port specification in
> > known_hosts file
> > * [SSHD-748] - Activate Maven PMD plugin in the project
> > ** New Feature
> > * [SSHD-656] - Support The PROXY protocol
> > * [SSHD-710] - Cannot connect standard OpenSSH client/server using
> > ed25519 keys
> > * [SSHD-741] - Provide seamless replacement for Spring integation
> SFTP
> > adapter
> > * [SSHD-750] - Accept SSH clients advertising vesion 1.99
> > ** Task
> > * [SSHD-727] - Upgrade used EdDSA artifact version to 1.1
> > ** Wish
> > * [SSHD-733] - SSHD server displays file symlinks instead of dir
> > symlinks
> >
> >
> > Please review and vote !
> >
> > Cheers,
> > Guillaume Nodet
> >
> >
> >
> >
>
>
> --
> 
> Guillaume Nodet
>



-- 
Jeff MAURY


"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

Re: [VOTE] Release Apache Mina SSHD 1.4.0

[Jeff MAURY]

Sorry for the delay
+1

Jeff

On Wed, Feb 15, 2017 at 12:09 PM, Guillaume Nodet <gno...@apache.org> wrote:

> I've staged a candidate release for SSHD 1.4.0.
>
> The staging repository is available at :
>   https://repository.apache.org/content/repositories/orgapachemina-1028
>
> Release notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12310849=12338322
>
> Please review and vote !
>
> Cheers,
> Guillaume Nodet
>



-- 
Jeff MAURY


"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

Re: [VOTE] Apache FTPServer 1.1.0 release

[Jeff MAURY]

+1

Jeff


On Fri, Oct 28, 2016 at 9:54 AM, Christoph John <christoph.j...@macd.com>
wrote:

> +1
>
>
> On 26/10/16 18:55, Ashish wrote:
>
>> +1
>>
>> Build works find, all test cases passed.
>>
>> On Mon, Oct 24, 2016 at 6:34 AM, Emmanuel Lécharny <elecha...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> this is a new release of Apache MINA FTPServer, 1.1.0. It's a bug fix
>>> release, that makes FTPServer
>>> using MINA 2.0.16.
>>>
>>> Java 7 is required to run this version.
>>>
>>>
>>> Here are the fixed issues :
>>>
>>> Bugs :
>>> --
>>>
>>> [FTPSERVER-475 <https://issues.apache.org/jira/browse/FTPSERVER-475>]
>>> FTPServer should use latest MINA-Core (2.0.15) and prevent abstract method
>>> error caused by missing FtpHandlerAdapter.inputClosed()
>>> [FTPSERVER-461 <https://issues.apache.org/jira/browse/FTPSERVER-461>]
>>> FtpServer implement inputClosed() or extend IoHandlerAdapter for MINA 2.0.8
>>> or higher
>>>
>>>
>>>
>>> A temporary tag has been created (it can be removed if the vote is not
>>> approved):
>>>
>>> Updated Branches:
>>>refs/heads/master 50e47f44f -> 8f39414e2
>>>
>>> Project: http://git-wip-us.apache.org/repos/asf/mina-ftpserver/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/mina-ftpserver/commit
>>> /8f39414e
>>> Tree: http://git-wip-us.apache.org/repos/asf/mina-ftpserver/tree/8
>>> f39414e
>>> Diff: http://git-wip-us.apache.org/repos/asf/mina-ftpserver/diff/8
>>> f39414e
>>>
>>> - Nexus repository: https://repository.apache.org/
>>> content/repositories/orgapachemina-1027
>>>
>>> - Binaries and sources: https://dist.apache.org/repos/
>>> dist/dev/mina/ftpserver/1.1.0/
>>>
>>> Let us vote :
>>> [ ] +1 | Release FTPServer 1.1.0
>>> [ ] ± | Abstain
>>> [ ] -1 | Do **NOT**  release FTPServer 1.1.0
>>>
>>> Thanks !
>>>
>>> --
>>> Emmanuel Lecharny
>>>
>>> Symas.com
>>> directory.apache.org
>>>
>>>
>>
>>
> --
> Christoph John
> Development & Support
> Direct: +49 241 557080-28
> Mailto:christoph.j...@macd.com
>
>
>
> http://www.macd.com <http://www.macd.com/>
> ----
> 
>
> 
> 
> MACD GmbH
> Oppenhoffallee 103
> D-52066 Aachen
> Tel: +49 241 557080-0 | Fax: +49 241 557080-10
>  Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
>
> Geschäftsführer: George Macdonald
> 
> 
>
> 
> 
>
> take care of the environment - print only if necessary
>



-- 
Jeff MAURY


"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

Re: [VOTE] MINA 2.0.16 release

[Jeff MAURY]

+1

Jeff

Le 29 oct. 2016 11:02, "Emmanuel Lécharny"  a écrit :

> For the record, building MINA 2.0.16 with Java 8 may fail. Oracle have
> demoted the MD5withRSA cipher, and sadly the certificate we use in some
> tests have been created with this cipher.
>
> It's possible to workaround the issue, by changing the
> JRE_HOME/lib/security/java.security file, and more specifically the
> jdk.certpath.disabledAlgorithms and jdk.tls.disabledAlgorithms
> parameters : you will have to remove MD5 and MD5withRSA from those lists.
>
> We will have that fixed in 2.017, by regenerating the certificates.
>
> FtpServer had the same issue, but I have enforced teh use of this cipher
> programatically.
>

Re: [VOTE] MINA 2.0.15 release

[Jeff MAURY]

+1

Jeff

On Thu, Sep 22, 2016 at 3:08 AM, Ashish <paliwalash...@gmail.com> wrote:

> +1
>
> Build works fine. All test cases passed
>
> On Wed, Sep 21, 2016 at 12:11 AM, Emmanuel Lécharny <elecha...@gmail.com>
> wrote:
> > Hi,
> >
> > Here is a new release, MINA 2.0.15. It fixes one critical SSL issue, and
> a NPE. Javadoc has also been a bit cleaned up.
> >
> > Here are the fixed issues :
> >
> > Bugs :
> > --
> >
> > [DIRMINA-1044 <https://issues.apache.org/jira/browse/DIRMINA-1044>]
> Non-Secure (no TLS/SSL) based client could successfully send message to
> secure Mina endpoint after second attempt
> > [DIRMINA-1à43 <https://issues.apache.org/jira/browse/DIRMINA-1043>]
> NullPointerException after upgrade to mina 2.0.14
> >
> >
> >
> > A temporary tag has been created (it can be removed if the vote is not
> approved):
> >
> > Updated Tags:  refs/tags/2.0.15 [created] 0399f97db
> >
> > Project: http://git-wip-us.apache.org/repos/asf/mina/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/mina/commit/8bae1d4f
> > Tree: http://git-wip-us.apache.org/repos/asf/mina/tree/8bae1d4f
> > Diff: http://git-wip-us.apache.org/repos/asf/mina/diff/8bae1d4f
> >
> > - Nexus repository: https://repository.apache.org/content/repositories/
> orgapachemina-1025
> >
> > - Binaries and sources: https://dist.apache.org/repos/
> dist/dev/mina/mina/2.0.15/
> >
> > Let us vote :
> > [ ] +1 | Release MINA 2.0.15
> > [ ] ± | Abstain
> > [ ] -1 | Do **NOT**  release MINA 2.0.15
> >
> > Thanks !
> >
>
>
>
> --
> thanks
> ashish
>
> Blog: http://www.ashishpaliwal.com/blog
> My Photo Galleries: http://www.pbase.com/ashishpaliwal
>



-- 
Jeff MAURY


"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

Re: [VOTE] Release Apache Mina SSHD 1.2.0

[Jeff MAURY]

+1

Jeff

On Thu, Mar 31, 2016 at 9:15 AM, Guillaume Nodet <gno...@apache.org> wrote:

> We're still missing a few binding votes 
>
> 2016-03-09 11:30 GMT+01:00 Guillaume Nodet <gno...@apache.org>:
>
> > I've staged a release candidate for SSHD 1.2.0
> >
> > Repository:
> >   https://repository.apache.org/content/repositories/orgapachemina-1021
> >
> > Release notes:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334702=Html=12310849
> >
> > Please review and vote !
> >
> > Cheers,
> > Guillaume Nodet
> >
>
>
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>



-- 
Jeff MAURY


"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

Re: svn commit: r1730433 - /mina/site/trunk/content/mina-project/developer-guide.mdtext

[Jeff MAURY]

Should we really promote skipping tests which is a bad practice ?

Jeff


On Mon, Feb 15, 2016 at 12:45 AM, <elecha...@apache.org> wrote:

> Author: elecharny
> Date: Sun Feb 14 23:45:54 2016
> New Revision: 1730433
>
> URL: http://svn.apache.org/viewvc?rev=1730433=rev
> Log:
> Fixed the developper guide
>
> Modified:
> mina/site/trunk/content/mina-project/developer-guide.mdtext
>
> Modified: mina/site/trunk/content/mina-project/developer-guide.mdtext
> URL:
> http://svn.apache.org/viewvc/mina/site/trunk/content/mina-project/developer-guide.mdtext?rev=1730433=1730432=1730433=diff
>
> ==
> --- mina/site/trunk/content/mina-project/developer-guide.mdtext (original)
> +++ mina/site/trunk/content/mina-project/developer-guide.mdtext Sun Feb 14
> 23:45:54 2016
> @@ -182,7 +182,7 @@ Answer to maven questions :
>  Then some other questions will be asked, about the next version to use.
> The default values should be fine.
>
>  
> -**Be Careful**
> +Be Careful
>
>  Make sure the change made by the release plugin is correct! (pom.xml,
> tags created)
>  
> @@ -209,8 +209,10 @@ The first mail tells you that the SNAPSH
>
>  ### Step 4 : perform the release
>
> -The last step before launching a vote is to push the potential release to
> Nexus so that every user can test the created packages. Perform the
> following actions
> +The last step before launching a vote is to push the potential release to
> Nexus so that every user can test the created packages. Perform the
> following actions (note that we have to run a build first for teh javadoc
> to be correctly generated...) :
>
> +$ mvn clean install -Pserial -DskipTests
> +...
>  $ mvn -Pserial,apache-release release:perform
>  ...
>  [INFO] [INFO]
> 
> @@ -250,11 +252,30 @@ Done !
>
>  ### Step 5 : closing the staging release on nexus
>
> -Now, you have to close the staged project on nexus. In order to do that
> you *must* have exported your PGP key to a PGP public server [see](
> http://www.apache.org/dev/openpgp.html)
> +Now, you have to close the staged project on nexus. In order to do that
> you **must** have exported your PGP key to a PGP public server [see](
> http://www.apache.org/dev/openpgp.html)
>
> -Connect to the Nexus server (https://repository.apache.org), login, and
> select the MINA staging repository you just created, then click on the
> 'close' button. You are home...
> +Connect to the [Nexus server](https://repository.apache.org), login, and
> select the MINA staging repository you just created, then click on the
> 'close' button. You are home...
>
>  ### Step 6 : Build the Site
> +You will need to modify the **pom.xml** file to be able to run the **mvn
> site** command. Actually, you have to comment the executions part of the
> maven JXF plugin in the **maven-site-plugin** configuration :
> +
> +
> +  maven-jxr-plugin
> +  
> +true
> +  
> +
> +  
> +
> +
>
>  $ cd target/checkout
>  $ mvn -Pserial site
>
>
>


-- 
Jeff MAURY


"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

Re: [VOTE] MINA 2.0.13 release

[Jeff MAURY]

+1

Jeff

On Fri, Feb 12, 2016 at 7:36 PM, Emmanuel Lécharny <elecha...@gmail.com>
wrote:

> Hi,
>
> MINA 2.0.13 is a release that fixes a serious bug in the SslHandler that
> was causing a deadlock in some specific case.
>
> Here is the fixed issues :
>
> Bugs :
> --
>
> [DIRMINA-1019 <https://issues.apache.org/jira/browse/DIRMINA-1019>]
> SslHandler flushScheduledEvents race condition
> [DIRMINA-1027 <https://issues.apache.org/jira/browse/DIRMINA-1027>]
> SSLHandler writes corrupt messages under heavy load
>
>
>
> A temporary tag has been created (it can be removed if the vote is not
> approved):
>
> Updated Tags:  refs/tags/2.0.13 [created] 882dbe52a
>
> Project: http://git-wip-us.apache.org/repos/asf/mina/repo
> Commit: http://git-wip-us.apache.org/repos/asf/mina/commit/2cfadcf3
> Tree: http://git-wip-us.apache.org/repos/asf/mina/tree/2cfadcf3
> Diff: http://git-wip-us.apache.org/repos/asf/mina/diff/2cfadcf3
>
> - Nexus repository:
> https://repository.apache.org/content/repositories/orgapachemina-1020
>
> - Binaries:http://people.apache.org/~elecharny
>
> Let us vote :
> [ ] +1 | Release MINA 2.0.13
> [ ] ± | Abstain
> [ ] -1 | Do **NOT**  release MINA 2.0.13
>
> Thanks !
>
>
>


-- 
Jeff MAURY


"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

Re: MINA jenkins Build on windows

[Jeff MAURY]

No, I looked at it but I think it's related to Jenkins.

On Sun, Feb 7, 2016 at 8:46 AM, Emmanuel Lécharny <elecha...@gmail.com>
wrote:

> Hi guys,
>
> it's a couple of days we get some jenkins error every hour for windows.
>
> I have askd Infra about it, and in the mean time, changed the
> periodicity to get only one build per day.
>
> If anyone has a clue about what should be done to get this fixed, this
> would be very appreciated.
>



-- 
Jeff MAURY


"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

Re: [VOTE] MINA 2.0.12 release, take 2

[Jeff MAURY]

+1

Jeff


On Wed, Feb 3, 2016 at 4:37 PM, Jeff Genender <jgenen...@apache.org> wrote:

> +1
>
> Jeff
>
> > On Feb 3, 2016, at 2:21 AM, Emmanuel Lécharny <elecha...@gmail.com>
> wrote:
> >
> > Hi,
> >
> > Here is another vote for a new bug fix release of Mina : 2.0.12.
> >
> > This release fixed a serious issue in the IoProcessor loop, that may
> lead in some cases to a 100% CPU consumption.
> > It also fixes the IoProcessor loop exit conditions. Another two bugs
> found by Radovan Semancik has been fixed.
> >
> > Here is the list of fixed issues :
> >
> > Bugs :
> > --
> >
> > [DIRMINA-1001 <https://issues.apache.org/jira/browse/DIRMINA-1001;>]
> mina2.0.9 session.close cpu100%
> > [DIRMINA-1006 <https://issues.apache.org/jira/browse/DIRMINA-1006;>]
> mina2.0.9 NioProcessor thread make cpu 100%
> > [DIRMINA-1024 <https://issues.apache.org/jira/browse/DIRMINA-1024;>]
> There is no way to start a SslHandshake when the autoStart flag is set to
> false
> > [DIRMINA-1026 <https://issues.apache.org/jira/browse/DIRMINA-1026;>]
> Session may be removed twice from the removedSession queue
> >
> >
> >
> > A temporary tag has been created (it can be removed if the vote is not
> > approved):
> >
> > Updated Tags:  refs/tags/2.0.12 [created] 5498c66fb
> >
> > Project: http://git-wip-us.apache.org/repos/asf/mina/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/mina/commit/d35959b8
> > Tree: http://git-wip-us.apache.org/repos/asf/mina/tree/d35959b8
> > Diff: http://git-wip-us.apache.org/repos/asf/mina/diff/d35959b8
> >
> > - Nexus repository:
> https://repository.apache.org/content/repositories/orgapachemina-1019
> >
> > - Binaries:http://people.apache.org/~elecharny
> >
> > Let us vote :
> > [ ] +1 | Release MINA 2.0.12
> > [ ] ± | Abstain
> > [ ] -1 | Do **NOT**  release MINA 2.0.12
> >
> > Thanks !
> >
>
>


-- 
Jeff MAURY


"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

Re: [VOTE] MINA 2.0.12 release

[Jeff MAURY]

+1

Jeff

On Sun, Jan 31, 2016 at 8:27 AM, Emmanuel Lécharny <elecha...@gmail.com>
wrote:

> Hi,
>
> Here is a vote for a new bug fix release of Mina : 2.0.12.
>
> Tjis release fixed a serious issue in the IoProcessor loop, that may lead
> in some cases to a 100% CPU consumption.
> It also fixes the IoProcessor loop exit conditions.
>
> Here is the list of fixed issues :
>
> Bugs :
> --
>
> [DIRMINA-1001 <https://issues.apache.org/jira/browse/DIRMINA-1001;>]
> mina2.0.9 session.close cpu100%
> [DIRMINA-1006 <https://issues.apache.org/jira/browse/DIRMINA-1006;>]
> mina2.0.9 NioProcessor thread make cpu 100%
>
>
> A temporary tag has been created (it can be removed if the vote is not
> approved):
>
> Updated Tags:  refs/tags/2.0.12 [created] 8df857252
>
> Project: http://git-wip-us.apache.org/repos/asf/mina/repo
> Commit: http://git-wip-us.apache.org/repos/asf/mina/commit/7c7336a9
> Tree: http://git-wip-us.apache.org/repos/asf/mina/tree/7c7336a9
> Diff: http://git-wip-us.apache.org/repos/asf/mina/diff/7c7336a9
>
> - Nexus repository:
> https://repository.apache.org/content/repositories/orgapachemina-1018
>
> - Binaries:http://people.apache.org/~elecharny
>
> Let us vote :
> [ ] +1 | Release MINA 2.0.12
> [ ] ± | Abstain
> [ ] -1 | Do **NOT**  release MINA 2.0.12
>
> Thanks !
>
> --
> Regards, Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
>


-- 
Jeff MAURY


"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

Re: [VOTE] Release SSHD 1.1.0

[Jeff MAURY]

Lyor,

ok, I created a "normal" user on my Win7 workstation and build is now ok.
It would be nice if the build checks that condition for non expert users.

So here's my +1.

Jeff


On Mon, Jan 25, 2016 at 7:12 AM, Lyor Goldstein <lgoldst...@vmware.com>
wrote:

> Hi Jeff,
>
> Indeed there is an issue with running the tests under Windows as
> administrator - we chose not to address it by design as there are some
> complex issues associated with identifying such a user/group in Java
> without resorting to native Win32 API and we did not want to get into it.
> Please run the build under a 'normal' user and see if it succeeds.
>
> Lyor
>
> -Original Message-
> From: jeffma...@gmail.com [mailto:jeffma...@gmail.com] On Behalf Of Jeff
> MAURY
> Sent: Monday, January 25, 2016 00:19
> To: dev <dev@mina.apache.org>
> Subject: Re: [VOTE] Release SSHD 1.1.0
>
> Sorry, I did not get the files were removed.
> Here is the link:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__paste.apache.org_2h1d=BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=GiITVQl_XsSfIeLEpIVnV6PUOEsY7E3poTdDlstjoe0=5k-ZlgvRzOTnFfiM6Bjq9e6NjeSLI3vFAHFBu7zeK_4=
>
> Jeff
>
> On Sun, Jan 24, 2016 at 10:49 PM, Emmanuel Lécharny <elecha...@gmail.com>
> wrote:
>
> > Le 24/01/16 22:06, Jeff MAURY a écrit :
> > > Please find the attached log file.
> >
> > Jeff, the attachements are removed by the mail system.
> >
> > Better create a JIRA and attach the log to it, or use
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__paste.apache.org_
> > =BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55x
> > AmksY4SsQcYP_oPrfu1Vne__JKwWQvo=GiITVQl_XsSfIeLEpIVnV6PUOEsY7E3poTdD
> > lstjoe0=a8e9PYnrpZjU8kUGYYzqy6VKG_tQFIB7HihsosyQm9M=  to insert
> > your attachement and post the URL
> >
> >
>
>
> --
> Jeff MAURY
>
>
> "Legacy code" often differs from its suggested alternative by actually
> working and scaling.
>  - Bjarne Stroustrup
>
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jeffmaury.com=BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=GiITVQl_XsSfIeLEpIVnV6PUOEsY7E3poTdDlstjoe0=Ftk_Qru7o5drrWQoPimlewnuukEQ05kv2Qp8O7N220M=
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__riadiscuss.jeffmaury.com=BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=GiITVQl_XsSfIeLEpIVnV6PUOEsY7E3poTdDlstjoe0=fN4NmGYsBuHmbet6FlgAd7bsMxE3cipaWietj_PaOmo=
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_jeffmaury=BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=GiITVQl_XsSfIeLEpIVnV6PUOEsY7E3poTdDlstjoe0=mulpHFwNdTPd3yY6d0L8VsKuZU63u5Gl2wKRFEKUyPU=
>



-- 
Jeff MAURY


"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

RE: [VOTE] Release SSHD 1.1.0

[Jeff MAURY]

I checked my sent mail.
It has a sshd.log file

Jeff
Le 24 janv. 2016 06:50, "Lyor Goldstein" <lgoldst...@vmware.com> a écrit :

> Hi Jeff,
>
> I don’t see any attached log to the message….
> Lyor
>
> From: jeffma...@gmail.com [mailto:jeffma...@gmail.com] On Behalf Of Jeff
> MAURY
> Sent: Friday, January 22, 2016 12:20
> To: dev <dev@mina.apache.org>
> Subject: Re: [VOTE] Release SSHD 1.1.0
>
> Hello,
>
> I tried to build on a Windows workstation and I got failed tests. See the
> attached log. Please note that I am administrator of my machine.
>
> Regards
> Jeff
>
>
> On Fri, Jan 22, 2016 at 10:10 AM, Jeff MAURY <jeffma...@jeffmaury.com
> <mailto:jeffma...@jeffmaury.com>> wrote:
> Working on it this morning.
> Already a remark: in NOTICE.txt it says copyright 2008 - 2015 shoud be
> 2008 - 2016
>
> On Fri, Jan 22, 2016 at 8:50 AM, Guillaume Nodet <gno...@apache.org
> <mailto:gno...@apache.org>> wrote:
> I think we're still missing at least one binding vote ...
>
> Guillaume
>
> 2016-01-22 8:49 GMT+01:00 Guillaume Nodet <gno...@apache.org gno...@apache.org>>:
>
> > +1
> >
> > 2016-01-15 16:11 GMT+01:00 Guillaume Nodet <gno...@apache.org gno...@apache.org>>:
> >
> >> I uploaded a 1.1.0 release of SSHD.
> >> The artefacts are available at
> >>   https://repository.apache.org/content/repositories/orgapachemina-1016
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__repository.apache.org_content_repositories_orgapachemina-2D1016=BQMFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=Y8cE5-QYm0_O523fmZ9b2-wL30Dt622_jZYvF0AySXs=qofjyILYMVN1zBiYycg9MwCcYwF0Gr9DxBy8L0CzRvQ=
> >
> >>
> >> Release notes:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310849=12333293
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_secure_ReleaseNote.jspa-3FprojectId-3D12310849-26version-3D12333293=BQMFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=Y8cE5-QYm0_O523fmZ9b2-wL30Dt622_jZYvF0AySXs=1u66Pm-61NArw43ePAfjsXHvbJM2XF8neH4ffbg0e6I=
> >
> >>
> >> Please review and vote.
> >>
> >> Cheers,
> >> Guillaume Nodet
> >>
> >
> >
>
>
>
> --
> Jeff MAURY
>
>
> "Legacy code" often differs from its suggested alternative by actually
> working and scaling.
>  - Bjarne Stroustrup
>
> http://www.jeffmaury.com<
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jeffmaury.com=BQMFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=Y8cE5-QYm0_O523fmZ9b2-wL30Dt622_jZYvF0AySXs=uXmIm6apn3BYJBauAHjbexi0H6hlzy4e4lTrYxjjzjY=
> >
> http://riadiscuss.jeffmaury.com<
> https://urldefense.proofpoint.com/v2/url?u=http-3A__riadiscuss.jeffmaury.com=BQMFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=Y8cE5-QYm0_O523fmZ9b2-wL30Dt622_jZYvF0AySXs=3u50glh0aKdGUkTZVuAxTxUPDVnWZWhloBE69ploXtU=
> >
> http://www.twitter.com/jeffmaury<
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_jeffmaury=BQMFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=Y8cE5-QYm0_O523fmZ9b2-wL30Dt622_jZYvF0AySXs=TwR4TwdFdSZvv5cqR2zD0gvWJdrS5ddflWFWeg18nHw=
> >
>
>
>
> --
> Jeff MAURY
>
>
> "Legacy code" often differs from its suggested alternative by actually
> working and scaling.
>  - Bjarne Stroustrup
>
> http://www.jeffmaury.com<
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jeffmaury.com=BQMFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=Y8cE5-QYm0_O523fmZ9b2-wL30Dt622_jZYvF0AySXs=uXmIm6apn3BYJBauAHjbexi0H6hlzy4e4lTrYxjjzjY=
> >
> http://riadiscuss.jeffmaury.com<
> https://urldefense.proofpoint.com/v2/url?u=http-3A__riadiscuss.jeffmaury.com=BQMFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=Y8cE5-QYm0_O523fmZ9b2-wL30Dt622_jZYvF0AySXs=3u50glh0aKdGUkTZVuAxTxUPDVnWZWhloBE69ploXtU=
> >
> http://www.twitter.com/jeffmaury<
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_jeffmaury=BQMFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=Y8cE5-QYm0_O523fmZ9b2-wL30Dt622_jZYvF0AySXs=TwR4TwdFdSZvv5cqR2zD0gvWJdrS5ddflWFWeg18nHw=
> >
>

Re: [VOTE] Release SSHD 1.1.0

[Jeff MAURY]

Sorry, I did not get the files were removed.
Here is the link: http://paste.apache.org/2h1d

Jeff

On Sun, Jan 24, 2016 at 10:49 PM, Emmanuel Lécharny <elecha...@gmail.com>
wrote:

> Le 24/01/16 22:06, Jeff MAURY a écrit :
> > Please find the attached log file.
>
> Jeff, the attachements are removed by the mail system.
>
> Better create a JIRA and attach the log to it, or use
> https://paste.apache.org/ to insert your attachement and post the URL
>
>


-- 
Jeff MAURY


"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

Re: [VOTE] Release SSHD 1.1.0

[Jeff MAURY]

Please find the attached log file.

Jeff

On Sun, Jan 24, 2016 at 3:26 PM, Jeff MAURY <jeffma...@jeffmaury.com> wrote:

> OK but as I'm outside I will send it this evening (5 hours from now)
> Jeff
> Le 24 janv. 2016 15:05, "Lyor Goldstein" <lgoldst...@vmware.com> a écrit :
>
>> For some reason I did not get it - can you send it to me directly to this
>> e-mail instead of dev@mina.apache.org ?
>> Thanks...
>>
>> -Original Message-
>> From: Jeff MAURY [mailto:jeffma...@gmail.com]
>> Sent: Sunday, January 24, 2016 15:58
>> To: dev <dev@mina.apache.org>
>> Subject: RE: [VOTE] Release SSHD 1.1.0
>>
>> I checked my sent mail.
>> It has a sshd.log file
>>
>> Jeff
>> Le 24 janv. 2016 06:50, "Lyor Goldstein" <lgoldst...@vmware.com> a écrit
>> :
>>
>> > Hi Jeff,
>> >
>> > I don’t see any attached log to the message….
>> > Lyor
>> >
>> > From: jeffma...@gmail.com [mailto:jeffma...@gmail.com] On Behalf Of
>> > Jeff MAURY
>> > Sent: Friday, January 22, 2016 12:20
>> > To: dev <dev@mina.apache.org>
>> > Subject: Re: [VOTE] Release SSHD 1.1.0
>> >
>> > Hello,
>> >
>> > I tried to build on a Windows workstation and I got failed tests. See
>> > the attached log. Please note that I am administrator of my machine.
>> >
>> > Regards
>> > Jeff
>> >
>> >
>> > On Fri, Jan 22, 2016 at 10:10 AM, Jeff MAURY <jeffma...@jeffmaury.com
>> > <mailto:jeffma...@jeffmaury.com>> wrote:
>> > Working on it this morning.
>> > Already a remark: in NOTICE.txt it says copyright 2008 - 2015 shoud be
>> > 2008 - 2016
>> >
>> > On Fri, Jan 22, 2016 at 8:50 AM, Guillaume Nodet <gno...@apache.org
>> > <mailto:gno...@apache.org>> wrote:
>> > I think we're still missing at least one binding vote ...
>> >
>> > Guillaume
>> >
>> > 2016-01-22 8:49 GMT+01:00 Guillaume Nodet <gno...@apache.org> > gno...@apache.org>>:
>> >
>> > > +1
>> > >
>> > > 2016-01-15 16:11 GMT+01:00 Guillaume Nodet <gno...@apache.org> > gno...@apache.org>>:
>> > >
>> > >> I uploaded a 1.1.0 release of SSHD.
>> > >> The artefacts are available at
>> > >>
>> > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__repository.apa
>> > >> che.org_content_repositories_orgapachemina-2D1016=BQIFaQ=Sqcl0E
>> > >> z6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oP
>> > >> rfu1Vne__JKwWQvo=hO8ouGNC29ftfGPtcWXT6N7wDUBwbaGNGZY5yU9wYEs=Lz
>> > >> 9QjBz7bwKC85p4Xxw1m3m0kjCvCixTubsHsNmD8Nw=
>> > <
>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__repository.apache
>> > .org_content_repositories_orgapachemina-2D1016=BQMFaQ=Sqcl0Ez6M0X8
>> > aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__
>> > JKwWQvo=Y8cE5-QYm0_O523fmZ9b2-wL30Dt622_jZYvF0AySXs=qofjyILYMVN1zB
>> > iYycg9MwCcYwF0Gr9DxBy8L0CzRvQ=
>> > >
>> > >>
>> > >> Release notes:
>> > >>
>> > >>
>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org
>> > _jira_secure_ReleaseNote.jspa-3FprojectId-3D12310849-26version-3D12333
>> > 293=BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv
>> > 55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=hO8ouGNC29ftfGPtcWXT6N7wDUBwbaGNG
>> > ZY5yU9wYEs=w-E-CLEfyLoSPujfpivMlg0A0gjU-DgPh22i_Bw9VeU=
>> > <
>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org
>> > _jira_secure_ReleaseNote.jspa-3FprojectId-3D12310849-26version-3D12333
>> > 293=BQMFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv
>> > 55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=Y8cE5-QYm0_O523fmZ9b2-wL30Dt622_j
>> > ZYvF0AySXs=1u66Pm-61NArw43ePAfjsXHvbJM2XF8neH4ffbg0e6I=
>> > >
>> > >>
>> > >> Please review and vote.
>> > >>
>> > >> Cheers,
>> > >> Guillaume Nodet
>> > >>
>> > >
>> > >
>> >
>> >
>> >
>> > --
>> > Jeff MAURY
>> >
>> >
>> > "Legacy code" often differs from its suggested alternative by actually
>> > working and scaling.
>> >  - Bjarne Stroustrup
>> >
>> > https://urldefense.proofpoint.com/v2/url?u=http

Re: [VOTE] MINA 2.0.11 release

[Jeff MAURY]

+1

Jeff

On Fri, Jan 22, 2016 at 7:51 PM, Mondain <mond...@gmail.com> wrote:

> +1
>
>
> On Fri, Jan 22, 2016 at 1:05 PM Jeff Genender <jgenen...@apache.org>
> wrote:
>
> > +1
> >
> > Jeff
> >
> > > On Jan 22, 2016, at 10:33 AM, Emmanuel Lécharny <elecha...@gmail.com>
> > wrote:
> > >
> > > Hi,
> > >
> > > Here is a vote for a new bug fix release of Mina : 2.0.11.
> > >
> > > This mainly fixes a bug in the SslHandler, which might cause a loop in
> > some corner cases.
> > >
> > > The Javadoc has also be improved so that all the missing annotations
> > (@param, @return)
> > > are now present.
> > >
> > > Here is the list of fixed issues :
> > >
> > > Bugs :
> > > --
> > >
> > > [DIRMINA-1023 <https://issues.apache.org/jira/browse/DIRMINA-1023;>]
> > Infinite loop in SslHandler when the AppBuffer is too small
> > > <https://issues.apache.org/jira/browse/DIRMINA-1023>
> > > [DIRMINA-1022 <https://issues.apache.org/jira/browse/DIRMINA-1022;>]
> > The IoBuffer.fill(byte, int) method does not work when byte > 0x7F
> > >
> > >
> > > A temporary tag has been created (it can be removed if the vote is not
> > > approved):
> > >
> > > - GIT tag : "2.0.11" SHA-1 : "0b348ccd3aa8ed2776b4d0de1f477c90b4ba51f9"
> > >
> > > Project: http://git-wip-us.apache.org/repos/asf/mina/repo
> > > Commit:http://git-wip-us.apache.org/repos/asf/mina/commit/0b348ccd
> > > Tree:http://git-wip-us.apache.org/repos/asf/mina/tree/0b348ccd
> > >
> > >
> > > - Nexus repository:
> > https://repository.apache.org/content/repositories/orgapachemina-1017
> > >
> > > - Binaries:http://people.apache.org/~elecharny
> > >
> > > Let us vote :
> > > [ ] +1 | Release MINA 2.0.11
> > > [ ] ± | Abstain
> > > [ ] -1 | Do **NOT**  release MINA 2.0.11
> > >
> > > Thanks !
> > >
> > > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
> > >
> >
> >
>



-- 
Jeff MAURY


"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

Re: [VOTE] Release SSHD 1.1.0

[Jeff MAURY]

Working on it this morning.
Already a remark: in NOTICE.txt it says copyright 2008 - 2015 shoud be 2008
- 2016

On Fri, Jan 22, 2016 at 8:50 AM, Guillaume Nodet <gno...@apache.org> wrote:

> I think we're still missing at least one binding vote ...
>
> Guillaume
>
> 2016-01-22 8:49 GMT+01:00 Guillaume Nodet <gno...@apache.org>:
>
> > +1
> >
> > 2016-01-15 16:11 GMT+01:00 Guillaume Nodet <gno...@apache.org>:
> >
> >> I uploaded a 1.1.0 release of SSHD.
> >> The artefacts are available at
> >>   https://repository.apache.org/content/repositories/orgapachemina-1016
> >>
> >> Release notes:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310849=12333293
> >>
> >> Please review and vote.
> >>
> >> Cheers,
> >> Guillaume Nodet
> >>
> >
> >
>



-- 
Jeff MAURY


"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

Re: [VOTE] Release SSHD 1.1.0

[Jeff MAURY]

Hello,

I tried to build on a Windows workstation and I got failed tests. See the
attached log. Please note that I am administrator of my machine.

Regards
Jeff


On Fri, Jan 22, 2016 at 10:10 AM, Jeff MAURY <jeffma...@jeffmaury.com>
wrote:

> Working on it this morning.
> Already a remark: in NOTICE.txt it says copyright 2008 - 2015 shoud be
> 2008 - 2016
>
> On Fri, Jan 22, 2016 at 8:50 AM, Guillaume Nodet <gno...@apache.org>
> wrote:
>
>> I think we're still missing at least one binding vote ...
>>
>> Guillaume
>>
>> 2016-01-22 8:49 GMT+01:00 Guillaume Nodet <gno...@apache.org>:
>>
>> > +1
>> >
>> > 2016-01-15 16:11 GMT+01:00 Guillaume Nodet <gno...@apache.org>:
>> >
>> >> I uploaded a 1.1.0 release of SSHD.
>> >> The artefacts are available at
>> >>
>> https://repository.apache.org/content/repositories/orgapachemina-1016
>> >>
>> >> Release notes:
>> >>
>> >>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310849=12333293
>> >>
>> >> Please review and vote.
>> >>
>> >> Cheers,
>> >> Guillaume Nodet
>> >>
>> >
>> >
>>
>
>
>
> --
> Jeff MAURY
>
>
> "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
>



-- 
Jeff MAURY


"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

Apache MINA - January 2016

[Jeff MAURY]

Hello,

please find the report I will submit to the board. Comments welcomed !!

## Description:
  Apache MINA is a network application framework which helps users
develop high performance and high scalability network applications
easily.

## Issues:
 There are no issues requiring board attention at this time

## Activity:
 Apache MINA 2.0.10 has been released on December 16th, 2015. It addresses
mainly performance and concurrent related problems.
 Apache MINA SSHD is about to release 1.1.0 in the next fews days.

## Health report:
 Project activitity is broadly the same as previous quarters, in all the
various categories (commits, JIRA tickets, mails).

## PMC changes:

 - Currently 10 PMC members.
 - No new PMC members added in the last 3 months
 - Last PMC addition was Jean-François Maury on Mon Apr 07 2014

## Committer base changes:

 - Currently 26 committers.
 - No new committers added in the last 3 months
 - Last committer addition was Lyor Goldstein at Thu Apr 30 2015

## Releases:

 - Apache MINA 2.0.10 was released on Wed Dec 16 2015

## Mailing list activity:

 - us...@mina.apache.org:
- 498 subscribers (down -3 in the last 3 months):
- 78 emails sent to list (108 in previous quarter)

 - dev@mina.apache.org:
- 358 subscribers (down -6 in the last 3 months):
- 597 emails sent to list (344 in previous quarter)

 - ftpserver-us...@mina.apache.org:
- 138 subscribers (up 0 in the last 3 months):
- 1 emails sent to list (5 in previous quarter)


## JIRA activity:

 - 57 JIRA tickets created in the last 3 months
 - 53 JIRA tickets closed/resolved in the last 3 months

-- 
Jeff MAURY


"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

Re: MINA build with Java 8

[Jeff MAURY]

Given the Java5 minimum requirement for MINA, can't we have an annotation.

Jeff

On Thu, Dec 17, 2015 at 2:08 PM, Emmanuel Lécharny <elecha...@gmail.com>
wrote:

> Le 17/12/15 13:49, Jeff MAURY a écrit :
> > Agree that we should adopt Java8 standards related to JavaDoc.
> > I think we should have a CI job that does the check from now, even if it
> > fails until we finished what you propose.
>
> Actually, the pb is just when we run mvn site (which makes sense,
> because this is where we build the javadoc).
>
> There are many tags seen as invalid, like :
>
> [ERROR]
>
> /Users/elecharny/mina/mina/mina-2.0/mina-core/src/main/java/org/apache/mina/core/service/AbstractIoAcceptor.java:131:
> error: unknown tag: org.apache.xbean.Property
>
> ...
> /**
>  * A base implementation of {@link IoAcceptor}.
>  *
>  * @author http://mina.apache.org;>Apache MINA Project
>  * @org.apache.xbean.XBean
>  */
> public abstract class AbstractIoAcceptor extends AbstractIoService
> implements IoAcceptor {
> ...
>
> I'm not sure how we can fix that.
>
>
>


-- 
Jeff MAURY


"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

Re: MINA build with Java 8

[Jeff MAURY]

Agree that we should adopt Java8 standards related to JavaDoc.
I think we should have a CI job that does the check from now, even if it
fails until we finished what you propose.

Jeff

On Thu, Dec 17, 2015 at 1:23 PM, Emmanuel Lécharny <elecha...@gmail.com>
wrote:

> Hi guys,
>
> Java 8 is pretty picky when it comes to Javadoc. In order to cut the
> latest release, I had to add this line in the main pom.xml :
>
> -Xdoclint:none
>
> At this point, I think that we should benefit from the strictness of Java
> 8 and get the Javadoc fixed for the next release. That would have the side
> benefit of also make our doco better...
>
> It mightbe a good idea for the other projects and versions to do the same
> (tedious) work.
>
> thoughts ?
>
>
>


-- 
Jeff MAURY


"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

Re: MINA build with Java 8

[Jeff MAURY]

I was looking for an annotation to replace the javadoc comment specific to
Xbean.

Jeff

On Thu, Dec 17, 2015 at 2:34 PM, Lyor Goldstein <lgoldst...@vmware.com>
wrote:

> Agreed, I just thought you were looking for an annotation - and this a
> built-in one, which means that by a simple 'grep' you can find all the
> place where it exists and handle each of them individually.
>
> -Original Message-
> From: jeffma...@gmail.com [mailto:jeffma...@gmail.com] On Behalf Of Jeff
> MAURY
> Sent: Thursday, December 17, 2015 15:32
> To: dev <dev@mina.apache.org>
> Subject: Re: MINA build with Java 8
>
> On Thu, Dec 17, 2015 at 2:20 PM, Lyor Goldstein <lgoldst...@vmware.com>
> wrote:
>
> > I think there is @SuppressWarning("javadoc") available...
> >
> We don't want that as it will not fix the real problem.
>
> Jeff
>
> >
> > -----Original Message-
> > From: jeffma...@gmail.com [mailto:jeffma...@gmail.com] On Behalf Of
> > Jeff MAURY
> > Sent: Thursday, December 17, 2015 15:17
> > To: dev <dev@mina.apache.org>
> > Subject: Re: MINA build with Java 8
> >
> > Given the Java5 minimum requirement for MINA, can't we have an
> annotation.
> >
> > Jeff
> >
> > On Thu, Dec 17, 2015 at 2:08 PM, Emmanuel Lécharny
> > <elecha...@gmail.com>
> > wrote:
> >
> > > Le 17/12/15 13:49, Jeff MAURY a écrit :
> > > > Agree that we should adopt Java8 standards related to JavaDoc.
> > > > I think we should have a CI job that does the check from now, even
> > > > if it fails until we finished what you propose.
> > >
> > > Actually, the pb is just when we run mvn site (which makes sense,
> > > because this is where we build the javadoc).
> > >
> > > There are many tags seen as invalid, like :
> > >
> > > [ERROR]
> > >
> > >
> >
> /Users/elecharny/mina/mina/mina-2.0/mina-core/src/main/java/org/apache/mina/core/service/AbstractIoAcceptor.java:131:
> > > error: unknown tag: org.apache.xbean.Property
> > >
> > > ...
> > > /**
> > >  * A base implementation of {@link IoAcceptor}.
> > >  *
> > >  * @author  > > href="https://urldefense.proofpoint.com/v2/url?u=http-3A__mina.apache.
> > > org=BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLK
> > > Xv
> > > 55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=G2at91n6XJRjtcyuVvVicyab3oTiZEl
> > > h5 9QAm64_qwQ=KY4Wxmwf00ZyM0ciXDyGvUDYc0yB02fpbmyHdTYzHNM=
> > > ">Apache MINA Project
> > >  * @org.apache.xbean.XBean
> > >  */
> > > public abstract class AbstractIoAcceptor extends AbstractIoService
> > > implements IoAcceptor { ...
> > >
> > > I'm not sure how we can fix that.
> > >
> > >
> > >
> >
> >
> > --
> > Jeff MAURY
> >
> >
> > "Legacy code" often differs from its suggested alternative by actually
> > working and scaling.
> >  - Bjarne Stroustrup
> >
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jeffmaury.com;
> > d=BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xA
> > mksY4SsQcYP_oPrfu1Vne__JKwWQvo=G2at91n6XJRjtcyuVvVicyab3oTiZElh59QAm
> > 64_qwQ=YxvALbj5IKZc9h_RKWUyEkQIGOHdkfSWlz3eqFHEZdA=
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__riadiscuss.jeffmau
> > ry.com=BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGL
> > KXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=G2at91n6XJRjtcyuVvVicyab3oTiZE
> > lh59QAm64_qwQ=MmCBiCpSKq5tUCLYwaeDuhPqesPFbXGaylDf-naQ5UE=
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_je
> > ffmaury=BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsG
> > LKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=G2at91n6XJRjtcyuVvVicyab3oTiZ
> > Elh59QAm64_qwQ=sgRYQQSaUoCyPfXJFn_suT3QVhrFrVN2o-s3voOe1F4=
> >
>
>
>
> --
> Jeff MAURY
>
>
> "Legacy code" often differs from its suggested alternative by actually
> working and scaling.
>  - Bjarne Stroustrup
>
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jeffmaury.com=BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=xyy_gt2-gfvyhH0YLU-ZTt0UDJobGo8FQS-9VXIhpKo=wHzQejl3i60sU7lgIvAo6twCnRDvV7lQs93HUNaNKi8=
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__riadiscuss.jeffmaury.com=BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=xyy_gt2-gfvyhH0YLU-ZTt0UDJobGo8FQS-9VXIhpKo=18O_5yMCC4k0hnV1diKoDr5mDs_dw8e_dOJz9yZJNU4=
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_jeffmaury=BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=xyy_gt2-gfvyhH0YLU-ZTt0UDJobGo8FQS-9VXIhpKo=vD2vorYhk4iZ5Pod4lD3gNhRSWQxW1QIe0t_FFNIBmM=
>



-- 
Jeff MAURY


"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

Re: MINA build with Java 8

[Jeff MAURY]

On Thu, Dec 17, 2015 at 2:20 PM, Lyor Goldstein <lgoldst...@vmware.com>
wrote:

> I think there is @SuppressWarning("javadoc") available...
>
We don't want that as it will not fix the real problem.

Jeff

>
> -Original Message-
> From: jeffma...@gmail.com [mailto:jeffma...@gmail.com] On Behalf Of Jeff
> MAURY
> Sent: Thursday, December 17, 2015 15:17
> To: dev <dev@mina.apache.org>
> Subject: Re: MINA build with Java 8
>
> Given the Java5 minimum requirement for MINA, can't we have an annotation.
>
> Jeff
>
> On Thu, Dec 17, 2015 at 2:08 PM, Emmanuel Lécharny <elecha...@gmail.com>
> wrote:
>
> > Le 17/12/15 13:49, Jeff MAURY a écrit :
> > > Agree that we should adopt Java8 standards related to JavaDoc.
> > > I think we should have a CI job that does the check from now, even
> > > if it fails until we finished what you propose.
> >
> > Actually, the pb is just when we run mvn site (which makes sense,
> > because this is where we build the javadoc).
> >
> > There are many tags seen as invalid, like :
> >
> > [ERROR]
> >
> >
> /Users/elecharny/mina/mina/mina-2.0/mina-core/src/main/java/org/apache/mina/core/service/AbstractIoAcceptor.java:131:
> > error: unknown tag: org.apache.xbean.Property
> >
> > ...
> > /**
> >  * A base implementation of {@link IoAcceptor}.
> >  *
> >  * @author  > href="https://urldefense.proofpoint.com/v2/url?u=http-3A__mina.apache.
> > org=BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv
> > 55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=G2at91n6XJRjtcyuVvVicyab3oTiZElh5
> > 9QAm64_qwQ=KY4Wxmwf00ZyM0ciXDyGvUDYc0yB02fpbmyHdTYzHNM= ">Apache
> > MINA Project
> >  * @org.apache.xbean.XBean
> >  */
> > public abstract class AbstractIoAcceptor extends AbstractIoService
> > implements IoAcceptor { ...
> >
> > I'm not sure how we can fix that.
> >
> >
> >
>
>
> --
> Jeff MAURY
>
>
> "Legacy code" often differs from its suggested alternative by actually
> working and scaling.
>  - Bjarne Stroustrup
>
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jeffmaury.com=BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=G2at91n6XJRjtcyuVvVicyab3oTiZElh59QAm64_qwQ=YxvALbj5IKZc9h_RKWUyEkQIGOHdkfSWlz3eqFHEZdA=
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__riadiscuss.jeffmaury.com=BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=G2at91n6XJRjtcyuVvVicyab3oTiZElh59QAm64_qwQ=MmCBiCpSKq5tUCLYwaeDuhPqesPFbXGaylDf-naQ5UE=
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_jeffmaury=BQIFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvo=G2at91n6XJRjtcyuVvVicyab3oTiZElh59QAm64_qwQ=sgRYQQSaUoCyPfXJFn_suT3QVhrFrVN2o-s3voOe1F4=
>



-- 
Jeff MAURY


"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

Re: [VOTE] MINA 2.0.10 release

[Jeff MAURY]

Sorry for being late as I'm out. Let move to +0 and me create the JIRA.

Regards
Jeff


On Tue, Dec 15, 2015 at 11:11 AM, Emmanuel Lécharny <elecha...@gmail.com>
wrote:

> Hi Jeff,
>
> I'd like to know if you hold on your -1 vote. Release vote are majority
> votes, there is no veto, but in this case, I think it's important to
> have your opinion. We have three options here :
> - You maintain your -1, and we bypass it. I think that would be the very
> first time, and would be bad taste, IMHO.
> - You maintain your -1, we cancel the vote and teh release, fix the pb,
> and cut a new release
> - You withdraw your -1, we create a JIRA, and get the issue fixed for
> 2.0.11
>
> I really think that the first option is a big no-no.
>
> So between the two other options, I let you decide. Both are fine.
>
> Thanks a lot !
>



-- 
Jeff MAURY


"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

Re: [VOTE] MINA 2.0.10 release

[Jeff MAURY]

Please find my following remarks:


   - mina-example: contains log4j.properties + MANIFEST.MF does not contain
   OSGI metadata
   - mina-integration-beans: import org.apache.mina.transport.vmpipe but
   not org.apache.mina.core packages, don't know if this is relevant
   - mina-integration-xbean: MANIFEST.MF does not contain OSGI metadata


So, for the last point, here is my -1

Jeff


On Mon, Dec 7, 2015 at 11:08 AM, Emmanuel Lecharny <elecha...@apache.org>
wrote:

> Hi,
>
> Here is a vote for a new bug fix release of Mina 2 : 2.0.10.
>
> No new features, but a few critical fixes :
>
> - a race condition in the SSL handler
>
> - some OSGi package declaration fixes
>
> - removed a lock in the decoder, speeding up MINA.
>
> Here is the list of fixed issues :
> Improvements :
> --
>
> [DIRMINA-1018 <https://issues.apache.org/jira/browse/DIRMINA-1018
> ">]FetchAppBuffer
> shrink
> [DIRMINA-1020 <https://issues.apache.org/jira/browse/DIRMINA-1020;>]Change
> minimum version for slf4j in MANIFEST
>
> Bugs :
> --
>
> [DIRMINA-992 <https://issues.apache.org/jira/browse/DIRMINA-992;>]
> NioSocketConnector.newHandle throws the wrong exception
> [DIRMINA-994 <https://issues.apache.org/jira/browse/DIRMINA-994;>] The
> ConnectionRequest.cancel() method is inconsistent wrt concurrent
> access
> [DIRMINA-995 <https://issues.apache.org/jira/browse/DIRMINA-995;>]
> Deadlock when using SSL and proxy
> [DIRMINA-1013 <https://issues.apache.org/jira/browse/DIRMINA-1013;>]
> Threading model is supressed by ProtocolCodecFilter
> [DIRMINA-1016 <https://issues.apache.org/jira/browse/DIRMINA-1016;>]
> Regression with 2.0.9: Missing javax.net.ssl import in manifest
> [DIRMINA-1017 <https://issues.apache.org/jira/browse/DIRMINA-1017;>]
> SSLEngine BUFFER_OVERFLOW (unwrap)
> [DIRMINA-1019 <https://issues.apache.org/jira/browse/DIRMINA-1019;>]
> SslHandler flushScheduledEvents race condition
>
>
> A temporary tag has been created (it can be removed if the vote is not
> approved):
>
> - GIT tag : "2.0.10" SHA-1 : "d0263e8a00cf6e60d18317d1e8899554c53083bc"
>
> Project: http://git-wip-us.apache.org/repos/asf/mina/repo
> Commit:http://git-wip-us.apache.org/repos/asf/mina/commit/d0263e8a
> Tree:http://git-wip-us.apache.org/repos/asf/mina/tree/d0263e8a
>
>
> - Nexus repository:
> https://repository.apache.org/content/repositories/orgapachemina-1015
>
> -Binaries:http://people.apache.org/~elecharny
>
> Let us vote :
> [ ] +1 | Release MINA 2.0.10
> [ ] ± | Abstain
> [ ] -1 | Do **NOT**  release MINA 2.0.10
>
> Thanks !
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>



-- 
Jeff MAURY


"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

[jira] [Created] (SSHD-568) Update web site

[Jeff MAURY (JIRA)]

Jeff MAURY created SSHD-568:
---

 Summary: Update web site
 Key: SSHD-568
 URL: https://issues.apache.org/jira/browse/SSHD-568
 Project: MINA SSHD
  Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Jeff MAURY


Update web site to reflect the release of 1.1.0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release SSHD 1.0.0 (2nd try)

[Jeff MAURY]

+1 (Windows 8.1 / Java 1.8.0_51)

Jeff

On Thu, Sep 3, 2015 at 9:17 AM, Emmanuel Lécharny <elecha...@gmail.com>
wrote:

> Le 03/09/15 06:35, Lyor Goldstein a écrit :
> > That's strange (see below) - I noticed you are using Java 8 to compile
> whereas we use Java 7. It should not matter - e.g., I also use (sometimes)
> Java 8 and have had no problems.
> >
> > - Have you tried running only this test (see below) ?
> > - Maybe your host is too "weak" or too busy and you are hitting some
> internal JSch timeout ?
>
>
> I'll do the test when back home (on the road today...) Sorry for the delay.
>
>
>


-- 
Jeff MAURY


"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

[SITE] Site enhancemens

[Jeff MAURY]

Hello,

I received a mail from the infra team suggesting to update Apache TLP sites
regarding DDOS attacks. I'm volontering to work on it but I never worked on
MINA site so if there are pointers I will be happy to read them and train
them as well.

Regards
Jeff

-- 
Jeff MAURY


"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

[jira] [Commented] (DIRMINA-1017) SSLEngine BUFFER_OVERFLOW (unwrap)

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644127#comment-14644127
 ] 

Jeff MAURY commented on DIRMINA-1017:
-

OK no problem this was just for clarification. We'll publish the code as it is 
an optimization (less loops)

 SSLEngine BUFFER_OVERFLOW (unwrap)
 --

 Key: DIRMINA-1017
 URL: https://issues.apache.org/jira/browse/DIRMINA-1017
 Project: MINA
  Issue Type: Bug
  Components: SSL
Affects Versions: 2.0.9
 Environment: Android
Reporter: Terence Marks
 Fix For: 2.0.10

   Original Estimate: 24h
  Remaining Estimate: 24h

 I've discovered an issue with the SslHandler class when the unwrap method is 
 called on the local SSLEngine member (SslHandler.sslEngine). 
 If the returned status is SSLEngineResult.Status.BUFFER_OVERFLOW, the 
 capacity of the output buffer (SslHandler.appBuffer) can be increased to a 
 size which still may is not large enough for the result.
 I have reproduced this issue consistently by sending a 4k frame over TLS1.2 
 to an android device. The frame gets heavily fragmented, sometimes into 6 
 frames, and the SSLEngine does not unwrap the frame until all the bytes have 
 been received (since the hash is based on the entire frame).
 Since the frame gets heavily fragmented, the last segment of the frame can be 
 lower than 2048 bytes. Hence by increasing the capacity by  1, the output 
 buffer will still be under the required size. (Have a look through SslHandler 
 source for appBuffer.capacity(appBuffer.capacity()  1);)
 Anyway, the fix is really easy. Change the line:
 appBuffer.capacity(appBuffer.capacity()  1);
 to:
 appBuffer.capacity(sslEngine.getSession().getApplicationBufferSize());
 This is actually in the java docs 
 (http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLEngine.html) for 
 the overflow buffer case.
 Hope this helps,
 Terence



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRMINA-1017) SSLEngine BUFFER_OVERFLOW (unwrap)

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644119#comment-14644119
 ] 

Jeff MAURY commented on DIRMINA-1017:
-

I agree with you patch but, in my opinion, there is something broken with the 
Android SSL/TLS implementation. Can you confirm the MINA code is running on 
Android ?

 SSLEngine BUFFER_OVERFLOW (unwrap)
 --

 Key: DIRMINA-1017
 URL: https://issues.apache.org/jira/browse/DIRMINA-1017
 Project: MINA
  Issue Type: Bug
  Components: SSL
Affects Versions: 2.0.9
 Environment: Android
Reporter: Terence Marks
 Fix For: 2.0.10

   Original Estimate: 24h
  Remaining Estimate: 24h

 I've discovered an issue with the SslHandler class when the unwrap method is 
 called on the local SSLEngine member (SslHandler.sslEngine). 
 If the returned status is SSLEngineResult.Status.BUFFER_OVERFLOW, the 
 capacity of the output buffer (SslHandler.appBuffer) can be increased to a 
 size which still may is not large enough for the result.
 I have reproduced this issue consistently by sending a 4k frame over TLS1.2 
 to an android device. The frame gets heavily fragmented, sometimes into 6 
 frames, and the SSLEngine does not unwrap the frame until all the bytes have 
 been received (since the hash is based on the entire frame).
 Since the frame gets heavily fragmented, the last segment of the frame can be 
 lower than 2048 bytes. Hence by increasing the capacity by  1, the output 
 buffer will still be under the required size. (Have a look through SslHandler 
 source for appBuffer.capacity(appBuffer.capacity()  1);)
 Anyway, the fix is really easy. Change the line:
 appBuffer.capacity(appBuffer.capacity()  1);
 to:
 appBuffer.capacity(sslEngine.getSession().getApplicationBufferSize());
 This is actually in the java docs 
 (http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLEngine.html) for 
 the overflow buffer case.
 Hope this helps,
 Terence



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRMINA-1016) Regression with 2.0.9: Missing javax.net.ssl import in manifest

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642020#comment-14642020
 ] 

Jeff MAURY commented on DIRMINA-1016:
-

Peter,

patch has been committed, you can find the latest build JAR at 
https://repository.apache.org/content/repositories/snapshots/org/apache/mina/mina-core/2.0.10-SNAPSHOT/mina-core-2.0.10-20150726.091142-1.jar
Please let us know if this fix the problem.

 Regression with 2.0.9: Missing javax.net.ssl import in manifest
 ---

 Key: DIRMINA-1016
 URL: https://issues.apache.org/jira/browse/DIRMINA-1016
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.9
 Environment: Karaf 3.0.3, Camel 2.15.2, Java 1.8.0_45
Reporter: Peter Berkman
  Labels: OSGi, SSL, SSLException

 see 
 http://camel.465427.n5.nabble.com/MINA-TLS-Silent-Error-when-trying-to-load-a-MINA-route-with-TLS-td5769456.html
 in mina-core 2.0.7, it imports javax.net.ssl: 
 Import-Package: javax.crypto,javax.crypto.spec,javax.net.ssl,javax.secur 
  ity.sasl,org.ietf.jgss,org.slf4j;version=[1.6,2) 
 in mina-core 2.09, it only imports: 
 Import-Package: org.slf4j;version=1.7.7 
 Is no one else having this problem? 
 Exception: 
 org.osgi.framework.BundleException: Activator start error in bundle 
 com.nextgate.ms.components.adapters.ngms-listener-hl7v2-mllp [348]. 
 at 
 org.apache.felix.framework.Felix.activateBundle(Felix.java:2196)[org.apache.felix.framework-4.2.1.jar:]
  
 at 
 org.apache.felix.framework.Felix.startBundle(Felix.java:2064)[org.apache.felix.framework-4.2.1.jar:]
  
 at 
 org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1291)[org.apache.felix.framework-4.2.1.jar:]
  
 at 
 org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)[org.apache.felix.framework-4.2.1.jar:]
  
 at java.lang.Thread.run(Unknown Source)[:1.8.0_45] 
 Caused by: java.lang.NoClassDefFoundError: javax/net/ssl/SSLException 
 at 
 org.apache.camel.component.mina2.Mina2Consumer.setupSocketProtocol(Mina2Consumer.java:194)
  
 at 
 org.apache.camel.component.mina2.Mina2Consumer.init(Mina2Consumer.java:87) 
 at 
 org.apache.camel.component.mina2.Mina2Endpoint.createConsumer(Mina2Endpoint.java:59)
  
 at 
 org.apache.camel.impl.EventDrivenConsumerRoute.addServices(EventDrivenConsumerRoute.java:65)
  
 at 
 org.apache.camel.impl.DefaultRoute.onStartingServices(DefaultRoute.java:85) 
 at org.apache.camel.impl.RouteService.warmUp(RouteService.java:158) 
 at 
 org.apache.camel.impl.DefaultCamelContext.doWarmUpRoutes(DefaultCamelContext.java:3090)
  
 at 
 org.apache.camel.impl.DefaultCamelContext.safelyStartRouteServices(DefaultCamelContext.java:3020)
  
 at 
 org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRoutes(DefaultCamelContext.java:2797)
  
 at 
 org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:2653)
  
 at 
 org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:167)
  
 at 
 org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2467)
  
 at 
 org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2463)
  
 at 
 org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:2486)
  
 at 
 org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:2463)
  
 at 
 org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) 
 at 
 org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:2432)
  
 at 
 com.nextgate.ms.bundlelib.interfaces.NGMSBundleActivator.startup(NGMSBundleActivator.java:81)
  
 at 
 com.nextgate.ms.component.adapter.listener.hl7mllp.routes.Activator.start(Activator.java:58)
  
 at 
 org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
  
 at org.apache.felix.framework.Felix.activateBundle(Felix.java:2146) 
 ... 4 more 
 Caused by: java.lang.ClassNotFoundException: javax.net.ssl.SSLException not 
 found by org.apache.mina.core [75] 
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)[org.apache.felix.framework-4.2.1.jar:]
  
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)[org.apache.felix.framework-4.2.1.jar:]
  
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)[org.apache.felix.framework-4.2.1.jar:]
  
 at java.lang.ClassLoader.loadClass(Unknown Source)[:1.8.0_45] 
 ... 25 more

[jira] [Commented] (DIRMINA-1016) Regression with 2.0.9: Missing javax.net.ssl import in manifest

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14641540#comment-14641540
 ] 

Jeff MAURY commented on DIRMINA-1016:
-

Will submit a path but have you problems only with core

 Regression with 2.0.9: Missing javax.net.ssl import in manifest
 ---

 Key: DIRMINA-1016
 URL: https://issues.apache.org/jira/browse/DIRMINA-1016
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.9
 Environment: Karaf 3.0.3, Camel 2.15.2, Java 1.8.0_45
Reporter: Peter Berkman
  Labels: OSGi, SSL, SSLException

 see 
 http://camel.465427.n5.nabble.com/MINA-TLS-Silent-Error-when-trying-to-load-a-MINA-route-with-TLS-td5769456.html
 in mina-core 2.0.7, it imports javax.net.ssl: 
 Import-Package: javax.crypto,javax.crypto.spec,javax.net.ssl,javax.secur 
  ity.sasl,org.ietf.jgss,org.slf4j;version=[1.6,2) 
 in mina-core 2.09, it only imports: 
 Import-Package: org.slf4j;version=1.7.7 
 Is no one else having this problem? 
 Exception: 
 org.osgi.framework.BundleException: Activator start error in bundle 
 com.nextgate.ms.components.adapters.ngms-listener-hl7v2-mllp [348]. 
 at 
 org.apache.felix.framework.Felix.activateBundle(Felix.java:2196)[org.apache.felix.framework-4.2.1.jar:]
  
 at 
 org.apache.felix.framework.Felix.startBundle(Felix.java:2064)[org.apache.felix.framework-4.2.1.jar:]
  
 at 
 org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1291)[org.apache.felix.framework-4.2.1.jar:]
  
 at 
 org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)[org.apache.felix.framework-4.2.1.jar:]
  
 at java.lang.Thread.run(Unknown Source)[:1.8.0_45] 
 Caused by: java.lang.NoClassDefFoundError: javax/net/ssl/SSLException 
 at 
 org.apache.camel.component.mina2.Mina2Consumer.setupSocketProtocol(Mina2Consumer.java:194)
  
 at 
 org.apache.camel.component.mina2.Mina2Consumer.init(Mina2Consumer.java:87) 
 at 
 org.apache.camel.component.mina2.Mina2Endpoint.createConsumer(Mina2Endpoint.java:59)
  
 at 
 org.apache.camel.impl.EventDrivenConsumerRoute.addServices(EventDrivenConsumerRoute.java:65)
  
 at 
 org.apache.camel.impl.DefaultRoute.onStartingServices(DefaultRoute.java:85) 
 at org.apache.camel.impl.RouteService.warmUp(RouteService.java:158) 
 at 
 org.apache.camel.impl.DefaultCamelContext.doWarmUpRoutes(DefaultCamelContext.java:3090)
  
 at 
 org.apache.camel.impl.DefaultCamelContext.safelyStartRouteServices(DefaultCamelContext.java:3020)
  
 at 
 org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRoutes(DefaultCamelContext.java:2797)
  
 at 
 org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:2653)
  
 at 
 org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:167)
  
 at 
 org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2467)
  
 at 
 org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2463)
  
 at 
 org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:2486)
  
 at 
 org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:2463)
  
 at 
 org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) 
 at 
 org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:2432)
  
 at 
 com.nextgate.ms.bundlelib.interfaces.NGMSBundleActivator.startup(NGMSBundleActivator.java:81)
  
 at 
 com.nextgate.ms.component.adapter.listener.hl7mllp.routes.Activator.start(Activator.java:58)
  
 at 
 org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
  
 at org.apache.felix.framework.Felix.activateBundle(Felix.java:2146) 
 ... 4 more 
 Caused by: java.lang.ClassNotFoundException: javax.net.ssl.SSLException not 
 found by org.apache.mina.core [75] 
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)[org.apache.felix.framework-4.2.1.jar:]
  
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)[org.apache.felix.framework-4.2.1.jar:]
  
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)[org.apache.felix.framework-4.2.1.jar:]
  
 at java.lang.ClassLoader.loadClass(Unknown Source)[:1.8.0_45] 
 ... 25 more 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [MINA3] HTTP/2 thoughts

[Jeff MAURY]

The idea is to provide a helper function like:

HTTP2Session http2Session = HTTP2Session.from(minaSession)

and you should call this method from a SessionCreated event.

The HTTP2Session should provide the following methods:

   - HTTP2Stream createStream();
   - void close();
   - void addHTTP2Listenener(HTTP2Listener listener);
   - and more to be discussed


Regards
Jeff

On Sun, Jun 28, 2015 at 7:45 AM, Emmanuel Lécharny elecha...@gmail.com
wrote:

 Le 27/06/15 19:17, Jeff MAURY a écrit :
  Hello,
 
  I am thinking about the HTTP/2 implementation we might have in MINA3 and
 I
  want to share it with you.
  As of yet, we have a basic HTTP/2 layer that just encode and decode
 HTTP/2
  frames. This is not enough as the user has to manage the conversion
 between
  HTTP/1.x PDUs (requests and responses) and HTTP/2 frames. No talking
 about
  the flow control management.
  We need to expose HTTP/2 streams to the user: I see to possible
  implementations:
 
 1. transmit the stream ID in HTTP/1.x messages but this will break the
 read-only nature of the those messages as the stream ID is created
 when a
 new HTTP request is sent
 2. Provider an HTTP/2 view of the MINA session where the user could
 allocate streams and also receive notification for new streams (in
 case of
 server push). This HTTP/2 view will be provided through an helper
 method.

 I would favor the second approach. The key here would be to generate
 this notification, which should somehow fit with teh way MINA works (we
 currentlysupport a set of events, which is not extensible). Would you do
 that through the SessionCreated event ?




-- 
Jeff MAURY


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

[MINA3] HTTP/2 thoughts

[Jeff MAURY]

Hello,

I am thinking about the HTTP/2 implementation we might have in MINA3 and I
want to share it with you.
As of yet, we have a basic HTTP/2 layer that just encode and decode HTTP/2
frames. This is not enough as the user has to manage the conversion between
HTTP/1.x PDUs (requests and responses) and HTTP/2 frames. No talking about
the flow control management.
We need to expose HTTP/2 streams to the user: I see to possible
implementations:

   1. transmit the stream ID in HTTP/1.x messages but this will break the
   read-only nature of the those messages as the stream ID is created when a
   new HTTP request is sent
   2. Provider an HTTP/2 view of the MINA session where the user could
   allocate streams and also receive notification for new streams (in case of
   server push). This HTTP/2 view will be provided through an helper method.

WDYT ?
Jeff

-- 
Jeff MAURY


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

[jira] [Commented] (DIRMINA-934) Replace synchronized with a Semaphore for better performance

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584118#comment-14584118
 ] 

Jeff MAURY commented on DIRMINA-934:


Emmanuel,

I think I got your point. The idea behind the decoderOut is that it is 
currently implemented as a queue of generated messages that are sent to the 
next filter upon flush. The problem is that as it is bound to the session, then 
we need a lock in case 2 ProcotolCodec filters got executed concurrently.
My proposition is the following:
 * remove the synchronisation
 * replace the getDecoderOut by an overriding method (it is private in 2.0 so 
it cannot be overriden) and remove the session storage and return a new object 
each time it is called.

 Replace synchronized with a Semaphore for better performance
 

 Key: DIRMINA-934
 URL: https://issues.apache.org/jira/browse/DIRMINA-934
 Project: MINA
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.0.7, 2.0.8
 Environment: Window 8 Pro x64, JDK 7
Reporter: Paul Gregoire
  Labels: patch
 Fix For: 2.0.8

 Attachments: ProtocolCodecFilterWithSemaphoreAndMore.diff

   Original Estimate: 2h
  Remaining Estimate: 2h

 Replacing the synchronized block with a Semaphore in the ProtocolCodecFilter 
 provides a lot of benefit in terms of locking and also reduces CPU 
 utilization. See attached git diff.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRMINA-934) Replace synchronized with a Semaphore for better performance

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582462#comment-14582462
 ] 

Jeff MAURY commented on DIRMINA-934:


What about:
  removing the synchronization
  removing the decoder output from the session and replace by a local decoder 
out (that is in all cases flushed ie emptied at the end of the decoding phase

 Replace synchronized with a Semaphore for better performance
 

 Key: DIRMINA-934
 URL: https://issues.apache.org/jira/browse/DIRMINA-934
 Project: MINA
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.0.7, 2.0.8
 Environment: Window 8 Pro x64, JDK 7
Reporter: Paul Gregoire
  Labels: patch
 Fix For: 2.0.8

 Attachments: ProtocolCodecFilterWithSemaphoreAndMore.diff

   Original Estimate: 2h
  Remaining Estimate: 2h

 Replacing the synchronized block with a Semaphore in the ProtocolCodecFilter 
 provides a lot of benefit in terms of locking and also reduces CPU 
 utilization. See attached git diff.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: OpenHub

[Jeff MAURY]

I did not see the new git repo to be set at openhub.
Did anyone of yours with an account take action ?

Regards
Jeff

On Sat, Mar 28, 2015 at 1:12 PM, Emmanuel Lecharny elecha...@apache.org
wrote:

 Sure.

 Le samedi 28 mars 2015, Jeff MAURY jeffma...@jeffmaury.com a écrit :

  Hello,
 
  I noticed that Apache MINA is available at the OpenHUB site but it
 appears
  the code location is the SVN one and not the Git one thus statistics are
  wrong.
  I tried to add one but it requires to have an OpenHub account and it
 seems
  it is not possible to create account (feature is suspended).
  Does anyone of yours have one and can make the modification ?
 
  Regards
  Jeff
 
 
  --
  Jeff MAURY
 
 
  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
 


 --
 Regards,
 Cordialement,
 Emmanuel Lécharny
 www.iktek.com




-- 
Jeff MAURY


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

Board report

[Jeff MAURY]

Hello,

please find the draft for the report I plan to send to the board for the
April 15th, 2015 meeting.
Comments welcome

Regards
Jeff

Apache MINA is a network application framework which helps users
develop high performance and high scalability network applications
easily.

-- Community --
* No new committers (Last addition, october 2013)
* No new PMC member (Last addition october 2014)

Users mailing list :
Feb 2015 : 486 subscribers (64 emails)
April 2015: 489 subscribers (84 emails)

Dev mailing list :
Feb 2015 : 383 subscribers (326 emails)
April 2015: 374 subscribers (395 emails)

ftpserver-users mailing list:
Feb 2015: 139 subscribers (6 emails)
April 2015: 140 subscribers (8 emails)

Jean-François Maury has been approved by the board as the new MINA Chairman.

-- Current activity --

Some work has been initiated to get 2.0.10 release, but reverted, due to
some API modification. The release has still to be completed.

Apache SSHd 0.14.0 has been released.

A slow quarter, so to speak. The only two projects that saw
activity are MINA and SSHd.


* Apache MINA :
 * MINA 2.0.9 has been released in october 2014

* Apache SSHd:
 * SSHD 0.14.0 has been released in march 2015

* Apache FtpServer:
 * No activity if the past 3 months

* Apache Vysper :
 * Nothing done

* Apache AsyncWeb:
 * No activity.

-- Releases --
* SSHD 0.14.0 has been released.

-- JIRA activity --
63 JIRA tickets created in the last 3 months
59 JIRA tickets closed/resolved in the last 3 months

-- 
Jeff MAURY


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

Re: Board report

[Jeff MAURY]

No new committer is reported by reporter.apache.org.
If you've got a name or a mail, I'll take it.
I'll check in my mails

Regards
Jeff

On Fri, Apr 3, 2015 at 5:47 AM, Ashish paliwalash...@gmail.com wrote:

 We did vote for new committer. Does that count?

 On Fri, Apr 3, 2015 at 4:46 AM, Emmanuel Lécharny elecha...@gmail.com
 wrote:
  Sounds good to me.
 
  Thanks Jeff !
 
 
  Le 02/04/15 22:43, Jeff MAURY a écrit :
  Hello,
 
  please find the draft for the report I plan to send to the board for the
  April 15th, 2015 meeting.
  Comments welcome
 
  Regards
  Jeff
 
  Apache MINA is a network application framework which helps users
  develop high performance and high scalability network applications
  easily.
 
  -- Community --
  * No new committers (Last addition, october 2013)
  * No new PMC member (Last addition october 2014)
 
  Users mailing list :
  Feb 2015 : 486 subscribers (64 emails)
  April 2015: 489 subscribers (84 emails)
 
  Dev mailing list :
  Feb 2015 : 383 subscribers (326 emails)
  April 2015: 374 subscribers (395 emails)
 
  ftpserver-users mailing list:
  Feb 2015: 139 subscribers (6 emails)
  April 2015: 140 subscribers (8 emails)
 
  Jean-François Maury has been approved by the board as the new MINA
 Chairman.
 
  -- Current activity --
 
  Some work has been initiated to get 2.0.10 release, but reverted, due to
  some API modification. The release has still to be completed.
 
  Apache SSHd 0.14.0 has been released.
 
  A slow quarter, so to speak. The only two projects that saw
  activity are MINA and SSHd.
 
 
  * Apache MINA :
   * MINA 2.0.9 has been released in october 2014
 
  * Apache SSHd:
   * SSHD 0.14.0 has been released in march 2015
 
  * Apache FtpServer:
   * No activity if the past 3 months
 
  * Apache Vysper :
   * Nothing done
 
  * Apache AsyncWeb:
   * No activity.
 
  -- Releases --
  * SSHD 0.14.0 has been released.
 
  -- JIRA activity --
  63 JIRA tickets created in the last 3 months
  59 JIRA tickets closed/resolved in the last 3 months
 
 



 --
 thanks
 ashish

 Blog: http://www.ashishpaliwal.com/blog
 My Photo Galleries: http://www.pbase.com/ashishpaliwal




-- 
Jeff MAURY


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

OpenHub

[Jeff MAURY]

Hello,

I noticed that Apache MINA is available at the OpenHUB site but it appears
the code location is the SVN one and not the Git one thus statistics are
wrong.
I tried to add one but it requires to have an OpenHub account and it seems
it is not possible to create account (feature is suspended).
Does anyone of yours have one and can make the modification ?

Regards
Jeff


-- 
Jeff MAURY


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

[jira] [Assigned] (DIRMINA-1008) fromHexString converts non-hex Strings to ByteBuffer

[Jeff MAURY (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff MAURY reassigned DIRMINA-1008:
---

Assignee: Jeff MAURY

 fromHexString converts non-hex Strings to ByteBuffer
 

 Key: DIRMINA-1008
 URL: https://issues.apache.org/jira/browse/DIRMINA-1008
 Project: MINA
  Issue Type: Bug
  Components: Core
Reporter: nullpointer
Assignee: Jeff MAURY
 Fix For: 3.0.0-trunk


 I came across this by accident in class org.apache.mina.util.ByteBufferDumper:
 [fromHexString|https://git-wip-us.apache.org/repos/asf?p=mina.git;a=blob;f=core/src/main/java/org/apache/mina/util/ByteBufferDumper.java;h=e351a139a4a13a2028f55898716e19f21a33a4d4;hb=HEAD#l138]
  happily converts Strings like ff, fa, f2 and not a hex string to bytes.
 Here is a suggestion for curing the problem:
 {code}
   public static ByteBuffer fromHexString(final String hex) {
 if (null == hex) {
   throw new IllegalArgumentException(
   null argument not permitted);
 } else if (hex.length() % 2 != 0) {
   throw new IllegalArgumentException(
   the hexadecimal string length cannot be odd);
 }
 int size = hex.length() / 2;
 ByteBuffer res = ByteBuffer.allocate(size);
 for (int i = 0; i  hex.length(); i += 2) {
   int b = Integer.parseInt(hex.substring(i, i + 2), 16);
   if (Integer.highestOneBit(b) == 128) {
 b = b - 256;
   }
   res.put((byte) b);
 }
 res.flip();
 return res;
  }
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DIRMINA-1008) fromHexString converts non-hex Strings to ByteBuffer

[Jeff MAURY (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff MAURY updated DIRMINA-1008:

Fix Version/s: 3.0.0-trunk

 fromHexString converts non-hex Strings to ByteBuffer
 

 Key: DIRMINA-1008
 URL: https://issues.apache.org/jira/browse/DIRMINA-1008
 Project: MINA
  Issue Type: Bug
  Components: Core
Reporter: nullpointer
 Fix For: 3.0.0-trunk


 I came across this by accident in class org.apache.mina.util.ByteBufferDumper:
 [fromHexString|https://git-wip-us.apache.org/repos/asf?p=mina.git;a=blob;f=core/src/main/java/org/apache/mina/util/ByteBufferDumper.java;h=e351a139a4a13a2028f55898716e19f21a33a4d4;hb=HEAD#l138]
  happily converts Strings like ff, fa, f2 and not a hex string to bytes.
 Here is a suggestion for curing the problem:
 {code}
   public static ByteBuffer fromHexString(final String hex) {
 if (null == hex) {
   throw new IllegalArgumentException(
   null argument not permitted);
 } else if (hex.length() % 2 != 0) {
   throw new IllegalArgumentException(
   the hexadecimal string length cannot be odd);
 }
 int size = hex.length() / 2;
 ByteBuffer res = ByteBuffer.allocate(size);
 for (int i = 0; i  hex.length(); i += 2) {
   int b = Integer.parseInt(hex.substring(i, i + 2), 16);
   if (Integer.highestOneBit(b) == 128) {
 b = b - 256;
   }
   res.put((byte) b);
 }
 res.flip();
 return res;
  }
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[MINA 3] ProtocolCodecFilter: encoder/decoder state stored under a constant key

[Jeff MAURY]

Hello,

I looked at the ProcolCodecFilter code and I discovered that the
encoder/decoder states are stored in the session using a constant key. So
what if a user will chain two ProtocolCodecFilter ? Am I missing something ?

Jeff

-- 
Jeff MAURY


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

[MINA 3] ProtocolEncoder and ProtocolDecoder

[Jeff MAURY]

Hello,

I am working on the HTTP2 implementation for MINA. In HTTP2, the state is
attached to the connection as there is some flow control and multiplexing
on top of the HTTP2 socket.
So, it is difficult for me to use the codec framework as there is no way to
access the MINA session when the state is created. So I intent to add
access to the MINA session in the create...State methods.
WDYT ?
Jeff

-- 
Jeff MAURY


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

[jira] [Commented] (FTPSERVER-467) plain text injection during initialization of encrypted channel

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/FTPSERVER-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1434#comment-1434
 ] 

Jeff MAURY commented on FTPSERVER-467:
--

According to your client code, the plain text message is sent in the same TCP 
message as the START TLS message. So I don't think this is a case for injection 
because TLS will be started after the TCP message (containing both START TLS 
and text message) has been received. Or the server side should probably reject 
the remaining part of the message when processing START TLS.

 plain text injection during initialization of encrypted channel
 ---

 Key: FTPSERVER-467
 URL: https://issues.apache.org/jira/browse/FTPSERVER-467
 Project: FtpServer
  Issue Type: Bug
Reporter: alexander todorov

 Hi, 
 We have plain text injection problem with mina 2.0.4 (It is reproducible with 
 2.0.9 as well).
 This is the problem
 The FTP client sends the commands:
 auth tls\r\nfeat
 and the feat command is executed.
 It became obvious, that the output was received encrypted. However, the 
 command was sent unencrypted. In general, it is possible to inject commands 
 in plain-text during the initialization of the encrypted 
 channel. This can be abused for attacks against the user.
 All unencrypted commands that are send after “auth tls” must be ignored.
 Do you plan to fix this issue ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FTPSERVER-467) plain text injection during initialization of encrypted channel

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/FTPSERVER-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14336495#comment-14336495
 ] 

Jeff MAURY commented on FTPSERVER-467:
--

Who's in charge of handling the message where AUTH TLS appears ? FtpServer ? 
Another piece of code ?

 plain text injection during initialization of encrypted channel
 ---

 Key: FTPSERVER-467
 URL: https://issues.apache.org/jira/browse/FTPSERVER-467
 Project: FtpServer
  Issue Type: Bug
Reporter: alexander todorov

 Hi, 
 We have plain text injection problem with mina 2.0.4 (It is reproducible with 
 2.0.9 as well).
 This is the problem
 The FTP client sends the commands:
 auth tls\r\nfeat
 and the feat command is executed.
 It became obvious, that the output was received encrypted. However, the 
 command was sent unencrypted. In general, it is possible to inject commands 
 in plain-text during the initialization of the encrypted 
 channel. This can be abused for attacks against the user.
 All unencrypted commands that are send after “auth tls” must be ignored.
 Do you plan to fix this issue ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRMINA-1007) plain text injection during initialization of encrypted channel

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1485#comment-1485
 ] 

Jeff MAURY commented on DIRMINA-1007:
-

I did not get that you were using MINA FtpServer. You should move the issue to 
https://issues.apache.org/jira/browse/FTPSERVER instead

 plain text injection during initialization of encrypted channel
 ---

 Key: DIRMINA-1007
 URL: https://issues.apache.org/jira/browse/DIRMINA-1007
 Project: MINA
  Issue Type: Bug
Reporter: alexander todorov

 Hi, 
 We have plain text injection problem with mina 2.0.4 (It is reproducible with 
 2.0.9 as well).
 This is the problem
 The FTP client sends the commands:
 auth tls\r\nfeat
 and the feat command is executed.
 It became obvious, that the output was received encrypted. However, the 
 command was sent unencrypted. In general, it is possible to inject commands 
 in plain-text during the initialization of the encrypted 
 channel. This can be abused for attacks against the user.
 All unencrypted commands that are send after “auth tls” must be ignored.
 Do you plan to fix this issue ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRMINA-1007) plain text injection during initialization of encrypted channel

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1471#comment-1471
 ] 

Jeff MAURY commented on DIRMINA-1007:
-

So my undertstanding is that the MINA code is on the server side and should 
handle the AUTH TLS message. Can you give us you server code ?

 plain text injection during initialization of encrypted channel
 ---

 Key: DIRMINA-1007
 URL: https://issues.apache.org/jira/browse/DIRMINA-1007
 Project: MINA
  Issue Type: Bug
Reporter: alexander todorov

 Hi, 
 We have plain text injection problem with mina 2.0.4 (It is reproducible with 
 2.0.9 as well).
 This is the problem
 The FTP client sends the commands:
 auth tls\r\nfeat
 and the feat command is executed.
 It became obvious, that the output was received encrypted. However, the 
 command was sent unencrypted. In general, it is possible to inject commands 
 in plain-text during the initialization of the encrypted 
 channel. This can be abused for attacks against the user.
 All unencrypted commands that are send after “auth tls” must be ignored.
 Do you plan to fix this issue ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: New to Open Source Community

[Jeff MAURY]

You should first:

1) read the project documentation (mina.apache.org)
2) analyze the source code
2) look into JIRA and submit patches.

Regards
Jeff

On Mon, Feb 23, 2015 at 8:04 PM, Vibhor Sharma 
vibhormagotra...@yahoo.com.invalid wrote:

  Hello everyone.
 I'm new here to Apache and I would like to contribute and learn
 simultaneously on the way being a beginner in programming and open source.
 How should I start working on codes?
 Any Suggestions would be appreciated.Warm Regards




-- 
Jeff MAURY


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

[jira] [Commented] (DIRMINA-1007) plain text injection during initialization of encrypted channel

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14332090#comment-14332090
 ] 

Jeff MAURY commented on DIRMINA-1007:
-

the code that does the plain text injection

 plain text injection during initialization of encrypted channel
 ---

 Key: DIRMINA-1007
 URL: https://issues.apache.org/jira/browse/DIRMINA-1007
 Project: MINA
  Issue Type: Bug
Reporter: alexander todorov

 Hi, 
 We have plain text injection problem with mina 2.0.4 (It is reproducible with 
 2.0.9 as well).
 This is the problem
 The FTP client sends the commands:
 auth tls\r\nfeat
 and the feat command is executed.
 It became obvious, that the output was received encrypted. However, the 
 command was sent unencrypted. In general, it is possible to inject commands 
 in plain-text during the initialization of the encrypted 
 channel. This can be abused for attacks against the user.
 All unencrypted commands that are send after “auth tls” must be ignored.
 Do you plan to fix this issue ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRMINA-1007) plain text injection during initialization of encrypted channel

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14330106#comment-14330106
 ] 

Jeff MAURY commented on DIRMINA-1007:
-

Can you give code sample or logs ?

 plain text injection during initialization of encrypted channel
 ---

 Key: DIRMINA-1007
 URL: https://issues.apache.org/jira/browse/DIRMINA-1007
 Project: MINA
  Issue Type: Bug
Reporter: alexander todorov

 Hi, 
 We have plain text injection problem with mina 2.0.4 (It is reproducible with 
 2.0.9 as well).
 This is the problem
 The FTP client sends the commands:
 auth tls\r\nfeat
 and the feat command is executed.
 It became obvious, that the output was received encrypted. However, the 
 command was sent unencrypted. In general, it is possible to inject commands 
 in plain-text during the initialization of the encrypted 
 channel. This can be abused for attacks against the user.
 All unencrypted commands that are send after “auth tls” must be ignored.
 Do you plan to fix this issue ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRMINA-1005) SSL write blocked on Android

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302965#comment-14302965
 ] 

Jeff MAURY commented on DIRMINA-1005:
-

Is there a reason you're using 2.0.7 ? 

 SSL write blocked on Android
 

 Key: DIRMINA-1005
 URL: https://issues.apache.org/jira/browse/DIRMINA-1005
 Project: MINA
  Issue Type: Bug
  Components: SSL
Affects Versions: 2.0.7
 Environment: Android
Reporter: zphreg

 I'm developing an Android app using Apache Mina for network IO. Non-SSL 
 connections (reading, writing) work fine, but as soon as I add an SSL filter 
 things stop working. I also tried pure SSL sockets and they work fine.
 final byte[] TEST_TEXT = new byte[]{
 'a', '\n'
 };
 ..
 connectorTLSFilter = new SslFilter(BogusSslContextFactory
 .getInstance(false));
 connectorTLSFilter.setUseClientMode(true);
 connector.getFilterChain().addFirst(SSL, connectorTLSFilter);
 connector.setHandler(new MinaClientHandler());
 ConnectFuture future = connector.connect(new 
 InetSocketAddress(192.168.0.10, 443));
 future.awaitUninterruptibly();
 Log.v(ssl, handshake sucess);
 IoSession session = future.getSession();
 IoBuffer buf = IoBuffer.allocate(TEST_TEXT.length);
 buf.put(TEST_TEXT);
 buf.flip();
 Log.v(ssl,sending);
 session.write(buf).awaitUninterruptibly();
 Log.v(ssl,sent);
 =
 Blocked at sending



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: mina git commit: [maven-release-plugin] prepare for next development iteration

[Jeff MAURY]

 --
 diff --git a/mina-integration-jmx/pom.xml b/mina-integration-jmx/pom.xml
 index cfe9c02..790d689 100644
 --- a/mina-integration-jmx/pom.xml
 +++ b/mina-integration-jmx/pom.xml
 @@ -24,7 +24,7 @@
parent
  groupIdorg.apache.mina/groupId
  artifactIdmina-parent/artifactId
 -version2.0.10/version
 +version2.0.11-SNAPSHOT/version
/parent

artifactIdmina-integration-jmx/artifactId


 http://git-wip-us.apache.org/repos/asf/mina/blob/4bb91e3d/mina-integration-ognl/pom.xml
 --
 diff --git a/mina-integration-ognl/pom.xml b/mina-integration-ognl/pom.xml
 index 7badf44..0aeaa34 100644
 --- a/mina-integration-ognl/pom.xml
 +++ b/mina-integration-ognl/pom.xml
 @@ -24,7 +24,7 @@
parent
  groupIdorg.apache.mina/groupId
  artifactIdmina-parent/artifactId
 -version2.0.10/version
 +version2.0.11-SNAPSHOT/version
/parent

artifactIdmina-integration-ognl/artifactId


 http://git-wip-us.apache.org/repos/asf/mina/blob/4bb91e3d/mina-integration-xbean/pom.xml
 --
 diff --git a/mina-integration-xbean/pom.xml
 b/mina-integration-xbean/pom.xml
 index cdeed1f..0b48a60 100644
 --- a/mina-integration-xbean/pom.xml
 +++ b/mina-integration-xbean/pom.xml
 @@ -24,7 +24,7 @@
parent
  groupIdorg.apache.mina/groupId
  artifactIdmina-parent/artifactId
 -version2.0.10/version
 +version2.0.11-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion



 http://git-wip-us.apache.org/repos/asf/mina/blob/4bb91e3d/mina-legal/pom.xml
 --
 diff --git a/mina-legal/pom.xml b/mina-legal/pom.xml
 index e855a9c..aac8821 100644
 --- a/mina-legal/pom.xml
 +++ b/mina-legal/pom.xml
 @@ -21,7 +21,7 @@
  parent
  groupIdorg.apache.mina/groupId
  artifactIdmina-parent/artifactId
 -version2.0.10/version
 +version2.0.11-SNAPSHOT/version
  /parent

  artifactIdmina-legal/artifactId


 http://git-wip-us.apache.org/repos/asf/mina/blob/4bb91e3d/mina-statemachine/pom.xml
 --
 diff --git a/mina-statemachine/pom.xml b/mina-statemachine/pom.xml
 index 1f4a2fb..ce9701d 100644
 --- a/mina-statemachine/pom.xml
 +++ b/mina-statemachine/pom.xml
 @@ -24,7 +24,7 @@
parent
  groupIdorg.apache.mina/groupId
  artifactIdmina-parent/artifactId
 -version2.0.10/version
 +version2.0.11-SNAPSHOT/version
/parent

artifactIdmina-statemachine/artifactId


 http://git-wip-us.apache.org/repos/asf/mina/blob/4bb91e3d/mina-transport-apr/pom.xml
 --
 diff --git a/mina-transport-apr/pom.xml b/mina-transport-apr/pom.xml
 index fb031f3..f1bdfe5 100644
 --- a/mina-transport-apr/pom.xml
 +++ b/mina-transport-apr/pom.xml
 @@ -22,7 +22,7 @@
parent
  groupIdorg.apache.mina/groupId
  artifactIdmina-parent/artifactId
 -version2.0.10/version
 +version2.0.11-SNAPSHOT/version
/parent

artifactIdmina-transport-apr/artifactId


 http://git-wip-us.apache.org/repos/asf/mina/blob/4bb91e3d/mina-transport-serial/pom.xml
 --
 diff --git a/mina-transport-serial/pom.xml b/mina-transport-serial/pom.xml
 index c52838c..589111e 100644
 --- a/mina-transport-serial/pom.xml
 +++ b/mina-transport-serial/pom.xml
 @@ -24,7 +24,7 @@
parent
  groupIdorg.apache.mina/groupId
  artifactIdmina-parent/artifactId
 -version2.0.10/version
 +version2.0.11-SNAPSHOT/version
/parent

artifactIdmina-transport-serial/artifactId

 http://git-wip-us.apache.org/repos/asf/mina/blob/4bb91e3d/pom.xml
 --
 diff --git a/pom.xml b/pom.xml
 index 34f7617..1ad8ee6 100644
 --- a/pom.xml
 +++ b/pom.xml
 @@ -38,7 +38,7 @@
/organization

groupIdorg.apache.mina/groupId
 -  version2.0.10/version
 +  version2.0.11-SNAPSHOT/version
artifactIdmina-parent/artifactId
nameApache MINA/name
packagingpom/packaging
 @@ -55,7 +55,7 @@
  connectionscm:git:https://git-wip-us.apache.org/repos/asf/mina.git
 /connection
  urlhttps://github.com/apache/mina/tree/2.0/url
  developerConnectionscm:git:
 https://git-wip-us.apache.org/repos/asf/mina.git/developerConnection
 -tag2.0.10/tag
 +tagHEAD/tag
/scm

distributionManagement




-- 
Jeff MAURY


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

Re: mina git commit: [maven-release-plugin] prepare for next development iteration

[Jeff MAURY]

+1 for 2 interfaces

Jeff

On Mon, Dec 22, 2014 at 11:36 AM, Emmanuel Lécharny elecha...@gmail.com
wrote:

 Le 22/12/14 11:26, Emmanuel Lécharny a écrit :
  Le 22/12/14 11:05, Emmanuel Lécharny a écrit :
  Le 22/12/14 10:28, Jeff MAURY a écrit :
  Given the fact that we introduced some kind of incompatibility (with
 2.0.9
  or 2.0.10), don't you think it would be valuable to witch to 2.1.X ?
  We probably should. My mistake would then be fixed.
 
 
  The real pb is that MOINA 2.0.8 broke the API, and if we switch to 2.1.0
  - the move we should have made back then - that would mean we should
  create a new branch 2.0.10 where we remove the change I intriduced in
  2.0.8. Here is the
 
 
  2.0.7 -+- 2.0.8 (whith API change, wrong) -- 2.0.9 (still wrong) --
  2.0.10 (dead branch)
 | \ |  \
 |  \|   \
 +---++
  2.0.10 (with a revert on the changed API)
 |
  |
 
 +-+
 
  +-- 2.1.0 ( with the API change)
 
  So if we cut 2 releases :
  * 2.0.10 which contains the change done in 2.0.8 and 2.0.9 but rollback
  the changes in teh API done in 2.0.8
  * 2.1.0 which is a branch done based on 2.0.10 but with the change done
  in the API
 
  do you think that is a viable solution ?
 
 
 Another option would be to add a new Interface in 2.0.10 that those who
 want to benefit from the /inputClosed() event will have to implement. We
 roll back the previous interface to what it was.
 /




-- 
Jeff MAURY


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

Re: mina git commit: [maven-release-plugin] prepare for next development iteration

[Jeff MAURY]

Done

Jeff

On Mon, Dec 22, 2014 at 11:57 AM, Emmanuel Lécharny elecha...@gmail.com
wrote:

 Le 22/12/14 11:39, Jeff MAURY a écrit :
  +1 for 2 interfaces

 Ok, I'll do that.

 Jeff, can you delete the tag I just created for MINA 2.0.10 ?

 Thanks !




-- 
Jeff MAURY


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

[MINA3] Jenkins

[Jeff MAURY]

Hello,

you should have notice that we received a bunch of failure emails from
Apache Jenkins. The reason is that I created two new jobs from checking
MINA3 against Java8 (one for Linux and one for Windows). The problem is
that Jenkins is not able to install the JDK on the Jenkins slave on
Windows. I am working with Infra to fix it so don't worry about that. I
will let you know when we can expect a normal behaviour.

Regards
Jeff

-- 
Jeff MAURY


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

[MINA3] SSL

[Jeff MAURY]

Hello,

I just committed a bunch of files with the work on the SSL I've been doing
recently.
There are still issues I want to discuss with you:

   - as the SSLEngine is record oriented, a message submitted for write may
   be splitted in several records, leading to several sentMessage events. Do
   you think we can keep the current behaviour or should be hide intermediate
   events and wait for the last record to be sent to generate the single event
   - When a close SSL even is received, an event is generated but the
   underlying transport is not closed: my intent is to provided automatic
   closing in a separate filter
   - In order to deal with all the TLS/SSL/POODLE isssues, I think this
   could be a good idea that the current SSL details ( protocol, algorithm) be
   provided in the handshake completed event so that we can provided better
   protection through the filter.

Regards
Jeff

-- 
Jeff MAURY


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

[jira] [Created] (DIRMINA-999) Session closed with immediate=false are not closed

[Jeff MAURY (JIRA)]

Jeff MAURY created DIRMINA-999:
--

 Summary: Session closed with immediate=false are not closed
 Key: DIRMINA-999
 URL: https://issues.apache.org/jira/browse/DIRMINA-999
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 3.0.0-M2
Reporter: Jeff MAURY
 Fix For: 3.0.0-M3


If a session is closed with immediate=false, then the internal session state is 
switched to CLOSING preventing further messages to be written, the internal 
message write queue is flushed but no close is ever processed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DIRMINA-999) Session closed with immediate=false does not send closed event

[Jeff MAURY (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff MAURY updated DIRMINA-999:
---
Description: If a session is closed with immediate=false, then the internal 
session state is switched to CLOSING preventing further messages to be written, 
the internal message write queue is flushed but no close event is ever sent  
(was: If a session is closed with immediate=false, then the internal session 
state is switched to CLOSING preventing further messages to be written, the 
internal message write queue is flushed but no close is ever processed)

 Session closed with immediate=false does not send closed event
 --

 Key: DIRMINA-999
 URL: https://issues.apache.org/jira/browse/DIRMINA-999
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 3.0.0-M2
Reporter: Jeff MAURY
 Fix For: 3.0.0-M3


 If a session is closed with immediate=false, then the internal session state 
 is switched to CLOSING preventing further messages to be written, the 
 internal message write queue is flushed but no close event is ever sent



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DIRMINA-999) Session closed with immediate=false does not send closed event

[Jeff MAURY (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff MAURY updated DIRMINA-999:
---
Summary: Session closed with immediate=false does not send closed event  
(was: Session closed with immediate=false are not closed)

 Session closed with immediate=false does not send closed event
 --

 Key: DIRMINA-999
 URL: https://issues.apache.org/jira/browse/DIRMINA-999
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 3.0.0-M2
Reporter: Jeff MAURY
 Fix For: 3.0.0-M3


 If a session is closed with immediate=false, then the internal session state 
 is switched to CLOSING preventing further messages to be written, the 
 internal message write queue is flushed but no close is ever processed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (DIRMINA-999) Session closed with immediate=false does not send closed event

[Jeff MAURY (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff MAURY reassigned DIRMINA-999:
--

Assignee: Jeff MAURY

 Session closed with immediate=false does not send closed event
 --

 Key: DIRMINA-999
 URL: https://issues.apache.org/jira/browse/DIRMINA-999
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 3.0.0-M2
Reporter: Jeff MAURY
Assignee: Jeff MAURY
 Fix For: 3.0.0-M3


 If a session is closed with immediate=false, then the internal session state 
 is switched to CLOSING preventing further messages to be written, the 
 internal message write queue is flushed but no close event is ever sent



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DIRMINA-999) Session closed with immediate=false does not send closed event

[Jeff MAURY (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff MAURY closed DIRMINA-999.
--
Resolution: Fixed

 Session closed with immediate=false does not send closed event
 --

 Key: DIRMINA-999
 URL: https://issues.apache.org/jira/browse/DIRMINA-999
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 3.0.0-M2
Reporter: Jeff MAURY
Assignee: Jeff MAURY
 Fix For: 3.0.0-M3


 If a session is closed with immediate=false, then the internal session state 
 is switched to CLOSING preventing further messages to be written, the 
 internal message write queue is flushed but no close event is ever sent



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRMINA-995) Deadlock when using SSL and proxy

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14211342#comment-14211342
 ] 

Jeff MAURY commented on DIRMINA-995:


Yes, the pattern is correct. We will investigate the lock problem.

 Deadlock when using SSL and proxy
 -

 Key: DIRMINA-995
 URL: https://issues.apache.org/jira/browse/DIRMINA-995
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.7
 Environment: JRE 1.6, Linux
Reporter: yzb81

 I write a SSL client to connect server through SOCKS5 proxy, then meet a 
 deadlock.
 Maybe the reason of deadlock is I write data to a IoSession in my main 
 thread, but now this session is reading data from socket.
 Found one Java-level deadlock:
 =
 NioProcessor-7:
   waiting to lock monitor 0x0940a8a8 (object 0x98732818, a 
 org.apache.mina.filter.ssl.SslHandler),
   which is held by Thread-102
 Thread-102:
   waiting to lock monitor 0x09e8128c (object 0x9873d750, a 
 org.apache.mina.proxy.handlers.socks.Socks5LogicHandler),
   which is held by NioProcessor-7
 Java stack information for the threads listed above:
 ===
 NioProcessor-7:
   at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:576)
   - waiting to lock 0x98732818 (a org.apache.mina.filter.ssl.SslHandler)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:482)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1400(DefaultIoFilterChain.java:47)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:775)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.filterWrite(DefaultIoFilterChain.java:705)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:482)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:475)
   at 
 org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:494)
   at 
 org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:439)
   at xxx.xxxProxyHandler.messageReceived(xxxProxyHandler.java:74)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:690)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:765)
   at 
 org.apache.mina.filter.ssl.SslHandler.flushScheduledEvents(SslHandler.java:322)
   at 
 org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:497)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:765)
   at 
 org.apache.mina.proxy.filter.ProxyFilter.messageReceived(ProxyFilter.java:153)
   - locked 0x9873d750 (a 
 org.apache.mina.proxy.handlers.socks.Socks5LogicHandler)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:765)
   at 
 org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:109)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:410)
   at 
 org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:710)
   at 
 org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:664)
   at 
 org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:653)
   at 
 org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:67)
   at 
 org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1124

[jira] [Commented] (DIRMINA-995) Deadlock when using SSL and proxy

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14207162#comment-14207162
 ] 

Jeff MAURY commented on DIRMINA-995:


Look at the code: seems user code is launching a thread that performs write 
operation.
Seems two filters are in the chain: SslFilter and ProxyFilter. Each of them are 
synchronized against their underlying handler.
Seems that filters are not called in the same order for read or write 
operations thus the lock

 Deadlock when using SSL and proxy
 -

 Key: DIRMINA-995
 URL: https://issues.apache.org/jira/browse/DIRMINA-995
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.7
 Environment: JRE 1.6, Linux
Reporter: yzb81

 I write a SSL client to connect server through SOCKS5 proxy, then meet a 
 deadlock.
 Maybe the reason of deadlock is I write data to a IoSession in my main 
 thread, but now this session is reading data from socket.
 Found one Java-level deadlock:
 =
 NioProcessor-7:
   waiting to lock monitor 0x0940a8a8 (object 0x98732818, a 
 org.apache.mina.filter.ssl.SslHandler),
   which is held by Thread-102
 Thread-102:
   waiting to lock monitor 0x09e8128c (object 0x9873d750, a 
 org.apache.mina.proxy.handlers.socks.Socks5LogicHandler),
   which is held by NioProcessor-7
 Java stack information for the threads listed above:
 ===
 NioProcessor-7:
   at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:576)
   - waiting to lock 0x98732818 (a org.apache.mina.filter.ssl.SslHandler)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:482)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1400(DefaultIoFilterChain.java:47)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:775)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.filterWrite(DefaultIoFilterChain.java:705)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:482)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:475)
   at 
 org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:494)
   at 
 org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:439)
   at xxx.xxxProxyHandler.messageReceived(xxxProxyHandler.java:74)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:690)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:765)
   at 
 org.apache.mina.filter.ssl.SslHandler.flushScheduledEvents(SslHandler.java:322)
   at 
 org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:497)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:765)
   at 
 org.apache.mina.proxy.filter.ProxyFilter.messageReceived(ProxyFilter.java:153)
   - locked 0x9873d750 (a 
 org.apache.mina.proxy.handlers.socks.Socks5LogicHandler)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:765)
   at 
 org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:109)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:410)
   at 
 org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:710)
   at 
 org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:664)
   at 
 org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:653

Re: Review DIRMINA-994

[Jeff MAURY]

Le Fri Nov 07 2014 at 07:57:09, Emmanuel Lécharny elecha...@gmail.com a
écrit :

 Le 07/11/14 07:30, Jeff MAURY a écrit :
  Le Fri Nov 07 2014 at 1:42:43 AM, Emmanuel Lécharny elecha...@gmail.com
 a
  écrit :
 
  Le 06/11/14 23:15, Jeff MAURY a écrit :
  Hello,
 
  upon Emmanuel's request, I reviewed the fix for DIRMINA-994
  (commit f1972fc3de8c4074ff7b60f8c557d3c53013e30b). Here are my
 remarks:
 
 - the Future framework in MINA2 is not linked in any form to JDK's
 Future, is there any reason for that ? I've seen that IOFuture in
  MINA3
 extends Future
  Java Future were introduced in hava 5. MINA was created with Java 1.4
  compatibility as a target.
 
  Can't accpet it, as MINA2 code uses generics.

 I'm just stating the fact that when future were introduced, we weren't
 using generic yet, because we wanted to keep the 1.4 compatibility. When
 we decided to switch to Java 5, we added generic, but kept Future.

 I'm not saying it was a smart move, this is just what happened. In
 retrospect, that was lazy.

 Keep in mind that MINA history is nearly 10 years old...

The purpose of my questions was indeed to try to get some historic info as
I'm quite new to MINA

Jeff

Review DIRMINA-994

[Jeff MAURY]

Hello,

upon Emmanuel's request, I reviewed the fix for DIRMINA-994
(commit f1972fc3de8c4074ff7b60f8c557d3c53013e30b). Here are my remarks:

   - the Future framework in MINA2 is not linked in any form to JDK's
   Future, is there any reason for that ? I've seen that IOFuture in MINA3
   extends Future
   - Regarding MINA3, I suggest that IOFuture's implementation should
   benefit from helper class AbstractQueuedSynchronizer (
   
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/AbstractQueuedSynchronizer.html).
   As MINA3 Future framework is linked to the JDK Future framework, the change
   should be quite small and simple. I will open a JIRA for that


Jeff

Re: Review DIRMINA-994

[Jeff MAURY]

Le Fri Nov 07 2014 at 1:42:43 AM, Emmanuel Lécharny elecha...@gmail.com a
écrit :

 Le 06/11/14 23:15, Jeff MAURY a écrit :
  Hello,
 
  upon Emmanuel's request, I reviewed the fix for DIRMINA-994
  (commit f1972fc3de8c4074ff7b60f8c557d3c53013e30b). Here are my remarks:
 
 - the Future framework in MINA2 is not linked in any form to JDK's
 Future, is there any reason for that ? I've seen that IOFuture in
 MINA3
 extends Future

 Java Future were introduced in hava 5. MINA was created with Java 1.4
 compatibility as a target.

Can't accpet it, as MINA2 code uses generics.




 - Regarding MINA3, I suggest that IOFuture's implementation should
 benefit from helper class AbstractQueuedSynchronizer (
 http://docs.oracle.com/javase/1.5.0/docs/api/java/util/
 concurrent/locks/AbstractQueuedSynchronizer.html).
 As MINA3 Future framework is linked to the JDK Future framework, the
 change
 should be quite small and simple. I will open a JIRA for that

 Ok.

 Thanks !

Re: [VOTE] MINA 2.0.9 release (take 2)

[Jeff MAURY]

+1

Jeff

On Wed, Oct 22, 2014 at 2:37 PM, Jeff Genender jgenen...@apache.org wrote:

 +1

 Jeff

  On Oct 21, 2014, at 11:22 PM, Emmanuel Lécharny elecha...@gmail.com
 wrote:
 
  Hi fellow developers !
 
  we were able to cut a new release one month after 2.0.8. It's a bug fix
  release, with very few fixes, but expected ones.
 
  This release was also a good opportunity to fix the release
  documentation on the web site, it was lacking critical informations.
 
  It has been tested against FtpServer, Sshd and Vysper, with no problem.
 
  Changelog:
 
 
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20DIRMINA%20AND%20fixVersion%20%3D%202.0.9%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC
 
  A temporary tag has been created (it can be removed if the vote is not
  approved):
 
  - GIT tag : 2.0.9 SHA-1 : 548a54d63595f2d3a526471ed7dc9fd7fdd137ba
 
  Project: http://git-wip-us.apache.org/repos/asf/mina/repo
  Commit:
 
 https://git-wip-us.apache.org/repos/asf?p=mina.git;a=commit;h=1f632420ac4fde88ba21d78ea721ebb2d24ea898
  Tree:
 
 https://git-wip-us.apache.org/repos/asf?p=mina.git;a=tree;h=0db6758945abca5df3bab5046a57d1756eb47f44;hb=1f632420ac4fde88ba21d78ea721ebb2d24ea898
 
 
  - Nexus repository:
  https://repository.apache.org/content/repositories/orgapachemina-1009
 
  -Binaries:
  http://people.apache.org/~elecharny
 
  Let us vote :
  [ ] +1 | Release MINA 2.0.9
  [ ] ± | Abstain
  [ ] -1 | Do *NOT*  release MINA 2.0.9
 
  Thanks !
  --
  Emmanuel Lécharny
 
 




-- 
Jeff MAURY


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

Re: [VOTE] MINA 2.0.9

[Jeff MAURY]

You are mentioning tag 2.0.8. I suppose this is 2.0.9

Jeff

On Sat, Oct 18, 2014 at 7:41 PM, Emmanuel Lécharny elecha...@gmail.com
wrote:

 Hi fellow developers !

 we were able to cut a new release one month after 2.0.8. It's a bug fix
 release, with very few fixes, but expected ones.

 This release was also a good opportunity to fix the release
 documentation on the web site, it was lacking critical informations.

 It has been tested against FtpServer, Sshd and Vysper, with no problem.

 Changelog:


 https://issues.apache.org/jira/issues/?jql=project%20%3D%20DIRMINA%20AND%20fixVersion%20%3D%202.0.9%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC

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

 - GIT tag : 2.0.8 SHA-1 : 1f632420ac4fde88ba21d78ea721ebb2d24ea898

 Project: http://git-wip-us.apache.org/repos/asf/mina/repo
 Commit:

 https://git-wip-us.apache.org/repos/asf?p=mina.git;a=commit;h=1f632420ac4fde88ba21d78ea721ebb2d24ea898
 Tree:

 https://git-wip-us.apache.org/repos/asf?p=mina.git;a=tree;h=0db6758945abca5df3bab5046a57d1756eb47f44;hb=1f632420ac4fde88ba21d78ea721ebb2d24ea898


 - Nexus repository:
 https://repository.apache.org/content/repositories/orgapachemina-1006

 -Binaries:
 http://people.apache.org/~elecharny

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

 Thanks !
 --
 Emmanuel Lécharny





-- 
Jeff MAURY


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

Re: More SSL thoughts

[Jeff MAURY]

On Sat, Oct 11, 2014 at 8:24 AM, Emmanuel Lécharny elecha...@gmail.com
wrote:

 Le 08/10/14 11:45, Jeff MAURY a écrit :
  On Wed, Oct 8, 2014 at 10:33 AM, Emmanuel Lécharny elecha...@gmail.com
  wrote:
 
  Le 07/10/14 23:37, Jeff MAURY a écrit :
  Hello,
 
  as I'm working on the SSL part this time and more specifically on the
  handshake/rehandshake processing, I have a couple of questions and some
  infos to share:
 
 - I've added 3 more methods in IoHandler to reflect handshake
 related
 event: handshakeStarted, handshakeCompleted and secureClosed. I've
  added
 them as well to IoFilter but I don't quite understand the philosophy
  as
 some method have a chain controller to call the next filter and some
  not
  The idea behind the chain of filters is that any event is propagated up
  to the final filter (ie, the Iohandler) by each filter. If one filter
  decide not to propagate the event, then obviously the IoHandler will not
  receive it. This is thus to the Filter implementer to be sure it does
  propagate the event to teh next filter. If it does not, this is either a
  mistake, or a decision that has to be heavily and carefully thought.
 
  The pb is to delegate this responsability to the filter. It would be
  easier if the controller was to propagate the event further without
  expecting teh filter to do so. That woudl require some careful rework of
  the controller, as in some case (like errors, exceptions, etc) we don't
  want to propagate the event.
 
  In some other cases, we simply want the filter to handle the event
  propagation (typically this is the case for the MessageReceived when we
  are using a decoder filter : there is no mean to propagate the event
  automatically if a full message has not been decocded).
 
  This is definitively something we want to think about.
 
  What I didn't understand is that not all of IOFilter method signatures
 have
  a ChainController so I did not understand how they can decide to swallow
  the event or not.

 Not sure what you mean by not all of IOFilter method signatures have a
 ChainController in Mina 2.0 context.

 The IoFilter class has 3 sets of methods :
 - methods that propagate an event :
   o exceptionCaugth
   o filterClose
   o filterWrite
   o inputClose
   o messageReceived
   o messageSent
   o sessionClosed
   o sessionCreated
   o sessionIdle
   o sessionOpened

I don't agree for MINA 3. See
https://github.com/apache/mina/blob/trunk/core/src/main/java/org/apache/mina/api/IoFilter.java



  Those methods have a NextFilter parameter, which is the filter that
 will receive the event, should the current filter decide to propagate
 it. This can be seen in, for instance, the BlackListFilter :

 public void messageSent(NextFilter nextFilter, IoSession session,
 WriteRequest writeRequest) throws Exception {
 if (!isBlocked(session)) {
 // forward if not blocked
 nextFilter.messageSent(session, writeRequest);
 } else {
 blockSession(session);
 }
 }


 - methods that manage the chain manipulation :
   o onPreAdd
   o onPostAdd
   o onPreRemove
   o onPostRemove

  Those methods just react on the addition or removal of the current
 filter from the session chain.

 - general methods :
   o init
   o destroy

  Those methods are called when the filter is created or destroyed.

 Note that all the filter extends the IoFilterAdapter which already have
 a default implementation for all those methods (hence it should be an
 abstract method, IMO).

 Is that what you wanted to get some clarification on ?

 
 - In order to support rehandshaking et being efficient, we must keep
  the
 same SSLEngine.
  Ok, makes sense.
  So my idea to start a new handshake was to reuse what we
 have today through the initSecure method: if the SSLContext is null,
  I don't see how we can have a null SSLContext, as we create it before
  creating the SSLFilter, and there is a check for nullity in this
  constructor :
 
  public SslFilter(SSLContext sslContext, boolean autoStart) {
  if (sslContext == null) {
  throw new IllegalArgumentException(sslContext);
  }
 
  Assuming we always have a not null SSLContext, how does it translates in
  your proposed algorithm ?


  I was mentioning the SSLContext that is the argument of the initSecure
  method. Please note that in 3.0, there is no more SSLFilter as SSL
 handling
  has been moved to core.
  So my idea is that if no SSLContext is given to initSecure and SSLHandler
  is attached to the session, we keep the same underlying SSLEngine and we
  start a new handshake

 I see. You propose to handle the handshake re-negociation through a call
 to a newly added method called initSecure( SslContext ) in MINA 2, is
 that correct ?

No, I was talking about MINA3 and about the semantic of this existing
method.

Jeff




-- 
Jeff MAURY


Legacy code often differs from its suggested alternative by actually
working

Re: More SSL thoughts

[Jeff MAURY]

On Wed, Oct 8, 2014 at 10:33 AM, Emmanuel Lécharny elecha...@gmail.com
wrote:

 Le 07/10/14 23:37, Jeff MAURY a écrit :
  Hello,
 
  as I'm working on the SSL part this time and more specifically on the
  handshake/rehandshake processing, I have a couple of questions and some
  infos to share:
 
 - I've added 3 more methods in IoHandler to reflect handshake related
 event: handshakeStarted, handshakeCompleted and secureClosed. I've
 added
 them as well to IoFilter but I don't quite understand the philosophy
 as
 some method have a chain controller to call the next filter and some
 not
 The idea behind the chain of filters is that any event is propagated up
 to the final filter (ie, the Iohandler) by each filter. If one filter
 decide not to propagate the event, then obviously the IoHandler will not
 receive it. This is thus to the Filter implementer to be sure it does
 propagate the event to teh next filter. If it does not, this is either a
 mistake, or a decision that has to be heavily and carefully thought.

 The pb is to delegate this responsability to the filter. It would be
 easier if the controller was to propagate the event further without
 expecting teh filter to do so. That woudl require some careful rework of
 the controller, as in some case (like errors, exceptions, etc) we don't
 want to propagate the event.

 In some other cases, we simply want the filter to handle the event
 propagation (typically this is the case for the MessageReceived when we
 are using a decoder filter : there is no mean to propagate the event
 automatically if a full message has not been decocded).

 This is definitively something we want to think about.

What I didn't understand is that not all of IOFilter method signatures have
a ChainController so I did not understand how they can decide to swallow
the event or not.


 - In order to support rehandshaking et being efficient, we must keep
 the
 same SSLEngine.
 Ok, makes sense.
  So my idea to start a new handshake was to reuse what we
 have today through the initSecure method: if the SSLContext is null,

 I don't see how we can have a null SSLContext, as we create it before
 creating the SSLFilter, and there is a check for nullity in this
 constructor :

 public SslFilter(SSLContext sslContext, boolean autoStart) {
 if (sslContext == null) {
 throw new IllegalArgumentException(sslContext);
 }

 Assuming we always have a not null SSLContext, how does it translates in
 your proposed algorithm ?

I was mentioning the SSLContext that is the argument of the initSecure
method. Please note that in 3.0, there is no more SSLFilter as SSL handling
has been moved to core.
So my idea is that if no SSLContext is given to initSecure and SSLHandler
is attached to the session, we keep the same underlying SSLEngine and we
start a new handshake

Jeff



-- 
Jeff MAURY


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

Re: Q: why is the KeepAliveHandler always return ReplyFailure ?

[Jeff MAURY]

Can you more precise ? What part of MINA are you talking about ?

Jeff

On Tue, Oct 7, 2014 at 11:50 AM, Lyor Goldstein lgoldst...@vmware.com
wrote:

 Shouldn't it return ReplySuccess ? After all, if its code has been reached
 then the server is alive...




-- 
Jeff MAURY


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

More SSL thoughts

[Jeff MAURY]

Hello,

as I'm working on the SSL part this time and more specifically on the
handshake/rehandshake processing, I have a couple of questions and some
infos to share:

   - I've added 3 more methods in IoHandler to reflect handshake related
   event: handshakeStarted, handshakeCompleted and secureClosed. I've added
   them as well to IoFilter but I don't quite understand the philosophy as
   some method have a chain controller to call the next filter and some not
   - In order to support rehandshaking et being efficient, we must keep the
   same SSLEngine. So my idea to start a new handshake was to reuse what we
   have today through the initSecure method: if the SSLContext is null, then
   the rehandkshake is started if we already have an initialized SSLHandler
   attached to the session. If SSLContext is null and no SSLHandler is
   attached to the session, then an exception (IllegalState ?) will be
   through. If an SSLContext is attached and an SSLHandler is attached to the
   session, then a new SSLEngine is build. WDYT ?


Jeff

-- 
Jeff MAURY


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

Re: [VOTE] MINA 2.0.8

[Jeff MAURY]

+1

Ran the build, plus Apache Camel and Google Gerrit builds modified to use
2.0.8

Jeff

On Tue, Sep 16, 2014 at 1:01 PM, Ashish paliwalash...@gmail.com wrote:

 +1

 Ran the build, works fine, all test cases pass

 Got 404 for http://people.apache.org/~elecharny/mina-2.0.8, downloaded src
 from http://people.apache.org/~elecharny/

 On Tue, Sep 16, 2014 at 4:48 AM, Emmanuel Lécharny elecha...@gmail.com
 wrote:

  Hi,
  It's 2 years we haven't had a release of MINA 2.0, it's about time.
 
 
  We have tried to fix as much issues as we could in the last 2 weeks. As a
  result, we have closed around 90 JIRAs.
 
  There is one change that might break the build for those switching from
  MINA 2.0.7 to MINA 2.0.8 : the IoHandler interface now has a method
 called
  inputClosed(), so either you have to implement this method if you are
  directly implementing the IoHandler interface, or better, you can extends
  IoHandlerAdapter, which implements a placeholder for this method.
 
  Changelog:
 
 
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20DIRMINA%20AND%20fixVersion%20%3D%202.0.8%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC
 
  A temporary tag has been created (it can be removed if the vote is not
  approved):
 
  - GIT tag : 2.0.8 SHA-1 : 50e417e8116ea1d0b6fe6b8c970e0594ef89f743
 
  Project: http://git-wip-us.apache.org/repos/asf/mina/repo
  Commit:
 
 https://git-wip-us.apache.org/repos/asf?p=mina.git;a=commit;h=50e417e8116ea1d0b6fe6b8c970e0594ef89f743
  Tree:
 
 https://git-wip-us.apache.org/repos/asf?p=mina.git;a=tree;h=ef06b2f03cfe979f35af98aa2af194e877b8fd5c;hb=50e417e8116ea1d0b6fe6b8c970e0594ef89f743
 
 
  - Nexus repository:
  https://repository.apache.org/content/repositories/orgapachemina-1005
 
  -Binaries:
  http://people.apache.org/~elecharny/mina-2.0.8
 
  Let us vote :
  [ ] +1 | Release MINA 2.0.8
  [ ] ± | Abstain
  [ ] -1 | Do *NOT*  release MINA 2.0.8
 
  Thanks !
  --
  Emmanuel Lécharny
 
 


 --
 thanks
 ashish

 Blog: http://www.ashishpaliwal.com/blog
 My Photo Galleries: http://www.pbase.com/ashishpaliwal




-- 
Jeff MAURY


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

Jenkins jobs failing when performing git tag

[Jeff MAURY]

Hello,

I noticed Mina Jenkins jobs randomly failed when performing the git tag
command.
I opened a JIRA on INFRA (https://issues.apache.org/jira/browse/BUILDS-20).
But does anyone of you knows why the tag option has been set for the MINA
jobs ?
I removed it for the MINA2 Windows job but should be do it also for other
jobs ?

Regards

-- 
Jeff MAURY


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

[jira] [Commented] (DIRMINA-927) NPE SSL Handshake

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14130583#comment-14130583
 ] 

Jeff MAURY commented on DIRMINA-927:


I would argue for a JDK problem as those kind of errors are likely to be 
handled as connection refusals.
But, according to the stack trace, I think we should check if exceptions 
returned by tasks are correctly handled by MINA code

 NPE SSL Handshake
 -

 Key: DIRMINA-927
 URL: https://issues.apache.org/jira/browse/DIRMINA-927
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.7
 Environment: * Linux version 3.4.2-linode44 (root@build) (gcc version 
 4.4.5 (Debian 4.4.5-8) ) #1 SMP Tue Jun 12 15:04:46 EDT 2012
 * Java(TM) SE Runtime Environment (build 1.6.0_33-b03)
 * Mina 2.0.7
Reporter: Célio Vasconcelos
  Labels: Handshake, NPE, SSL
 Fix For: 2.0.9


 This error occurs sometimes. 
 java.lang.RuntimeException: Delegated task threw Exception/Error
 at 
 com.sun.net.ssl.internal.ssl.Handshaker.checkThrown(Handshaker.java:1012)
 at 
 com.sun.net.ssl.internal.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:485)
 at 
 com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:753)
 at 
 com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:721)
 at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:607)
 at org.apache.mina.filter.ssl.SslHandler.unwrap(SslHandler.java:728)
 at 
 org.apache.mina.filter.ssl.SslHandler.unwrapHandshake(SslHandler.java:666)
 at 
 org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:552)
 at 
 org.apache.mina.filter.ssl.SslHandler.messageReceived(SslHandler.java:351)
 at 
 org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:468)
 at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
 at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47)
 at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:765)
 at 
 org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:109)
 at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
 at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:410)
 at 
 org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:710)
 at 
 org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:664)
 at 
 org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:653)
 at 
 org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:67)
 at 
 org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1124)
 at 
 org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)
 Caused by: java.lang.NullPointerException
 at 
 sun.security.internal.spec.TlsKeyMaterialParameterSpec.init(TlsKeyMaterialParameterSpec.java:69)
 at 
 com.sun.net.ssl.internal.ssl.Handshaker.calculateConnectionKeys(Handshaker.java:840)
 at 
 com.sun.net.ssl.internal.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:595)
 at 
 com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:151)
 at 
 com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
 at com.sun.net.ssl.internal.ssl.Handshaker$1.run(Handshaker.java:533)
 at java.security.AccessController.doPrivileged(Native Method)
 at 
 com.sun.net.ssl.internal.ssl.Handshaker$DelegatedTask.run(Handshaker.java:952)
 at org.apache.mina.filter.ssl.SslHandler.doTasks(SslHandler.java:759)
 at 
 org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:544)
 ... 17 more



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRMINA-784) Error with MDCInjectionFilter on Windows

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128640#comment-14128640
 ] 

Jeff MAURY commented on DIRMINA-784:


Build is OK on my Windows7 machine. Maybe we should reactivate the Jenkins 
Windows build to check it in a long term

 Error with MDCInjectionFilter on Windows
 

 Key: DIRMINA-784
 URL: https://issues.apache.org/jira/browse/DIRMINA-784
 Project: MINA
  Issue Type: Bug
Affects Versions: 2.0.0-RC1
Reporter: Emmanuel Lecharny
Assignee: Ashish Paliwal
 Fix For: 2.0.9


 One test is randomly failing on Windows only :
 http://hudson.zones.apache.org/hudson/job/MINA-trunk-jdk1.6-windows/lastBuild/org.apache.mina$mina-core/testReport/org.apache.mina.filter.logging/MdcInjectionFilterTest/testOnlyRemoteAddress/
 It may be the test which is broken, or something we added since the last 
 version, as it was working in 2.0.0-RC1



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRMINA-784) Error with MDCInjectionFilter on Windows

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128672#comment-14128672
 ] 

Jeff MAURY commented on DIRMINA-784:


I enabled the Windows build, it is now OK, we should wait a few builds before 
switching to resolved.

 Error with MDCInjectionFilter on Windows
 

 Key: DIRMINA-784
 URL: https://issues.apache.org/jira/browse/DIRMINA-784
 Project: MINA
  Issue Type: Bug
Affects Versions: 2.0.0-RC1
Reporter: Emmanuel Lecharny
Assignee: Ashish Paliwal
 Fix For: 2.0.9


 One test is randomly failing on Windows only :
 http://hudson.zones.apache.org/hudson/job/MINA-trunk-jdk1.6-windows/lastBuild/org.apache.mina$mina-core/testReport/org.apache.mina.filter.logging/MdcInjectionFilterTest/testOnlyRemoteAddress/
 It may be the test which is broken, or something we added since the last 
 version, as it was working in 2.0.0-RC1



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRMINA-784) Error with MDCInjectionFilter on Windows

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128939#comment-14128939
 ] 

Jeff MAURY commented on DIRMINA-784:


My mistake, the build I re-enabled was for trunk. I just created 
MINA-2.0.X-jdk1.5-windows to monitor 2.0 on Windows

 Error with MDCInjectionFilter on Windows
 

 Key: DIRMINA-784
 URL: https://issues.apache.org/jira/browse/DIRMINA-784
 Project: MINA
  Issue Type: Bug
Affects Versions: 2.0.0-RC1
Reporter: Emmanuel Lecharny
Assignee: Ashish Paliwal
 Fix For: 2.0.9


 One test is randomly failing on Windows only :
 http://hudson.zones.apache.org/hudson/job/MINA-trunk-jdk1.6-windows/lastBuild/org.apache.mina$mina-core/testReport/org.apache.mina.filter.logging/MdcInjectionFilterTest/testOnlyRemoteAddress/
 It may be the test which is broken, or something we added since the last 
 version, as it was working in 2.0.0-RC1



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRMINA-777) IoSessionConfig.setUseReadOperation(true) doesn't seem to work

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14124930#comment-14124930
 ] 

Jeff MAURY commented on DIRMINA-777:


I added a JUnit test to validate the readFuture and it is working correctly (at 
least on a small message). Can you check if the codec is not the cause.
For the Junit test, see 
https://github.com/apache/mina/blob/2.0/mina-core/src/test/java/org/apache/mina/transport/socket/nio/DIRMINA777Test.java

 IoSessionConfig.setUseReadOperation(true) doesn't seem to work
 --

 Key: DIRMINA-777
 URL: https://issues.apache.org/jira/browse/DIRMINA-777
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0-RC1
 Environment: Mac OS X 10.6.2, Java 1.6, Android SDK
Reporter: Matt Huggins
Priority: Blocker
  Labels: config, session, synchronized
 Fix For: 2.0.8


 I'm attempting to perform a synchronous write/read in a demux-based client 
 application with MINA 2.0 RC1, but it seems to get stuck. Here is my code:
 {code}
 public boolean login(final String username, final String password) {
 // block inbound messages
 session.getConfig().setUseReadOperation(true);
 // send the login request
 final LoginRequest loginRequest = new LoginRequest(username, password);
 final WriteFuture writeFuture = session.write(loginRequest);
 writeFuture.awaitUninterruptibly();
 if (writeFuture.getException() != null) {
 session.getConfig().setUseReadOperation(false);
 return false;
 }
 // retrieve the login response
 final ReadFuture readFuture = session.read();
 readFuture.awaitUninterruptibly();
 if (readFuture.getException() != null) {
 session.getConfig().setUseReadOperation(false);
 return false;
 }
 // stop blocking inbound messages
 session.getConfig().setUseReadOperation(false);
 // determine if the login info provided was valid
 final LoginResponse loginResponse = 
 (LoginResponse)readFuture.getMessage();
 return loginResponse.getSuccess();
 }
 {code}
 I can see on the server side that the LoginRequest object is retrieved, and a 
 LoginResponse message is sent. On the client side, the 
 DemuxingProtocolCodecFactory receives the response, but after throwing in 
 some logging, I can see that the client gets stuck on the call to 
 `readFuture.awaitUninterruptibly() `.
 I can't for the life of me figure out why it is stuck here based upon my own 
 code. I properly set the read operation to true on the session config, 
 meaning that messages should be blocked. However, it seems as if the message 
 no longer exists by time I try to read response messages synchronously.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRMINA-932) HTTP Request decoding is broken if request headers are received in several messages

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14124942#comment-14124942
 ] 

Jeff MAURY commented on DIRMINA-932:


Fixed by DIRMINA-933

 HTTP Request decoding is broken if request headers are received in several 
 messages
 ---

 Key: DIRMINA-932
 URL: https://issues.apache.org/jira/browse/DIRMINA-932
 Project: MINA
  Issue Type: Bug
  Components: Protocol - HTTP
Affects Versions: 2.0.7
Reporter: Jeff MAURY
  Labels: http, http-headers
 Fix For: 2.0.8


 If the request header is received in several messages, the previous messages 
 are stored in the session and the next time, this will be appended to the 
 received message and decoding will be performed on the whole.
 Problem is that a new buffer is allocated and filled with proper data, but 
 not affected and used after 
 Does not apply to 3.0.0 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRMINA-931) HTTP header decoding is broken

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14124956#comment-14124956
 ] 

Jeff MAURY commented on DIRMINA-931:


Backported to 2.0 with commit 9645bc04739faa55f1aae396fb42d5221f5efddd

 HTTP header decoding is broken
 --

 Key: DIRMINA-931
 URL: https://issues.apache.org/jira/browse/DIRMINA-931
 Project: MINA
  Issue Type: Bug
  Components: Protocol - HTTP
Affects Versions: 2.0.7
Reporter: Jeff MAURY
  Labels: decode, http, http-headers
 Fix For: 2.0.8, 3.0.0-trunk


 HTTP header decoding is broken: MINA expects a space after the :,where the 
 spec says it is preferred but not mandatory: all leading and trailing spaces 
 must be removed.
 Please not that receiving such a header will cause an exception to be thrown 
 and no HTTP PDU to be generated



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRMINA-940) HTTP Client decoder does not support responses without Content-Length header

[Jeff MAURY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14124968#comment-14124968
 ] 

Jeff MAURY commented on DIRMINA-940:


Fixed by DIRMINA-920

 HTTP Client decoder does not support responses without Content-Length header
 

 Key: DIRMINA-940
 URL: https://issues.apache.org/jira/browse/DIRMINA-940
 Project: MINA
  Issue Type: Bug
  Components: Protocol - HTTP
Affects Versions: 2.0.7, 3.0.0-M2
Reporter: Jeff MAURY
Priority: Minor
  Labels: http, http-headers
 Fix For: 2.0.8, 3.0.0-trunk


 When an HTTP response is decoded has not Content-Length header, it is 
 rejected by the decoder as it should be accepted according to the spec



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Preparing a release for 2.0.8

[Jeff MAURY]

Can we establish the list by mid-day ?

Jeff


On Fri, Sep 5, 2014 at 7:02 AM, Emmanuel Lécharny elecha...@gmail.com
wrote:

 Le 04/09/14 21:41, Jeff MAURY a écrit :
  What kind of help do you need ? I may be able to find some time this
  week-end

 There are a bunh of opened JIRA's. The idea is to go through them and
 fix what we can.




-- 
Jeff MAURY


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

Re: Preparing a release for 2.0.8

[Jeff MAURY]

What kind of help do you need ? I may be able to find some time this
week-end

Jeff



On Thu, Sep 4, 2014 at 8:50 PM, Emmanuel Lécharny elecha...@gmail.com
wrote:

 Hi guys,

 as I'm back from vavations with some kind of energy, I've started to
 check all the opened issues in MINA 2.0. I expect to be able to cut a
 release this week-end (a long expetced one...).

 If one of you fell like helping, that would be a pleasure !

 Thanks !




-- 
Jeff MAURY


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

Re: SSL thoughts

[Jeff MAURY]

Hello,

after thinking about the messages ordering and rehandshaking, I agree that
we should encrypt just before sending. The only problematic case that I can
see is if the send queue is empty and the application submit a message when
the last client handshake message is received  : if both runs concurrently,
it will be possible that the message will be encrypted using the new key
materials but the changeCipherSpec will be sent after. I agree that the
window is small.
Regarding the event, I think we need two events: one for signaling the end
of the handshake, another one when the close alert is received as the spec
does not mandate the underlying transport connection to be closed. Sending
an event allow the application to decide what to do, maybe we should also
have a flag to automatically close the connection.

Jeff


On Wed, Jul 23, 2014 at 11:58 AM, Emmanuel Lécharny elecha...@gmail.com
wrote:

 Le 23/07/2014 10:56, Jeff MAURY a écrit :
  On Mon, Jul 21, 2014 at 5:25 PM, Emmanuel Lécharny elecha...@gmail.com
  wrote:
 
  Le 21/07/2014 16:16, Jeff MAURY a écrit :
  On Mon, Jul 21, 2014 at 3:32 PM, Emmanuel Lécharny 
 elecha...@gmail.com
  wrote:
 
  Le 21/07/2014 11:53, Jeff MAURY a écrit :
  On Mon, Jul 21, 2014 at 5:14 AM, Emmanuel Lécharny 
  elecha...@gmail.com
  wrote:
 
  Le 20/07/2014 23:11, Jeff MAURY a écrit :
 
 record layer to make the write pending state the write active
  state.
  The SSL sepc says basically the same thing.
 
  However, that only means we shoudl switch to the new keys when the
  handshake is done. It does not say anything about any pending
 message.
 
  I still think that once one peer has started an HandShake, whatever
  pending message will be lost, because I don't think the SslEngine
 will
  handle an incoming data not being part of the handshake protocol.
 
  TLS 1.2 spec says (chapter 7.1):
 
  Note: If a rehandshake occurs while data is flowing on a connection,
 the communicating parties may continue to send data using the old
 CipherSpec.  However, once the ChangeCipherSpec has been sent, the
 new CipherSpec MUST be used.  The first side to send the
 ChangeCipherSpec does not know that the other side has finished
 computing the new keying material (e.g., if it has to perform a
 time-consuming public key operation).  Thus, a small window of
 time,
 during which the recipient must buffer the data, MAY exist.  In
 
 practice, with modern machines this interval is likely to be
 fairly
  Good find !!!
 
  However, I wonder how the SslEngine will react in this case... Time
 for
  some experimentation !
 
  The spec clearly specify that there is a current read and write key
  materials and a pending one.
  Yes, but I'm afraid the SslEngine does not make any difference between
  Handshake messages and non-handshake message. I'd like to be proven
  wrong though.
 
  According to the SSLEngine Javadoc, it does support renegiotiation:
 
  Rehandshaking - Either side may request a renegotiation of the session at
  any time during the Application Data phase. New handshaking data can be
  intermixed among the application data. Before starting the rehandshake
  phase, the application may reset the SSL/TLS communication parameters
 such
  as the list of enabled ciphersuites and whether to use client
  authentication, but can not change between client/server modes. As
 before,
  once handshaking has begun, any new SSLEngine configuration settings will
  not be used until the next handshake.

 Ok. I hope it works this way. In any case, it's just a matter of being
 aware f this potential problem, and have a dedicated test for it.
 
 
 
 
  So, in my opinion, we may continue sending the old data using the old
  keys
  even after we received the re-handshake request.
  The only problem that I see is if the user submit messages before the
  initial handshake has been completed.
  Hmmm. That would mean the user does not wait for the handshake to
  complete, which sounds like a pb. All in all, the client which
 initiate
  a new HandShake is supposed to wait for this handshake to be
 completed,
  before sending anything, right ? OTOH, what if the client has some
  pending messages...
 
  BTW, we don't have an event to signal the end of the handshake (which
 is
  what we need to think about) and even if we had one, we need to handle
  this
  case.
  Here, I guess you mean something like HandshakeDone in the IoHandler
  interface ? Not sure we need one.
 
  It will allow the user application to know when messages sending can
 start.

 Seems a reasonnable feature. +1

 
  As we decided to encrypt messages
  when they are submitted, we may not be able to encrypt because the
  handshake is not finished so the ssl engine has no key materials yet.
  Yes, but I thought we agreed on the fact that messages should only be
  encrypted when we are writing them in teh socket, not before?
 
  No, I revert it because it will not be in line with the re handshake
  case