Re: [Vysper] Moving to the Maven build
On Tue, May 26, 2009 at 11:57, Emmanuel Lecharny elecha...@apache.org wrote: Niklas Gustavsson wrote: Hi Should we drop the Vysper Ant build in favour of the Maven build? Right now we have two build systems to maintain, which will cause confusion and end up being out of sync. Do we need a vote for this, or should we just svn del build.xml? I don't think we need a vote, just an agreement from Bernd. I would favor a maven build and a removal of the ant build. It will allow us to remove the libs rom svn too. I'm not pro or con a specific build tool, but I think, for any Apache project, not having its libraries accessible in SVN somewhere near the code is bad. Libraries are hard dependencies, but tools like mvn (and others) treat them like soft dependencies. What if repos get lost? Or are compromised? Given the number of artifacts and their transient dependencies, this will happen sooner or later (or has already happened without getting noticed). mvn is much more easy to get a build up and running and add features like reporting, etc. that's a huge advantage over ant. Also, I work a lot without online Internet access. mvn is more of a pain then than it is normally. (Yes, I know about offline modes etc.) So while I don't oppose mvn as a tool, it doesn't free us from our reponsabilities to make our software available not only today, but also in the future. That said, I'm somewhere between -0 and +0 for the switch. Bernd
Re: [Vysper] Moving to the Maven build
Bernd Fondermann wrote: On Tue, May 26, 2009 at 11:57, Emmanuel Lecharny elecha...@apache.org wrote: Niklas Gustavsson wrote: Hi Should we drop the Vysper Ant build in favour of the Maven build? Right now we have two build systems to maintain, which will cause confusion and end up being out of sync. Do we need a vote for this, or should we just svn del build.xml? I don't think we need a vote, just an agreement from Bernd. I would favor a maven build and a removal of the ant build. It will allow us to remove the libs rom svn too. I'm not pro or con a specific build tool, but I think, for any Apache project, not having its libraries accessible in SVN somewhere near the code is bad. My position was the same a few years ago.But I gently swift from it for many reasons... Libraries are hard dependencies, but tools like mvn (and others) treat them like soft dependencies. Not really true. You can impose the version you want to use. What if repos get lost? What if the SVN repos is lost ? The odds are pretty equivalent. Or are compromised? Same for SVN. Now, as jars in a maven repo are signed, you are more safe with it than with SVN, as you don't sign the jars in svn. Given the number of artifacts and their transient dependencies, this will happen sooner or later (or has already happened without getting noticed). Same for svn. mvn is much more easy to get a build up and running and add features like reporting, etc. that's a huge advantage over ant. Also, I work a lot without online Internet access. mvn is more of a pain then than it is normally. (Yes, I know about offline modes etc.) mvn -o + you can have your own repo on your disk, with all the needed jars. Yes, it's a bit of sweat to set it up... So while I don't oppose mvn as a tool, it doesn't free us from our reponsabilities to make our software available not only today, but also in the future. That said, I'm somewhere between -0 and +0 for the switch. What bother me about Maven repo currently is that it's often a PITA when you want to add a new jar in it (we waited months for a new BoucnyCastle version to be included), and the repo management still remain fuzzy to me : who is in charge ? Why dare we depending on a private company (sonatype) repos ? (correct me if it's not the case anymore). But all in all, I know think that is easier and safer to use maven than to get everything in svn and buildling with ant. Plus the fact is that maven is probably more efficient and more powerful than ant those days, so I think keeping maven only is probably better. And trust me, I hated maven in the past ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
[jira] Resolved: (DIRMINA-714) Packet sequence is unordered in multi thread.
[ https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny resolved DIRMINA-714. --- Resolution: Fixed Fix Version/s: 2.0.0-M6 The issue has been fixed on trunk. The 2.0.0-M6 release is currently being voted (mainly to solve this regression) and will be out in 2 days. Packet sequence is unordered in multi thread. - Key: DIRMINA-714 URL: https://issues.apache.org/jira/browse/DIRMINA-714 Project: MINA Issue Type: Bug Components: Filter Affects Versions: 2.0.0-M5 Environment: xp Reporter: ncanis2 Fix For: 2.0.0-M6 Hi. Packet sequence is unordered. = Server Client = chain.addLast(codec, new ProtocolCodecFilter(rcf)); chain.addLast(executor, getExecuteFilter());= OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100); If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6 from server. Clients : 100. where I am wrong? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release MINA 2.0.0-M6
On Tue, May 26, 2009 at 11:43 PM, Emmanuel Lecharny elecha...@apache.org wrote: Niklas, can you tell us you you managed to generate those binaries ? mvn -DaltDeploymentRepository=local::default::file:///tmp/mina clean package gpg:sign deploy # clean up unnecessary GPG signed files scp -r 2.0.0-M6 n...@people.apache.org:/home/ngn/public_html/mina I could probably have deployed directly to people.a.o, but I was lazy :-) /niklas
Re: [Vysper] Moving to the Maven build
On Wed, May 27, 2009 at 9:49 AM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: [snipped some questions that Emmanuel already addressed] Also, I work a lot without online Internet access. mvn is more of a pain then than it is normally. (Yes, I know about offline modes etc.) This is much less of a problem these days since the offline support has greatly improved and we have learned to pin the plugin versions in our POMs. So, a good (we're on the way to get good) Maven build should now use the network on the first build and then never again (unless you update a plugin version in our POM). /niklas
Re: [jira] Commented: (FTPSERVER-304) The Idle Timeout set in the listener configuration does not have any effect
Not sure why you think it will break the API, as I could not find anywhere the idleTimeout being documented as maximum idle time. Below is the Javadoc from the ListenerFactory: * Set the number of seconds during which no network activity * is allowed before a session is closed due to inactivity. * * @param idleTimeout The idle timeout in seconds So, to keep things simple, we should just mark it as a bug and make it the default timeout. Also, pre 1.0 releases worked fine with listener timeout set to a finite value and user timeout left at zero. so, I guess the issue is with 1.0/1.0.1. Sai Pullabhotla www.jMethods.com On Tue, May 26, 2009 at 1:00 PM, Niklas Gustavsson nik...@protocol7.comwrote: On Tue, May 26, 2009 at 7:01 PM, Johannes Katelaan j...@e-integration.de wrote: I absolutely agree with you. The listener timeout should be a default timeout. Since this would break our API, it's not something we can do for the 1.X series. So, if we want to introduce a default idle time, in addition to the existing maximum idle time, it needs to be a new configuration. /niklas
Re: [jira] Commented: (FTPSERVER-306) some clients won't transform NEW LINE characters to \r\n when sending in ASCII mode so after sending a file the new lines will be gone.
I added a fix and some tests but ToNetASCIIOutputStream in commons-util will always replace to \r\n so I'm uploading a modified version. With this fix ascii mode should not eat line separators anymore. 2009/5/26 Niklas Gustavsson nik...@protocol7.com: On Tue, May 26, 2009 at 12:38 PM, Sai Pullabhotla sai.pullabho...@jmethods.com wrote: when FtpServer receives a file in ASCII mode our current code replaces \r for \r\n and ignores \n, but since it seems FileZilla doesn't transform new lines to \r\n we will never find a \r and the new line characters will be silently ignored. Hmm... shouldn't it be just doing the following: 1. Replace \r\n with System.getProperty(line.separator); 2. Write everything else as is. Agreed. However, that's not what we currently do since if the client only sends \n we will strip out the line ending. This is a bug on our side that we should fix. You can probably agrue that FileZilla is doing the right thing as \r is probably not to be regarded as the internal character representation (as described in the RFC) on Windows. Anyways, we should add a bunch of tests for this and fix. /niklas
[jira] Resolved: (FTPSERVER-306) some clients won't transform NEW LINE characters to \r\n when sending in ASCII mode so after sending a file the new lines will be gone.
[ https://issues.apache.org/jira/browse/FTPSERVER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-306. - Resolution: Fixed I think it's fixed now, but it might not work with other line separators than CRLF or LF ... some clients won't transform NEW LINE characters to \r\n when sending in ASCII mode so after sending a file the new lines will be gone. - Key: FTPSERVER-306 URL: https://issues.apache.org/jira/browse/FTPSERVER-306 Project: FtpServer Issue Type: Improvement Reporter: David Latorre -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DIRMINA-715) Ability to set timeouts for NioSocketConnector.connect()
Ability to set timeouts for NioSocketConnector.connect() Key: DIRMINA-715 URL: https://issues.apache.org/jira/browse/DIRMINA-715 Project: MINA Issue Type: Wish Components: Core Affects Versions: 2.0.0-M5 Reporter: Roger Kapsi The connect() method in MINA 1.x had an argument for a SocketConnectorConfig object that would allow the user to specify a custom timeout for each call. In MINA 2.x there is only a per NioSocketConnector instance timeout. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DIRMINA-716) Get rid of finalize method in AbstractIoFilterChain.java
Get rid of finalize method in AbstractIoFilterChain.java -- Key: DIRMINA-716 URL: https://issues.apache.org/jira/browse/DIRMINA-716 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.0-M5 Reporter: Yongxing Wang The finalize method in AbstractIoFilterChain.java can possibly cause OOM error when the system is under very heavy load. The negative impact of finalize method can be found at: http://www.fasterj.com/articles/finalizer1.shtml AbstractIoFilterChain holds a reference to Session object which can hold a list of unwritten data. The deterministic run of Finalizer can very well cause memory not fred up on time under heavy load. And it can certainly cause very bad memory usage pattern and contribute to the overall heavy system load. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (FTPSERVER-306) some clients won't transform NEW LINE characters to \r\n when sending in ASCII mode so after sending a file the new lines will be gone.
On Wed, May 27, 2009 at 3:07 PM, David Latorre dvl...@gmail.com wrote: I added a fix and some tests but ToNetASCIIOutputStream in commons-util will always replace to \r\n so I'm uploading a modified version. With this fix ascii mode should not eat line separators anymore. Thanks! Looking into the fix I'm not sure we should print EOL on \r. Since \r is not the canonical line ending in the RFC, I think we should rather print \r as it is in the stream. What do you think? /niklas
Re: [jira] Commented: (FTPSERVER-306) some clients won't transform NEW LINE characters to \r\n when sending in ASCII mode so after sending a file the new lines will be gone.
On Wed, May 27, 2009 at 8:43 PM, Niklas Gustavsson nik...@protocol7.com wrote: On Wed, May 27, 2009 at 3:07 PM, David Latorre dvl...@gmail.com wrote: I added a fix and some tests but ToNetASCIIOutputStream in commons-util will always replace to \r\n so I'm uploading a modified version. With this fix ascii mode should not eat line separators anymore. Oh, also, do we need to handle \n line endings? /niklas
