Re: Mina server hang
Hi, this is a very small piece of information you gave us to work on !!! We don't know anything about your code, about the MINA version you are using, etc ... The only thing I can see from this TD is that you have 8 thread blocked, waiting for some queue to be fed. Those thread are Acceptors waiting for an incoming connection, AFAICS. More information and context could help... Steve Johns wrote: Hi the following is the full thread dump, can someone give any idea if mina itself problem or my program problem? Thanks a lot. AnonymousIoService-8 daemon prio=6 tid=0x16dd9400 nid=0x1608 waiting on condit ion [0x1856f000..0x1856fd18] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x088f69b0 (a java.util.concurrent.locks.Abstra ctQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(Unknown Source) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject .await(Unknown Source) at java.util.concurrent.LinkedBlockingQueue.take(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnabl e.java:51) at java.lang.Thread.run(Unknown Source) AnonymousIoService-7 daemon prio=6 tid=0x16dd8400 nid=0xe1c waiting on conditi on [0x1851f000..0x1851fd98] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x088f69b0 (a java.util.concurrent.locks.Abstra ctQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(Unknown Source) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject .await(Unknown Source) at java.util.concurrent.LinkedBlockingQueue.take(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnabl e.java:51) at java.lang.Thread.run(Unknown Source) AnonymousIoService-6 daemon prio=6 tid=0x16cb8800 nid=0x650 waiting on conditi on [0x1826f000..0x1826fa18] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x088f69b0 (a java.util.concurrent.locks.Abstra ctQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(Unknown Source) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject .await(Unknown Source) at java.util.concurrent.LinkedBlockingQueue.take(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnabl e.java:51) at java.lang.Thread.run(Unknown Source) AnonymousIoService-5 daemon prio=6 tid=0x16cb8400 nid=0x123c waiting on condit ion [0x180df000..0x180dfa98] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x088f69b0 (a java.util.concurrent.locks.Abstra ctQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(Unknown Source) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject .await(Unknown Source) at java.util.concurrent.LinkedBlockingQueue.take(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnabl e.java:51) at java.lang.Thread.run(Unknown Source) AnonymousIoService-4 daemon prio=6 tid=0x16f75c00 nid=0x110c waiting on condit ion [0x1808f000..0x1808fb18] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x088f69b0 (a java.util.concurrent.locks.Abstra ctQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(Unknown Source) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject .await(Unknown Source) at java.util.concurrent.LinkedBlockingQueue.take(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnabl e.java:51) at java.lang.Thread.run(Unknown Source) AnonymousIoService-3 daemon prio=6 tid=0x16cb7800 nid=0x179c waiting on condit ion [0x184cf000..0x184cfb98] java.lang.Thread.State: WAITING (parking) at
Re: Encoder/Decoder Repository in MINA source
This would be by far one of the best contributions to MINA. But I would keep them in a separated project (or bundle) as to not interfere with the core project. I would love to see such a project. Regards, Rodrigo On Thu, Dec 4, 2008 at 3:47 AM, Ashish [EMAIL PROTECTED] wrote: The idea is to include some well known Protocol (like DNS, HTTP, XML etc) encoder/decoder in MINA source. Essentially to speed up the development tasks. These may be completely functional or may need some work before they can be used. This shall help in easy adaptation of MINA for different projects. Users are free to use them as is, extend them or can use them as reference to build their own. Challenges that I see 1. We can't enforce high level object structure on User applications 2. Something unknown that I haven't thought of :-) Would like to know the opinion of Dev community on this. -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
[jira] Closed: (FTPSERVER-230) MFMT Command reply should include a message
[ https://issues.apache.org/jira/browse/FTPSERVER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-230. --- Assignee: Niklas Gustavsson (was: David Latorre) Fixed this quickly as it was real easy fix. Fixed in trunk in rev 723290. Reply no reads 213 ModifyTime=20020717210715 test1.txt MFMT Command reply should include a message --- Key: FTPSERVER-230 URL: https://issues.apache.org/jira/browse/FTPSERVER-230 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M3 Reporter: Sai Pullabhotla Assignee: Niklas Gustavsson Fix For: 1.0.0-RC1 MFMT Command replies with just the code 213. We might want to add a message at least saying requested action was successful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-229) MFMT Command - Code Enhancement
[ https://issues.apache.org/jira/browse/FTPSERVER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-229: Affects Version/s: (was: 1.0.0-M3) 1.0.0-M4 MFMT Command - Code Enhancement --- Key: FTPSERVER-229 URL: https://issues.apache.org/jira/browse/FTPSERVER-229 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Assignee: David Latorre Fix For: 1.0.0-RC1 MFMT Command - in the source code for this command (MFMT.java), the DateFormat and its configuration should be moved to static block for performance and to reduce object creations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-230) MFMT Command reply should include a message
[ https://issues.apache.org/jira/browse/FTPSERVER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-230: Affects Version/s: (was: 1.0.0-M3) 1.0.0-M4 MFMT Command reply should include a message --- Key: FTPSERVER-230 URL: https://issues.apache.org/jira/browse/FTPSERVER-230 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Assignee: Niklas Gustavsson Fix For: 1.0.0-RC1 MFMT Command replies with just the code 213. We might want to add a message at least saying requested action was successful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-232) MFMT command always returns a 2XX reply even if the date could not be set
[ https://issues.apache.org/jira/browse/FTPSERVER-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-232: Affects Version/s: (was: 1.0.0-M3) 1.0.0-M4 MFMT command always returns a 2XX reply even if the date could not be set - Key: FTPSERVER-232 URL: https://issues.apache.org/jira/browse/FTPSERVER-232 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Assignee: David Latorre Fix For: 1.0.0-RC1 MFMT command always returns a 2XX reply even if the date could not be set. MFMT Command should return a Positive Completion Reply if and only if we are sure that the date on the file was modified. In order to fix this, we need to make use of the return value from java.io.File.setLastModified(long). We are not using the returned boolean from this method and assuming that the new date was set. Code needs to be changed in a few places to fix this. The issue can be reproduced by trying to set the date on a file that is in use. I used a .doc file, had it open in MS Word and ran the MFMT command and got the 213 reply, but the date on the file was not changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-228) LIST command on a non-existent directory should result in an error
[ https://issues.apache.org/jira/browse/FTPSERVER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-228: Affects Version/s: (was: 1.0.0-M3) 1.0.0-M4 LIST command on a non-existent directory should result in an error -- Key: FTPSERVER-228 URL: https://issues.apache.org/jira/browse/FTPSERVER-228 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Fix For: 1.0.0-RC1 LIST command on a non-existent directory should result in an error. Instead, we send an empty list back. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-226) DELE command deletes directories
[ https://issues.apache.org/jira/browse/FTPSERVER-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-226: Affects Version/s: (was: 1.0.0-M3) 1.0.0-M4 DELE command deletes directories Key: FTPSERVER-226 URL: https://issues.apache.org/jira/browse/FTPSERVER-226 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Fix For: 1.0.0-RC1 DELE command should NOT delete the object if the argument represents a directory. According to the FTP Standards RMD command should be used for deleting directories. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-233) MKD command should not create all the parent directories
[ https://issues.apache.org/jira/browse/FTPSERVER-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-233: Component/s: Core Fix Version/s: 1.0.0-RC1 Affects Version/s: 1.0.0-M4 MKD command should not create all the parent directories Key: FTPSERVER-233 URL: https://issues.apache.org/jira/browse/FTPSERVER-233 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Fix For: 1.0.0-RC1 MKD command should not create all the parent directories, instead it should only try to create the last name in the given path. I'm filing this as a bug because most FTP servers fail if the parent directory does not exist. Just to be consistent with those we need to change the behavior too. To fix this, java.io.File.mkdirs() should be changed to java.io.File.mkdir() in the NativeFtpFile.java. Have to make sure this does not effect any other things though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-229) MFMT Command - Code Enhancement
[ https://issues.apache.org/jira/browse/FTPSERVER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653265#action_12653265 ] Niklas Gustavsson commented on FTPSERVER-229: - Be aware that SimpleDateFormat is not thread-safe and thus can not simply be set as static (this was the reason I did it as a variable). One way is to store a ThreadLocal of SimpleDateFormat instances. MFMT Command - Code Enhancement --- Key: FTPSERVER-229 URL: https://issues.apache.org/jira/browse/FTPSERVER-229 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Assignee: David Latorre Fix For: 1.0.0-RC1 MFMT Command - in the source code for this command (MFMT.java), the DateFormat and its configuration should be moved to static block for performance and to reduce object creations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-227) DELE command should not delete the current working directory or the any parent of current working directory
[ https://issues.apache.org/jira/browse/FTPSERVER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-227: Fix Version/s: (was: 1.0.0-M4) 1.0.0-RC1 Affects Version/s: (was: 1.0.0-M3) 1.0.0-M4 DELE command should not delete the current working directory or the any parent of current working directory --- Key: FTPSERVER-227 URL: https://issues.apache.org/jira/browse/FTPSERVER-227 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Fix For: 1.0.0-RC1 DELE command should not delete the current working directory or the any parent of current working directory. case 1: Let us say, the current working directory is /wd then DELE . or DELE /wd should result in a 5XX reply. case 2: Let us say the working directory is /wd/subdir, then DELE /wd or DELE .. should also be restricted and a 5xx reply should be sent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-231) MFMT Commad does not work on file/path names that have one or more white spaces
[ https://issues.apache.org/jira/browse/FTPSERVER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-231: Affects Version/s: (was: 1.0.0-M3) 1.0.0-M4 MFMT Commad does not work on file/path names that have one or more white spaces --- Key: FTPSERVER-231 URL: https://issues.apache.org/jira/browse/FTPSERVER-231 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Assignee: David Latorre Fix For: 1.0.0-RC1 MFMT Commad does not work on file/path names that have one or more white spaces. For example if you have a file named my file.txt, running the MFMT command on this file fails. To fix this, the MFMT.java needs to be changes as follows: String[] arguments = argument.split( ); should be changed to String[] arguments = arguments.split( , 2); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-234) TYPE command with no argument
[ https://issues.apache.org/jira/browse/FTPSERVER-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-234: Affects Version/s: (was: 1.0.0-M3) 1.0.0-M4 TYPE command with no argument - Key: FTPSERVER-234 URL: https://issues.apache.org/jira/browse/FTPSERVER-234 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Fix For: 1.0.0-RC1 Not sure if TYPE command with no argument should change the type to ASCII. Instead it should reply back with 2xx reply indicating the current type in use. Not sure what the RFC says. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Encoder/Decoder Repository in MINA source
Ashish wrote: The idea is to include some well known Protocol (like DNS, HTTP, XML etc) encoder/decoder in MINA source. Essentially to speed up the development tasks. These may be completely functional or may need some work before they can be used. This shall help in easy adaptation of MINA for different projects. Users are free to use them as is, extend them or can use them as reference to build their own. Challenges that I see 1. We can't enforce high level object structure on User applications 2. Something unknown that I haven't thought of :-) Would like to know the opinion of Dev community on this. Two years ago (more or less), we had a discussion about developing a project we would have called MinaReal, implementing as much protocol as possible. The name itself was taken from Ethereal, and it sound pretty well (a bit like mineral). The idea wasn't to build a concurrent product to Ethereal (as this product works directly on the network layer), but much more as a proxy. So basically, yes, this is a good idea. You have to know that we already have AsyncWeb (http), FtpServer, Dns, Ntp, Dhcp, Kerberos and Ldap implemented on top of MINA (even if those projects are shared between MINA and Directory, for historical reasons). It would be interesting to give more focus on each of those projects, in MINA, and to increase the base supported protocols. Another aspect would be to define some clear API for protocol like LDAP, Kerberos, etc, in a way it's possible to implement them directly, without having to take care of the intern of the codec. It's not so easy ... So +1, definitively ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
[jira] Commented: (FTPSERVER-227) DELE command should not delete the current working directory or the any parent of current working directory
[ https://issues.apache.org/jira/browse/FTPSERVER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653290#action_12653290 ] Sai Pullabhotla commented on FTPSERVER-227: --- Sorry for filing it incorrect, but it should have been RMD command should not delete working directory or parent of working directory. Could you please reopen this? Thanks. Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com DELE command should not delete the current working directory or the any parent of current working directory --- Key: FTPSERVER-227 URL: https://issues.apache.org/jira/browse/FTPSERVER-227 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Fix For: 1.0.0-RC1 DELE command should not delete the current working directory or the any parent of current working directory. case 1: Let us say, the current working directory is /wd then DELE . or DELE /wd should result in a 5XX reply. case 2: Let us say the working directory is /wd/subdir, then DELE /wd or DELE .. should also be restricted and a 5xx reply should be sent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-235) Documentation and code do not match for db user manager
Documentation and code do not match for db user manager
---
Key: FTPSERVER-235
URL: https://issues.apache.org/jira/browse/FTPSERVER-235
Project: FtpServer
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0-M3
Reporter: nathan longley
Priority: Minor
In the examples on the
website(http://cwiki.apache.org/FTPSERVER/database-user-manager.html) it shows:
authenticateSELECT uid from FTP_USER WHERE uid='{uid}' AND
userpassword='{userpassword}'/authenticate
(uid is wrong, is actually userid in all three places)
but the code will never set userpassword
in DbUserManager.authenticate
it does
HashMapString, Object map = new HashMapString, Object();
map.put(ATTR_LOGIN, escapeString(user));
String sql = StringUtils.replaceString(authenticateStmt, map);
LOG.info(sql);
and after it compares the stored password with the one the user entered.
is this designed to be this way or the way described in the documentation, i
think allowing it the way it is in the documentation allows for greater
flexibility.
if it is not a bug and is a design feature I will make a custom user manager.
a fix that would match the documentation would be
public User authenticate(Authentication authentication) throws
AuthenticationFailedException {
if (authentication instanceof UsernamePasswordAuthentication) {
UsernamePasswordAuthentication upauth =
(UsernamePasswordAuthentication) authentication;
String user = upauth.getUsername();
String password = upauth.getPassword();
if (user == null) {
throw new AuthenticationFailedException(Authentication
failed);
}
if (password == null) {
password = ;
}
Statement stmt = null;
ResultSet rs = null;
try {
// create the sql query
HashMapString, Object map = new HashMapString, Object();
map.put(ATTR_LOGIN, escapeString(user));
map.put(ATTR_PASSWORD, escapeString(password));
String sql = StringUtils.replaceString(authenticateStmt, map);
LOG.info(sql);
// execute query
stmt = createConnection().createStatement();
rs = stmt.executeQuery(sql);
if (rs.next()) {
try {
return getUserByName(user);
} catch (FtpException e) {
throw new AuthenticationFailedException(Authentication
failed, e);
}
} else {
throw new AuthenticationFailedException(Authentication
failed);
}
} catch (SQLException ex) {
LOG.error(DbUserManager.authenticate(), ex);
throw new AuthenticationFailedException(Authentication
failed, ex);
} finally {
closeQuitely(rs);
closeQuitely(stmt);
}
} else if (authentication instanceof AnonymousAuthentication) {
try {
if (doesExist(anonymous)) {
return getUserByName(anonymous);
} else {
throw new AuthenticationFailedException(Authentication
failed);
}
} catch (AuthenticationFailedException e) {
throw e;
} catch (FtpException e) {
throw new AuthenticationFailedException(Authentication
failed, e);
}
} else {
throw new IllegalArgumentException(Authentication not supported by
this user manager);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Encoder/Decoder Repository in MINA source
You have to know that we already have AsyncWeb (http), FtpServer, Dns, Ntp, Dhcp, Kerberos and Ldap implemented on top of MINA (even if those projects are shared between MINA and Directory, for historical reasons). DNS, NTP, DHCP and other implementation in ApacheDS prompted me to initiate this. I never knew they existed till I dived into ApacheDS code, and I hit the Holy Grail. The code at ApacheDS helped me a lot in refining my MINA understanding Not completely sure, but snmp4j folks were also planning to use MINA for transport layer. It would be interesting to give more focus on each of those projects, in MINA, and to increase the base supported protocols. Another aspect would be to define some clear API for protocol like LDAP, Kerberos, etc, in a way it's possible to implement them directly, without having to take care of the intern of the codec. It's not so easy ... Agree, will be a big challenge by itself. And that's where all the fun is :-)
[jira] Commented: (FTPSERVER-229) MFMT Command - Code Enhancement
[ https://issues.apache.org/jira/browse/FTPSERVER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653293#action_12653293 ] Sai Pullabhotla commented on FTPSERVER-229: --- Nicklas, That's a very valid point. I did not even think about it. I guess, it could stay the way it is or if we want, we can create a SynchronizedSimpleDateFormat class using the Deligator pattern, but synchronize some methods like format and parse. Surely, the synchronization would have a performance hit too. We need to think some more about this. Thanks. Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Thu, Dec 4, 2008 at 5:37 AM, Niklas Gustavsson (JIRA) MFMT Command - Code Enhancement --- Key: FTPSERVER-229 URL: https://issues.apache.org/jira/browse/FTPSERVER-229 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Assignee: David Latorre Fix For: 1.0.0-RC1 MFMT Command - in the source code for this command (MFMT.java), the DateFormat and its configuration should be moved to static block for performance and to reduce object creations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Releasing FtpServer 1.0.0-M4
On Tue, Dec 2, 2008 at 9:59 PM, Niklas Gustavsson [EMAIL PROTECTED] wrote: [X]: +1, Release FtpServer 1.0.0-M4 Forgot to put in my own vote :-) /niklas
[jira] Updated: (FTPSERVER-235) Documentation and code do not match for db user manager
[
https://issues.apache.org/jira/browse/FTPSERVER-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niklas Gustavsson updated FTPSERVER-235:
Fix Version/s: 1.0.0-M4
Assignee: Niklas Gustavsson
Documentation and code do not match for db user manager
---
Key: FTPSERVER-235
URL: https://issues.apache.org/jira/browse/FTPSERVER-235
Project: FtpServer
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0-M3
Reporter: nathan longley
Assignee: Niklas Gustavsson
Priority: Minor
Fix For: 1.0.0-M4
In the examples on the
website(http://cwiki.apache.org/FTPSERVER/database-user-manager.html) it
shows:
authenticateSELECT uid from FTP_USER WHERE uid='{uid}' AND
userpassword='{userpassword}'/authenticate
(uid is wrong, is actually userid in all three places)
but the code will never set userpassword
in DbUserManager.authenticate
it does
HashMapString, Object map = new HashMapString, Object();
map.put(ATTR_LOGIN, escapeString(user));
String sql = StringUtils.replaceString(authenticateStmt, map);
LOG.info(sql);
and after it compares the stored password with the one the user entered.
is this designed to be this way or the way described in the documentation, i
think allowing it the way it is in the documentation allows for greater
flexibility.
if it is not a bug and is a design feature I will make a custom user manager.
a fix that would match the documentation would be
public User authenticate(Authentication authentication) throws
AuthenticationFailedException {
if (authentication instanceof UsernamePasswordAuthentication) {
UsernamePasswordAuthentication upauth =
(UsernamePasswordAuthentication) authentication;
String user = upauth.getUsername();
String password = upauth.getPassword();
if (user == null) {
throw new AuthenticationFailedException(Authentication
failed);
}
if (password == null) {
password = ;
}
Statement stmt = null;
ResultSet rs = null;
try {
// create the sql query
HashMapString, Object map = new HashMapString, Object();
map.put(ATTR_LOGIN, escapeString(user));
map.put(ATTR_PASSWORD, escapeString(password));
String sql = StringUtils.replaceString(authenticateStmt, map);
LOG.info(sql);
// execute query
stmt = createConnection().createStatement();
rs = stmt.executeQuery(sql);
if (rs.next()) {
try {
return getUserByName(user);
} catch (FtpException e) {
throw new
AuthenticationFailedException(Authentication failed, e);
}
} else {
throw new AuthenticationFailedException(Authentication
failed);
}
} catch (SQLException ex) {
LOG.error(DbUserManager.authenticate(), ex);
throw new AuthenticationFailedException(Authentication
failed, ex);
} finally {
closeQuitely(rs);
closeQuitely(stmt);
}
} else if (authentication instanceof AnonymousAuthentication) {
try {
if (doesExist(anonymous)) {
return getUserByName(anonymous);
} else {
throw new AuthenticationFailedException(Authentication
failed);
}
} catch (AuthenticationFailedException e) {
throw e;
} catch (FtpException e) {
throw new AuthenticationFailedException(Authentication
failed, e);
}
} else {
throw new IllegalArgumentException(Authentication not supported
by this user manager);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (FTPSERVER-227) DELE command should not delete the current working directory or the any parent of current working directory
[ https://issues.apache.org/jira/browse/FTPSERVER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson reopened FTPSERVER-227: - DELE command should not delete the current working directory or the any parent of current working directory --- Key: FTPSERVER-227 URL: https://issues.apache.org/jira/browse/FTPSERVER-227 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Fix For: 1.0.0-RC1 DELE command should not delete the current working directory or the any parent of current working directory. case 1: Let us say, the current working directory is /wd then DELE . or DELE /wd should result in a 5XX reply. case 2: Let us say the working directory is /wd/subdir, then DELE /wd or DELE .. should also be restricted and a 5xx reply should be sent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-227) RMD command should not delete the current working directory or the any parent of current working directory
[ https://issues.apache.org/jira/browse/FTPSERVER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-227: Description: RMD command should not delete the current working directory or the any parent of current working directory. case 1: Let us say, the current working directory is /wd then RMD . or RMD /wd should result in a 5XX reply. case 2: Let us say the working directory is /wd/subdir, then RMD /wd or RMD .. should also be restricted and a 5xx reply should be sent. was: DELE command should not delete the current working directory or the any parent of current working directory. case 1: Let us say, the current working directory is /wd then DELE . or DELE /wd should result in a 5XX reply. case 2: Let us say the working directory is /wd/subdir, then DELE /wd or DELE .. should also be restricted and a 5xx reply should be sent. Summary: RMD command should not delete the current working directory or the any parent of current working directory (was: DELE command should not delete the current working directory or the any parent of current working directory) RMD command should not delete the current working directory or the any parent of current working directory -- Key: FTPSERVER-227 URL: https://issues.apache.org/jira/browse/FTPSERVER-227 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Fix For: 1.0.0-RC1 RMD command should not delete the current working directory or the any parent of current working directory. case 1: Let us say, the current working directory is /wd then RMD . or RMD /wd should result in a 5XX reply. case 2: Let us say the working directory is /wd/subdir, then RMD /wd or RMD .. should also be restricted and a 5xx reply should be sent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Vote] Create a MINA subproject to implement a SSH server based on Mina
What was the result of this? Is the integration being done? On Thu, Nov 20, 2008 at 12:29 PM, Jeff Genender [EMAIL PROTECTED] wrote: +1 Jeff On Nov 20, 2008, at 2:52 AM, Guillaume Nodet wrote: +1 On Thu, Nov 20, 2008 at 12:21 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Hi guys, Guillaume Nodet has written a SSH server based on MINA, and as we discussed it last week, it would be interesting to have it as a subproject. It's time for a formal vote then : [] +1 Yes, accept the SSH server as a sub-project [] +/-0 I don't really care [] -1 Nope, it does not belong to MINA -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [Vote] Create a MINA subproject to implement a SSH server based on Mina
Mark Webb wrote: What was the result of this? Is the integration being done? Ooopps... Seems like I forgot to close the vote. My bad ! So here are the results : 7 +1 binding votes, 5 +1 non binding votes So it's a go. I will inform Guillaume about this, and grant him commit access to MINA. Sorry for the delay ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [Vote] Create a MINA subproject to implement a SSH server based on Mina
Not a problem. On Thu, Dec 4, 2008 at 11:05 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Mark Webb wrote: What was the result of this? Is the integration being done? Ooopps... Seems like I forgot to close the vote. My bad ! So here are the results : 7 +1 binding votes, 5 +1 non binding votes So it's a go. I will inform Guillaume about this, and grant him commit access to MINA. Sorry for the delay ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: svn commit: r723396 [1/12] - in /mina/sshd/trunk: ./ src/ src/docs/ src/main/ src/main/filtered-resources/ src/main/filtered-resources/org/ src/main/filtered-resources/org/apache/ src/main/filtere
Awesome. I am really looking forward to playing with this. One note, you may want to change the java package to org.apache.mina.sshd. More of an opinion of mine, but not sure if there are any guidelines on this. Thanks Mark On Thu, Dec 4, 2008 at 1:59 PM, [EMAIL PROTECTED] wrote: Author: gnodet Date: Thu Dec 4 10:59:31 2008 New Revision: 723396 URL: http://svn.apache.org/viewvc?rev=723396view=rev Log: Commit code from the google project, refactored into org.apache.sshd package Added: mina/sshd/trunk/LICENSE.txt mina/sshd/trunk/NOTICE.txt mina/sshd/trunk/pom.xml mina/sshd/trunk/src/ mina/sshd/trunk/src/docs/ mina/sshd/trunk/src/docs/draft-ietf-secsh-filexfer-13.txt mina/sshd/trunk/src/docs/rfc4251.txt mina/sshd/trunk/src/docs/rfc4252.txt mina/sshd/trunk/src/docs/rfc4253.txt mina/sshd/trunk/src/docs/rfc4254.txt mina/sshd/trunk/src/docs/rfc4255.txt mina/sshd/trunk/src/docs/rfc4256.txt mina/sshd/trunk/src/docs/rfc4419.txt mina/sshd/trunk/src/main/ mina/sshd/trunk/src/main/filtered-resources/ mina/sshd/trunk/src/main/filtered-resources/org/ mina/sshd/trunk/src/main/filtered-resources/org/apache/ mina/sshd/trunk/src/main/filtered-resources/org/apache/sshd/ mina/sshd/trunk/src/main/filtered-resources/org/apache/sshd/sshd-version.properties mina/sshd/trunk/src/main/java/ mina/sshd/trunk/src/main/java/org/ mina/sshd/trunk/src/main/java/org/apache/ mina/sshd/trunk/src/main/java/org/apache/sshd/ mina/sshd/trunk/src/main/java/org/apache/sshd/ClientChannel.java mina/sshd/trunk/src/main/java/org/apache/sshd/ClientSession.java mina/sshd/trunk/src/main/java/org/apache/sshd/SshClient.java mina/sshd/trunk/src/main/java/org/apache/sshd/SshServer.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/ mina/sshd/trunk/src/main/java/org/apache/sshd/client/UserAuth.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/auth/ mina/sshd/trunk/src/main/java/org/apache/sshd/client/auth/UserAuthPassword.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/channel/ mina/sshd/trunk/src/main/java/org/apache/sshd/client/channel/AbstractClientChannel.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/channel/ChannelSession.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/channel/ChannelShell.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/kex/ mina/sshd/trunk/src/main/java/org/apache/sshd/client/kex/AbstractDHGClient.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/kex/DHG1.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/kex/DHG14.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/session/ mina/sshd/trunk/src/main/java/org/apache/sshd/client/session/ClientSessionImpl.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/ mina/sshd/trunk/src/main/java/org/apache/sshd/common/AbstractFactoryManager.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/AbstractSessionIoHandler.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Channel.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Cipher.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Compression.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Digest.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/FactoryManager.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/KeyExchange.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/KeyPairProvider.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Mac.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/NamedFactory.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Random.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Signature.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/SshConstants.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/SshException.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/ mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/AbstractChannel.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/ChannelOutputStream.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/ChannelPipedInputStream.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/ChannelPipedOutputStream.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/Window.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/cipher/ mina/sshd/trunk/src/main/java/org/apache/sshd/common/cipher/AES128CBC.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/cipher/AES192CBC.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/cipher/AES256CBC.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/cipher/BaseCipher.java
[jira] Updated: (FTPSERVER-235) Documentation and code do not match for db user manager
[
https://issues.apache.org/jira/browse/FTPSERVER-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niklas Gustavsson updated FTPSERVER-235:
Fix Version/s: (was: 1.0.0-M4)
1.0.0-RC1
Affects Version/s: 1.0.0-M4
Documentation and code do not match for db user manager
---
Key: FTPSERVER-235
URL: https://issues.apache.org/jira/browse/FTPSERVER-235
Project: FtpServer
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0-M3, 1.0.0-M4
Reporter: nathan longley
Assignee: Niklas Gustavsson
Priority: Minor
Fix For: 1.0.0-RC1
In the examples on the
website(http://cwiki.apache.org/FTPSERVER/database-user-manager.html) it
shows:
authenticateSELECT uid from FTP_USER WHERE uid='{uid}' AND
userpassword='{userpassword}'/authenticate
(uid is wrong, is actually userid in all three places)
but the code will never set userpassword
in DbUserManager.authenticate
it does
HashMapString, Object map = new HashMapString, Object();
map.put(ATTR_LOGIN, escapeString(user));
String sql = StringUtils.replaceString(authenticateStmt, map);
LOG.info(sql);
and after it compares the stored password with the one the user entered.
is this designed to be this way or the way described in the documentation, i
think allowing it the way it is in the documentation allows for greater
flexibility.
if it is not a bug and is a design feature I will make a custom user manager.
a fix that would match the documentation would be
public User authenticate(Authentication authentication) throws
AuthenticationFailedException {
if (authentication instanceof UsernamePasswordAuthentication) {
UsernamePasswordAuthentication upauth =
(UsernamePasswordAuthentication) authentication;
String user = upauth.getUsername();
String password = upauth.getPassword();
if (user == null) {
throw new AuthenticationFailedException(Authentication
failed);
}
if (password == null) {
password = ;
}
Statement stmt = null;
ResultSet rs = null;
try {
// create the sql query
HashMapString, Object map = new HashMapString, Object();
map.put(ATTR_LOGIN, escapeString(user));
map.put(ATTR_PASSWORD, escapeString(password));
String sql = StringUtils.replaceString(authenticateStmt, map);
LOG.info(sql);
// execute query
stmt = createConnection().createStatement();
rs = stmt.executeQuery(sql);
if (rs.next()) {
try {
return getUserByName(user);
} catch (FtpException e) {
throw new
AuthenticationFailedException(Authentication failed, e);
}
} else {
throw new AuthenticationFailedException(Authentication
failed);
}
} catch (SQLException ex) {
LOG.error(DbUserManager.authenticate(), ex);
throw new AuthenticationFailedException(Authentication
failed, ex);
} finally {
closeQuitely(rs);
closeQuitely(stmt);
}
} else if (authentication instanceof AnonymousAuthentication) {
try {
if (doesExist(anonymous)) {
return getUserByName(anonymous);
} else {
throw new AuthenticationFailedException(Authentication
failed);
}
} catch (AuthenticationFailedException e) {
throw e;
} catch (FtpException e) {
throw new AuthenticationFailedException(Authentication
failed, e);
}
} else {
throw new IllegalArgumentException(Authentication not supported
by this user manager);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r723396 [1/12] - in /mina/sshd/trunk: ./ src/ src/docs/ src/main/ src/main/filtered-resources/ src/main/filtered-resources/org/ src/main/filtered-resources/org/apache/ src/main/filtere
Mark Webb wrote: Awesome. I am really looking forward to playing with this. One note, you may want to change the java package to org.apache.mina.sshd. More of an opinion of mine, but not sure if there are any guidelines on this. Currently, asyncweb and ftpserver use org.apache.asyncweb and org.apache.ftpserver. I'm not sure that we should do differentely for sshd ... -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: svn commit: r723396 [1/12] - in /mina/sshd/trunk: ./ src/ src/docs/ src/main/ src/main/filtered-resources/ src/main/filtered-resources/org/ src/main/filtered-resources/org/apache/ src/main/filtere
ok. no problem On Thu, Dec 4, 2008 at 5:05 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Mark Webb wrote: Awesome. I am really looking forward to playing with this. One note, you may want to change the java package to org.apache.mina.sshd. More of an opinion of mine, but not sure if there are any guidelines on this. Currently, asyncweb and ftpserver use org.apache.asyncweb and org.apache.ftpserver. I'm not sure that we should do differentely for sshd ... -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [jira] Commented: (FTPSERVER-229) MFMT Command - Code Enhancement
2008/12/4 Sai Pullabhotla (JIRA) [EMAIL PROTECTED] [ https://issues.apache.org/jira/browse/FTPSERVER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653293#action_12653293] Sai Pullabhotla commented on FTPSERVER-229: --- Nicklas, That's a very valid point. I did not even think about it. I guess, it could stay the way it is or if we want, we can create a SynchronizedSimpleDateFormat class using the Deligator pattern, but synchronize some methods like format and parse. Surely, the synchronization would have a performance hit too. We need to think some more about this. Yeah I was nearly caught here too. Anyway since I had already ported the DateFormat to DateUtils.java when I noticed the synchronization issue, I think we can leave it there so it will be easier to port if we decided to synchronize the method. I don't know if that sohuld be necessary though. Synchronized/new object: what do you like better? Thanks. Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Thu, Dec 4, 2008 at 5:37 AM, Niklas Gustavsson (JIRA) MFMT Command - Code Enhancement --- Key: FTPSERVER-229 URL: https://issues.apache.org/jira/browse/FTPSERVER-229 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Assignee: David Latorre Fix For: 1.0.0-RC1 MFMT Command - in the source code for this command (MFMT.java), the DateFormat and its configuration should be moved to static block for performance and to reduce object creations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (FTPSERVER-229) MFMT Command - Code Enhancement
[ https://issues.apache.org/jira/browse/FTPSERVER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reopened FTPSERVER-229: - We should see if we want to fix this , accessing DateFormat in a thread-safe way. Sorry for 'resolving' issues too soon (and not committing them!). MFMT Command - Code Enhancement --- Key: FTPSERVER-229 URL: https://issues.apache.org/jira/browse/FTPSERVER-229 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Assignee: David Latorre Fix For: 1.0.0-RC1 MFMT Command - in the source code for this command (MFMT.java), the DateFormat and its configuration should be moved to static block for performance and to reduce object creations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Vote] Release MINA 2.0.0-M4
Hi guys, we have released 2.0.0-M3 a few weeks ago (nov, 8th). I think it's time for the last milestone before RC1 now. We still have a few issues to fix (7), but so far, the API won't change now. I would call this release the API freeze release. Once release, we should work on 2.0-RC1, fixing the last bugs, and more important, adding documentation to the project. Hopefully, we can get a 2.0-RC1 by the very beginning of 2009, and a 2.0-GA a few weeks later, if everything goes right. So now, let's open the vote : [] +1, let's release 2.0.0-M4 and freeze the API [] +/- 0, abstain [] -1 : we are not ready, let's wait a bit more. Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [Vote] Release MINA 2.0.0-M4
And here is my vote : [X] +1, let's release 2.0.0-M4 and freeze the API -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [Vote] Release MINA 2.0.0-M4
[X] +1, let's release 2.0.0-M4 and freeze the API On Thu, Dec 4, 2008 at 7:50 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: And here is my vote : [X] +1, let's release 2.0.0-M4 and freeze the API -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [Vote] Release MINA 2.0.0-M4
+1 On Dec 4, 2008, at 4:49 PM, Emmanuel Lecharny wrote: Hi guys, we have released 2.0.0-M3 a few weeks ago (nov, 8th). I think it's time for the last milestone before RC1 now. We still have a few issues to fix (7), but so far, the API won't change now. I would call this release the API freeze release. Once release, we should work on 2.0-RC1, fixing the last bugs, and more important, adding documentation to the project. Hopefully, we can get a 2.0-RC1 by the very beginning of 2009, and a 2.0-GA a few weeks later, if everything goes right. So now, let's open the vote : [] +1, let's release 2.0.0-M4 and freeze the API [] +/- 0, abstain [] -1 : we are not ready, let's wait a bit more. Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: svn commit: r723396 [1/12] - in /mina/sshd/trunk: ./ src/ src/docs/ src/main/ src/main/filtered-resources/ src/main/filtered-resources/org/ src/main/filtered-resources/org/apache/ src/main/filtere
Yeah, I have been pondering that, but as Emmanuel said, I used the same convention than for ftpserver and asyncweb. On Thu, Dec 4, 2008 at 8:06 PM, Mark Webb [EMAIL PROTECTED] wrote: Awesome. I am really looking forward to playing with this. One note, you may want to change the java package to org.apache.mina.sshd. More of an opinion of mine, but not sure if there are any guidelines on this. Thanks Mark On Thu, Dec 4, 2008 at 1:59 PM, [EMAIL PROTECTED] wrote: Author: gnodet Date: Thu Dec 4 10:59:31 2008 New Revision: 723396 URL: http://svn.apache.org/viewvc?rev=723396view=rev Log: Commit code from the google project, refactored into org.apache.sshd package Added: mina/sshd/trunk/LICENSE.txt mina/sshd/trunk/NOTICE.txt mina/sshd/trunk/pom.xml mina/sshd/trunk/src/ mina/sshd/trunk/src/docs/ mina/sshd/trunk/src/docs/draft-ietf-secsh-filexfer-13.txt mina/sshd/trunk/src/docs/rfc4251.txt mina/sshd/trunk/src/docs/rfc4252.txt mina/sshd/trunk/src/docs/rfc4253.txt mina/sshd/trunk/src/docs/rfc4254.txt mina/sshd/trunk/src/docs/rfc4255.txt mina/sshd/trunk/src/docs/rfc4256.txt mina/sshd/trunk/src/docs/rfc4419.txt mina/sshd/trunk/src/main/ mina/sshd/trunk/src/main/filtered-resources/ mina/sshd/trunk/src/main/filtered-resources/org/ mina/sshd/trunk/src/main/filtered-resources/org/apache/ mina/sshd/trunk/src/main/filtered-resources/org/apache/sshd/ mina/sshd/trunk/src/main/filtered-resources/org/apache/sshd/sshd-version.properties mina/sshd/trunk/src/main/java/ mina/sshd/trunk/src/main/java/org/ mina/sshd/trunk/src/main/java/org/apache/ mina/sshd/trunk/src/main/java/org/apache/sshd/ mina/sshd/trunk/src/main/java/org/apache/sshd/ClientChannel.java mina/sshd/trunk/src/main/java/org/apache/sshd/ClientSession.java mina/sshd/trunk/src/main/java/org/apache/sshd/SshClient.java mina/sshd/trunk/src/main/java/org/apache/sshd/SshServer.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/ mina/sshd/trunk/src/main/java/org/apache/sshd/client/UserAuth.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/auth/ mina/sshd/trunk/src/main/java/org/apache/sshd/client/auth/UserAuthPassword.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/channel/ mina/sshd/trunk/src/main/java/org/apache/sshd/client/channel/AbstractClientChannel.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/channel/ChannelSession.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/channel/ChannelShell.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/kex/ mina/sshd/trunk/src/main/java/org/apache/sshd/client/kex/AbstractDHGClient.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/kex/DHG1.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/kex/DHG14.java mina/sshd/trunk/src/main/java/org/apache/sshd/client/session/ mina/sshd/trunk/src/main/java/org/apache/sshd/client/session/ClientSessionImpl.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/ mina/sshd/trunk/src/main/java/org/apache/sshd/common/AbstractFactoryManager.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/AbstractSessionIoHandler.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Channel.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Cipher.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Compression.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Digest.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/FactoryManager.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/KeyExchange.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/KeyPairProvider.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Mac.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/NamedFactory.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Random.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/Signature.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/SshConstants.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/SshException.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/ mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/AbstractChannel.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/ChannelOutputStream.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/ChannelPipedInputStream.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/ChannelPipedOutputStream.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/channel/Window.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/cipher/ mina/sshd/trunk/src/main/java/org/apache/sshd/common/cipher/AES128CBC.java mina/sshd/trunk/src/main/java/org/apache/sshd/common/cipher/AES192CBC.java
SSHD web site and issue tracker
I have create a confluence space for SSHD and Emmanuel set up the JIRA project. http://cwiki.apache.org/SSHD/ http://issues.apache.org/jira/browse/SSHD I've seen that the MINA web site uses confluence autoexport plugin, so I've used the same template. Can someone please update the rsync cron job (I suppose you use that) to add the SSHD wiki to the main MINA web site ? Or tell me how to do it if I can set that up. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
