Hi !
sure, feel free to do so ! We haven't tested it with Java > 8, so that
would clearly help.
Thanks !
On 02/12/2018 18:43, Sina Kashipazha wrote:
Dear Community members
I'm graduated CS student with computer network and operating system experience.
I want to help open source
>> I have question regarding SSH server timeout. Can you please help me
with timeout configuration for sshd apache server.
There are many timeouts or other configuration values that affect timeouts
in SSHD. The code assumes some reasonable widely used defaults. If these
are not good enough for
On Fri, Nov 16, 2018 at 7:14 PM Lyor Goldstein
wrote:
> >> In ApacheDS, we decided to limit the size of a PDU to avoid crazy big
> (and crafted) messages to be processed. This is of course configurable. I
> guess you could do the same. Note that I don't think it makes sense to send
> a big
>> In ApacheDS, we decided to limit the size of a PDU to avoid crazy big
(and crafted) messages to be processed. This is of course configurable. I
guess you could do the same. Note that I don't think it makes sense to send
a big chunk of data in SSH, IMO.
Please note though that the limiting the
Interesting problem...
In ApacheDS, we decided to limit the size of a PDU to avoid crazy big (and
crafted) messages to be processed. This is of course configurable. I guess
you could do the same. Note that I don't think it makes sense to send a big
chunk of data in SSH, IMO.
Otherwise, I'm not a
That's great, thank you.
Greg
On Tue, 13 Nov 2018 at 22:50, Emmanuel Lecharny
wrote:
> We probably can get a release with only this issue being fixed. I would
> suggest we test it on Java 11 (Java 10 is not going to be supported while
> 11 is LTS).
>
> On Tue, Nov 13, 2018 at 4:55 PM Greg
We probably can get a release with only this issue being fixed. I would
suggest we test it on Java 11 (Java 10 is not going to be supported while
11 is LTS).
On Tue, Nov 13, 2018 at 4:55 PM Greg Thomas wrote:
> Hi there,
>
> Are there any plans for a new release of MINA anytime soon? I ask
Wish you the best on the computer issue. Once you get a new drive, it might
better to try accessing the original drive via external connectors. There
are also paid recovery options as well but they are quite expensive :(
Good luck,
Paul
On Tue, Nov 6, 2018, 14:42 Emmanuel Lecharny wrote:
> Hi!
or.createScpClient(session); // this is not a
Closeable API so no need for try-with-resource
scp.upload(local, remote);
scp.download(remote, local);
}
There you have it - of course, this does not mention error recovery, using
public key instead of password for authentication, setting up
We don’t have any support for udp multicadt in 2.0.19, but would be pleased
to add it if you volunteer to do it :-)
Le mer. 7 nov. 2018 à 17:43, Mondain a écrit :
> I have a need for UDP multicast and I was wondering what the status of
> https://issues.apache.org/jira/browse/DIRMINA-438 is?
Sounds like the master SelectorKey HashMap owned by the Selector. This is
part of the Java NIO API, not MINA.
https://docs.oracle.com/javase/7/docs/api/java/nio/channels/Selector.html
You can call selector.keys() which is actually that HashMap you are
referring to. I think there is a total of
>> You should not have to deal with the delayed closing: MINA is already
>> allowing
you to do that, if you call closeOnFlush() instead of
closeNow() -or close(), which maps to closeNow()-. It will then flushall
the pending messages before closing the session. No message written in the
session
This is how I handle it, Channel should go immediately into CLOSE_CLOSING
then into CLOSE_LINGER while flushing then CLOSE_CLOSED
On Fri, Oct 19, 2018 at 4:39 AM Emmanuel Lécharny
wrote:
> Hi Lyor,
>
> a few hints, onsidering I haven't reviewed the code...
>
> Le 19/10/2018 à 07:00, Lyor
Hi Lyor,
a few hints, onsidering I haven't reviewed the code...
Le 19/10/2018 à 07:00, Lyor Goldstein a écrit :
> Here is the issue in a nutshell - a client might open an SSH tunnel, send
> some data and close (normally) its side of the tunnel before the channel to
> the other side has been
I updated the test suite this morning. There is definitely a correlation
to performance and invokeinterface, however BakedGenericAbstractTest is
using invokevirtual and is actually 2x as expensive as invokeinterface in
that test.
On Fri, Oct 12, 2018 at 4:29 AM Emmanuel Lécharny
wrote:
>
>
>
Le 11/10/2018 à 19:03, Jonathan Valliere a écrit :
> One explaination I came up was that Java is performing a full upcast when
> encountering the generic-based interface. Unchecked and checked genetics
> perform identically.
Here is the bytecode for the strictMethod() :
0: aload_0
1:
One explaination I came up was that Java is performing a full upcast when
encountering the generic-based interface. Unchecked and checked genetics
perform identically.
Because the generics are fully removed at compile time; Java may be forced
to do full type casting every time the method is
Thanks, Jonathan,
Le 11/10/2018 à 18:07, Jonathan Valliere a écrit :
> I was having a conversation with a colleague last week about the cost of
> automatic casting due to the use of generics in java; so, I decided to
> write a benchmark. Since everyone wants their networking code to run as
>
Le 09/10/2018 à 14:49, Jonathan Valliere a écrit :
> I was willing to be the default maintainer for FtpServer.
That works :-)
Vysper seems a bit of a lost case, IMHO..
--
Emmanuel Lecharny
Symas.com
directory.apache.org
pEpkey.asc
Description: application/pgp-keys
I was willing to be the default maintainer for FtpServer.
On Tue, Oct 9, 2018 at 5:40 AM Emmanuel Lécharny
wrote:
> Sounds good to me.
>
> I think we should reboot the Vysper and FtpServer move to attic
> discussion...
>
> Le 09/10/2018 à 09:14, Guillaume Nodet a écrit :
> > Below is the draft
Sounds good to me.
I think we should reboot the Vysper and FtpServer move to attic
discussion...
Le 09/10/2018 à 09:14, Guillaume Nodet a écrit :
> Below is the draft board report we need to submit for the next board
> meeting in a week.
> If you have anything to add / modify, let me know, else
Le 03/10/2018 à 16:25, Mondain a écrit :
> I was looking into an issue reported in our use of UDP sessions in Mina
> 2.0.19. The IoSession.getScheduledWriteMessages() seemed to give very odd
> and varying results when more than one session existed. It seems that the
> scheduledWriteMessages
Le 01/10/2018 à 09:10, Lyor Goldstein a écrit :
>>> Lyor, would you mind writing the release annoucement ? I'll publish
the artifacts
> this morning, so we can send it later today.
>
> Sure - I'll send it to your private mail for proof-reading and any
> last-minute modifications you see fit so
+1
Le lun. 17 sept. 2018 à 10:35, Guillaume Nodet a écrit :
> I've staged a candidate release for Mina SSHD 2.1.0 at
> https://repository.apache.org/content/repositories/orgapachemina-1038/
>
> This release contains the following changes:
> ** Bug
> * [SSHD-827] - Dynamic port forwarding
Le 01/10/2018 à 09:10, Lyor Goldstein a écrit :
>>> Lyor, would you mind writing the release annoucement ? I'll publish the
>>> artifacts
> this morning, so we can send it later today.
>
> Sure - I'll send it to your private mail for proof-reading and any
> last-minute modifications you see
>> Lyor, would you mind writing the release annoucement ? I'll publish the
artifacts this morning, so we can send it later today.
>> Sure - I'll send it to your private mail for proof-reading and any
last-minute modifications you see fit so you can release it whenever you
feel is right.
Done -
>> Lyor, would you mind writing the release annoucement ? I'll publish the
>> artifacts
this morning, so we can send it later today.
Sure - I'll send it to your private mail for proof-reading and any
last-minute modifications you see fit so you can release it whenever you
feel is right.
Lyor, would you mind writing the release annoucement ? I'll publish the
artifacts this morning, so we can send it later today.
Le lun. 1 oct. 2018 à 08:44, Lyor Goldstein a
écrit :
> >> #2 is not an option imho. Given the amount of work that would be
> needed to manually re-pa
>> #2 is not an option imho. Given the amount of work that would be
needed to manually re-package and re-sign the distributions artifacts, i'd
go for #1 if this is considered a blocker.
Reasonable - I was only bringing it up so that when we decide how to
proceed we have all the relevant o
Sounds perfect to me.
I'll close the release tomorrow then.
Guillaume
Le dim. 30 sept. 2018 à 20:51, Emmanuel Lécharny a
écrit :
>
>
> Le 30/09/2018 à 20:37, Guillaume Nodet a écrit :
> > #2 is not an option imho. Given the amount of work that would be needed
> to
>
Le 30/09/2018 à 20:37, Guillaume Nodet a écrit :
> #2 is not an option imho. Given the amount of work that would be needed to
> manually re-package and re-sign the distributions artifacts, i'd go for #1
> if this is considered a blocker.
As soon as we know why it fails when we try
#2 is not an option imho. Given the amount of work that would be needed to
manually re-package and re-sign the distributions artifacts, i'd go for #1
if this is considered a blocker.
Le dim. 30 sept. 2018 à 18:23, Lyor Goldstein a
écrit :
> >>> I just used the link Guillaume provid
(in this case 2 *hostkey.ser* files) that are actually *products* of the
compilation and test code and not true sources (i.e., the test code
produces them and re-uses them if they are already there). Once these files
are removed (see *sshd-core* and *sshd-netty*) the build completes
successfully (E
>
>>> Or simply have an issue and lose the data.
>
> Then they would lose the community's support as well...
>> Which is the least of our concern ;-) Since they have been bought by M$,
many projects already migrated to gitlab (wait for gitlab to be bought
by some big co...)
Excellent point (BTW,
Le 30/09/2018 à 16:21, Lyor Goldstein a écrit :
>>> Also Github is own by a private company, we should not depend on them, they
> can easily shutdown their service, or stopping offering it for
> free.
>
> Very good point - however, why shouldn't Apache run its own GIT repository
> (which it
>> Also Github is own by a private company, we should not depend on them, they
can easily shutdown their service, or stopping offering it for
free.
Very good point - however, why shouldn't Apache run its own GIT repository
(which it actually does, since github is just a mirror of it...)
>> Or
You need the sources in case GIT has a major meltdown. Additionally, the
sources + javadoc can be distributed through Maven.
On Sat, Sep 29, 2018 at 1:31 PM Lyor Goldstein
wrote:
> > sources that are posted there and tried to build from them ? How is it
> even
> > possible - after all (AFAIK)
> sources that are posted there and tried to build from them ? How is it
even
> possible - after all (AFAIK) they do not form a valid Maven project ?
>> They should. What's the pount in distributing a source package if you
can't build it ?
>> Also keep in mind that Apache does *only* distribute
Le 27/09/2018 à 15:07, Lyor Goldstein a écrit :
> Hi Emmanuel,
>
>>> I just used the link Guillaume provided
> https://repository.apache.org/content/repositories/orgapachemina-1038/
>
> The link contains only binaries -
Nope, it also contains a source package :
sing Guiilaume's posted link ?
I have never done this, so if you could provide a brief step-by-step of the
process you employ, it would help me re-create this and perhaps diagnose
the issue. It would also be helpful in future releases since I will be able
to "preventively" run t
- but never in the core. As you have indicated, the GIT code
compiles without any problems. Can you indicate how you retrieved the
package sources and attempted to compile it - perhaps I can re-create the
problem somehow...
Lyor
-ldap-api/t/apache-sshd-2.1.0/sshd-core/target/surefire-reports-nio2
for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump,
[date].dumpstream and [date]-jvmRun[N].dumpstream.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack t
Sorry for the delay, I will take some time tonite or tomorrow to vote
this release !
Le 17/09/2018 à 10:35, Guillaume Nodet a écrit :
> I've staged a candidate release for Mina SSHD 2.1.0 at
> https://repository.apache.org/content/repositories/orgapachemina-1038/
>
> This release contains the
+1
Hi Guillaume,
If you have not cut out a release version, then all is well, otherwise, I
apologize for the inconvenience, but please include the fix I just
committed for SSHD-843.
Thanks again,
Lyor G.
>> I'll try to find some time to do it.
Great, thanks Guillaume...
Thanks for all the great inputs - at this stage we will not add these
dependencies in view of their relative small "weight" in our code. If this
should change in the future we will revisit this decision.
On Fri, Aug 17, 2018 at 9:19 AM, Lyor Goldstein
wrote:
> >>> We should be careful when trying to replace existing code with
> external libraries because there is rarely a guarantee that it will work
> exactly as the old code does.
>
> I agree in principle, but am not sure about "rarely a
>>> We should be careful when trying to replace existing code with
external libraries because there is rarely a guarantee that it will work
exactly as the old code does.
I agree in principle, but am not sure about "rarely a guarantee" -
especially in this case where the code is a 100% duplicate
Code which was already made shouldn’t be an issue unless it is full of
bugs. We should be careful when trying to replace existing code with
external libraries because there is rarely a guarantee that it will work
exactly as the old code does.
Dependencies create problems when the dependent
>>> Of course, it's all about the size of what is copied. At some point, it
would be better to go witha third party dependency instead of copying
its code.
Valid observation - we will need to "weigh" the amount of copied code and
see how "heavy" it is.
>>> On important aspect of adding external
Le jeu. 16 août 2018 à 08:58, Emmanuel Lécharny a
écrit :
> Hi guys,
>
> the new release policy requires that we remove MD5 signature from the
> www.apache.org/dist repository for our projects :
>
> " -- for past releases :
> -- you are not required to change anything ;
> --
r "3rd party" library - specifically Apache Commons (...so not quite
> "3rd party"...) . E.g., *IOUtils*, *GenericUtils*, *ValidateUtils*,
> *NumberUtils*, etc
>
> While I understand the advantages of maintaining a low dependency factor,
> there is still the issue &
Le lun. 30 juil. 2018 à 20:51, Michael Brodskiy
a écrit :
> Hello,
>
> My name is Michael Brodskiy. I have question regarding library
> configuration. Could you please help me with lib configuration.
> I have to implement custom SSH server with following functionality:
>
>1. authorization by
Can you copy your KeepAliveFilter code to a pastebin? I would like to look
at it.
Are you using the current version of Mina? We had an issue relating the
IoSession backlog a while back DIRMINA-1057 which makes sure that the
counters are working correctly.
On Thu, Jul 26, 2018 at 8:47 PM, Ming
tps://github.com/apache/mina-sshd/>
apache/mina-sshd<https://github.com/apache/mina-sshd/>
github.com
mina-sshd - Mirror of Apache MINA SSHD
From: Onder SEZGIN
Sent: Friday, July 20, 2018 10:39 AM
To: us...@mina.apache.org; dev@mina.apache.org
Subject: Re:
Hi,
I have the same question. So adding dev list.
Thanks.
On Mon, Jul 16, 2018 at 3:04 PM Matthias Sohn
wrote:
> I am looking for the latest release of Mina SSHD.
> On github and Maven central I find 2.0.0 whereas the download page says
> that 1.7.0 is the latest release.
> What is the
Le 16/07/2018 à 01:47, Reijhanniel Jearl Campos a écrit :
> Hi!
>
> I was recently working on a test that involves setting up an embedded XMPP
> server with Vysper, and Smack[1]. I encountered an issue[2] and posted on
> the Smack forum, and a developer pointed out that it might be a server
>
I don't think there is such a timeout directly, but since the server presenting
its key to the client for verification is part of the authentication protocol
perhaps you could use the authentication timeout for this purpose. It's not
exactly what you want, but it should do the job.
This is
Le 06/07/2018 à 23:15, Jonathan Valliere a écrit :
> There are no 2.1 releases are there?
No, there are none. There is a branch I created, but no release so far.
Maybe 3.0 should be reserved for some
> incompatible refactor.
3.0 does exist, and we have releases for it, but it's currently
There are no 2.1 releases are there? Maybe 3.0 should be reserved for some
incompatible refactor.
I know we had a discussion about this before; shouldn’t the major versions
numbers have a goal of maintaining compatibility with the entire major
number? So moving to 3 from 2 allows us to break
Le 06/07/2018 à 16:29, Jonathan Valliere a écrit :
> Any objections to setting up a 2.X branch which serves as the master then
> create the explicit numerical branches when releases are done? The 2.0
> used to be the master but now there is 2.1. Just looking to make it easier
> to understand.
Le 29/06/2018 à 13:10, Guillaume Nodet a écrit :
> Sorry for the delay.
> I gave it another try and unfortunately, the problem persists with my local
> build of 2.20-SNAPSHOT.
Ah, crap :/
> I'll try to find a fix next week.
Okiedo. What is surprizing is that I fixed the change you pointed, so
Sorry for the delay.
I gave it another try and unfortunately, the problem persists with my local
build of 2.20-SNAPSHOT.
I'll try to find a fix next week.
Le mar. 26 juin 2018 à 00:39, Emmanuel Lécharny a
écrit :
>
>
> Le 23/06/2018 à 01:40, Guillaume Nodet a écrit :
> > Sorry, I've been on
Le 23/06/2018 à 01:40, Guillaume Nodet a écrit :
> Sorry, I've been on meetings the whole week. I'll give it a try on monday.
Hi Guillaume,
any update ?
Thanks !
--
Emmanuel Lecharny
Symas.com
directory.apache.org
pEpkey.asc
Description: application/pgp-keys
Sorry, I've been on meetings the whole week. I'll give it a try on monday.
Le ven. 22 juin 2018 à 10:12, Emmanuel Lécharny a
écrit :
> Hi Guillaume,
>
> I have reverted the change. Can you give it a try ? If it's ok, I can
> cut a release right away.
>
> Thanks !
>
> --
> Emmanuel Lecharny
>
>
You're right.
Would you mind sending the email to the user list to announce it please ?
Le ven. 22 juin 2018 à 17:48, Lyor Goldstein a
écrit :
> Hi,
>
> I just noticed that SSHD 2.0 is listed on Maven central. I am all for it,
> but I do not remember seeing the official announcement - did I
I don’t think we should start from a blank page; we could always create a
whole new project todo that. I think we will be doing our jobs If we can
focus on improving pain points and stability.
I don’t have a problem with SSL being a filter; In fact, it is the most
flexible way to do it; just
Le 22/06/2018 à 14:01, Jonathan Valliere a écrit :
> At what point is the SSL going to be redesigned and anyone using it will be
> forced to update their code?
Sadly, we have thousands of peope using MINA as it is.
Mina 3.0 was an effort we started a few years ago to redesign this piece
of
At what point is the SSL going to be redesigned and anyone using it will be
forced to update their code?
Are we going to continue to support other projects which use internal APIs
or variables? Seems like every good idea Emmanuel had was reverted for
reasons from “using a private event you
Hi Guillaume,
I have reverted the change. Can you give it a try ? If it's ok, I can
cut a release right away.
Thanks !
--
Emmanuel Lecharny
Symas.com
directory.apache.org
pEpkey.asc
Description: application/pgp-keys
Le 21/06/2018 à 18:30, Guillaume Nodet a écrit :
> Sorry, my link does not work.
> I pinned it down to the removal of the SslHandler#handshakeStatus variable.
Ok, that makes more sense :-)
Can you test a 2.0.19 with this change reverted ?
I can easily cut a 2.0.20 fast. (makes me think that
Sorry, my link does not work.
I pinned it down to the removal of the SslHandler#handshakeStatus variable.
Guillaume
Le jeu. 21 juin 2018 à 16:43, Emmanuel Lécharny a
écrit :
>
>
> Le 21/06/2018 à 12:42, Guillaume Nodet a écrit :
> > So I can't explain exactly why, but the problem comes from
Le 21/06/2018 à 12:42, Guillaume Nodet a écrit :
> So I can't explain exactly why, but the problem comes from the removal of
> the following variable:
>
> https://github.com/apache/mina/commit/60cb619b6f0a940e7a6b18c060158270c227255b#diff-e3418ff2f83464c155b780cdbfb9e4aaL754
Hmmm...
public
So I can't explain exactly why, but the problem comes from the removal of
the following variable:
https://github.com/apache/mina/commit/60cb619b6f0a940e7a6b18c060158270c227255b#diff-e3418ff2f83464c155b780cdbfb9e4aaL754
Le jeu. 21 juin 2018 à 10:47, Guillaume Nodet a écrit :
> It looks like
It looks like visper is receiving a duplicate message from mina or
something like that and thus is closing the session because it assumes a
protocol error.
The actual location is the following:
java.lang.Throwable
at
Le 20/06/2018 à 19:00, Guillaume Nodet a écrit :
> So I've enabled debug logging which helps a bit.
> https://gist.github.com/gnodet/04b08b1d19caa67359f352522774a70d
>
> I suspect a concurrent access to the byte buffer because the exception
> should be thrown from the HeapByteBuffer#checkIndex
So I've enabled debug logging which helps a bit.
https://gist.github.com/gnodet/04b08b1d19caa67359f352522774a70d
I suspect a concurrent access to the byte buffer because the exception
should be thrown from the HeapByteBuffer#checkIndex instead of from
HeapByteBuffer#get. So I think there is a
Le mer. 20 juin 2018 à 18:09, Lyor Goldstein a
écrit :
> I believe CAMEL can simply choose to use mina-core 2.0.18 (since they have
> the same API) by simply overriding its version in the CAMEL POM.
>
Yeah, I'm not reporting a problem for camel per se, the upgrade has been
revert to 2.0.17 and
Le 20/06/2018 à 18:09, Lyor Goldstein a écrit :
> I believe CAMEL can simply choose to use mina-core 2.0.18
2.0.17.
There is an API regression in 2.0.18 which has been solved in 2.0.19.
--
Emmanuel Lecharny
Symas.com
directory.apache.org
I believe CAMEL can simply choose to use mina-core 2.0.18 (since they have
the same API) by simply overriding its version in the CAMEL POM.
Furthermore, since SSHD does not really need MINA, it can be configured to
use NIO2 and thus avoid dragging in the MINA dependency.
Le 20/06/2018 à 17:29, Guillaume Nodet a écrit :
> Here it is:
>https://gist.github.com/gnodet/e2f63e474965ba4d02e9625a1c69cbb5
There is some message :
Padded plaintext before ENCRYPTION: len = 240
: 2A 74 62 52 BC 59 24 C5 82 77 DB B3 B6 70 E6 D0 *tbR.Y$..w...p..
0010: 3C 3F 78
Here it is:
https://gist.github.com/gnodet/e2f63e474965ba4d02e9625a1c69cbb5
Le mer. 20 juin 2018 à 17:22, Emmanuel Lécharny a
écrit :
> I'd like to have the following test ran with -Djavax.net.debug=all
> option set :
> org.apache.camel.component.xmpp.XmppMultiUserChatTest.testXmppChat
>
>
I'd like to have the following test ran with -Djavax.net.debug=all
option set :
org.apache.camel.component.xmpp.XmppMultiUserChatTest.testXmppChat
There is clearly some SSL weirdness going on...
java.lang.RuntimeException: Could not connect to XMPP server:
localhost:5222/null
Caused by:
Tomislav,
FTPSERVER is not under active development. I will accept a patch to
add RFC2228
if you are willing to put in the effort to write the code and unit tests.
Cheers,
J
On Wed, Jun 20, 2018 at 2:57 AM, Tomislav Haramustek <
tomislav.haramus...@hashcode.hr> wrote:
> Hello,
>
> I am
Hi guys,
I was wondering where we are after resuming the vote on whether to release
SSHD 2.0 ...
Thanks,
+1
Sorry, sent to private mail by accident.
On 11/06/18 16:52, Guillaume Nodet wrote:
We're still having only 2 votes on this thread. Could a few people have a
look so that we can get it out or fix any problem ?
+1
Jeff
> On Jun 11, 2018, at 8:52 AM, Guillaume Nodet wrote:
>
> We're still having only 2 votes on this thread. Could a few people have a
> look so that we can get it out or fix any problem ?
>
> 2018-05-28 17:12 GMT+02:00 Guillaume Nodet :
>
>> I've staged a release of Mina SSHD 2.0.0
>>
We're still having only 2 votes on this thread. Could a few people have a
look so that we can get it out or fix any problem ?
2018-05-28 17:12 GMT+02:00 Guillaume Nodet :
> I've staged a release of Mina SSHD 2.0.0
> https://repository.apache.org/content/repositories/orgapachemina-1035/
>
>
Should be fine; ApacheDS is a complex project that used hooks for the old
SSL Events to listen when SSL was started / ended.
On Mon, Jun 11, 2018 at 5:18 AM, Christoph John
wrote:
> Hi Emmanuel,
>
> just a short question: I can compile against 2.0.18 without problems and
> the tests run fine.
Thanks for the information. No problem, will wait then.
Chris.
On 11/06/18 11:54, Emmanuel Lécharny wrote:
Le 11/06/2018 à 11:18, Christoph John a écrit :
Hi Emmanuel,
just a short question: I can compile against 2.0.18 without problems and
the tests run fine. So is it safe to use that
Le 11/06/2018 à 11:18, Christoph John a écrit :
> Hi Emmanuel,
>
> just a short question: I can compile against 2.0.18 without problems and
> the tests run fine. So is it safe to use that version then? In our
> project we extend AbstractIoHandler.
So it's safe.
2.0.19 fixed the API
Hi Emmanuel,
just a short question: I can compile against 2.0.18 without problems and the tests run fine. So is
it safe to use that version then? In our project we extend AbstractIoHandler.
Thanks and cheers,
Christoph.
On 07/06/18 20:13, Emmanuel Lécharny wrote:
Hi guys,
I have made a
>> This is a fix for the previous release (2.0.18) which broke the API by
mistake.
+1
+1
From: Emmanuel Lécharny
Sent: Friday, June 8, 2018 12:24 AM
To: dev@mina.apache.org
Subject: [VOTE] Apache Mina 2.0.19
Hi !
I'm calling for a vote of Apache MINA 2.0.19 release.
This is a fix for the previous release (2.0.18) which broke the API by
+!
Jeff
> On Jun 7, 2018, at 3:24 PM, Emmanuel Lécharny wrote:
>
> Hi !
>
> I'm calling for a vote of Apache MINA 2.0.19 release.
>
> This is a fix for the previous release (2.0.18) which broke the API by
> mistake.
>
> Two changes have been rolled back :
>
> - the 'event' message has been
+1
2018-06-07 23:24 GMT+02:00 Emmanuel Lécharny :
> Hi !
>
> I'm calling for a vote of Apache MINA 2.0.19 release.
>
> This is a fix for the previous release (2.0.18) which broke the API by
> mistake.
>
> Two changes have been rolled back :
>
> - the 'event' message has been removed from the
Le 07/06/2018 à 20:41, Jonathan Valliere a écrit :
> Would it make sense to rename the 3.0 branch to FUTURE or something that
> doesn’t involve a numerical version number?
Sure. It's a bit annoying to have blocked a version number for years...
--
Emmanuel Lecharny
Symas.com
Would it make sense to rename the 3.0 branch to FUTURE or something that
doesn’t involve a numerical version number?
On Thu, Jun 7, 2018 at 2:13 PM, Emmanuel Lécharny
wrote:
> Hi guys,
>
> I have made a mistake when I cut the latest release (MINA 2.0.18), which
> breaks the API - actually, two
+1
2018-06-04 17:55 GMT+02:00 Lyor Goldstein :
> >> Following up the discussions, I'm resuming the vote...
>
> (Again) +1
>
--
Guillaume Nodet
1401 - 1500 of 11689 matches
Mail list logo
