[jira] [Closed] (FTPSERVER-445) ExecutorService Implementations Are Not Replaceable
[ https://issues.apache.org/jira/browse/FTPSERVER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-445. --- Resolution: Fixed Assignee: Niklas Gustavsson Fixed in d2ed495. Thanks for reporting! ExecutorService Implementations Are Not Replaceable --- Key: FTPSERVER-445 URL: https://issues.apache.org/jira/browse/FTPSERVER-445 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.6 Reporter: Adam Bien Assignee: Niklas Gustavsson Fix For: 1.0.7 Original Estimate: 1h Remaining Estimate: 1h The interface: org.apache.ftpserver.impl.FtpServerContext currently returns a concrete implementation of ExecutorService in method: public ThreadPoolExecutor getThreadPoolExecutor() and so prevents replacement of the given implementation. Change the return type to ExecutorService. Use case: Integration with JavaEE servers -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VYSPER-329) Server To Server inbound messages in jabber:server namespace, delivery fails
[
https://issues.apache.org/jira/browse/VYSPER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471522#comment-13471522
]
Niklas Gustavsson commented on VYSPER-329:
--
Also, what's packet which is sent in their own namespace. Message being part
of that wouldn't be treated like a regular stanza.
Server To Server inbound messages in jabber:server namespace, delivery fails
Key: VYSPER-329
URL: https://issues.apache.org/jira/browse/VYSPER-329
Project: VYSPER
Issue Type: Bug
Components: server-to-server
Affects Versions: 0.8
Reporter: Justin Spears
Priority: Critical
Original Estimate: 24h
Remaining Estimate: 24h
When recieving messages from external servers, if the message is in the
jabber:server namespace the message is not recognized and is sent to the
ServiceUnavailableHandler. This includes all IQ/Presence/... messages.
This was discovered testing against Openfire 3.2. According to a quick look
of the rfc these should be accepted.
Easy fix it is to change XMPPCoreStanzaHandler to check for either namespace
protected boolean verifyNamespace(Stanza stanza) {
String namespaceUri = stanza.getNamespaceURI();
return NamespaceURIs.JABBER_SERVER.equals(namespaceUri) ||
NamespaceURIs.JABBER_CLIENT.equals(namespaceUri);
}
I am not entirely sure this the correct way to handle it... but it works.
It should also log at least debug level when StanzaHandlerLookup returns
SERVICE_UNAVAILABLE_STANZA_ERROR_HANDLER it would have saved days of
debugging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VYSPER-325) Non-ASCII chars get crippled
[ https://issues.apache.org/jira/browse/VYSPER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471772#comment-13471772 ] Niklas Gustavsson commented on VYSPER-325: -- Awesome, good find! Non-ASCII chars get crippled Key: VYSPER-325 URL: https://issues.apache.org/jira/browse/VYSPER-325 Project: VYSPER Issue Type: Bug Components: BOSH Reporter: Bernd Fondermann Assignee: Bernd Fondermann Priority: Blocker Fix For: 0.8 When a stanza contains Characters which don't fit in a byte (Umlauts etc., eg. 0xff), these get crippled by XMLTokenizer: buffer.put((byte)c); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VYSPER-329) Server To Server inbound messages in jabber:server namespace, delivery fails
[
https://issues.apache.org/jira/browse/VYSPER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471778#comment-13471778
]
Niklas Gustavsson commented on VYSPER-329:
--
Alright, great getting the correct XML examples. That looks indeed like it's
the problem we discussed above that is causing this. I'm not sure what the best
fix is, Bernd would know better.
Server To Server inbound messages in jabber:server namespace, delivery fails
Key: VYSPER-329
URL: https://issues.apache.org/jira/browse/VYSPER-329
Project: VYSPER
Issue Type: Bug
Components: server-to-server
Affects Versions: 0.8
Reporter: Justin Spears
Priority: Critical
Original Estimate: 24h
Remaining Estimate: 24h
When recieving messages from external servers, if the message is in the
jabber:server namespace the message is not recognized and is sent to the
ServiceUnavailableHandler. This includes all IQ/Presence/... messages.
This was discovered testing against Openfire 3.2. According to a quick look
of the rfc these should be accepted.
Easy fix it is to change XMPPCoreStanzaHandler to check for either namespace
protected boolean verifyNamespace(Stanza stanza) {
String namespaceUri = stanza.getNamespaceURI();
return NamespaceURIs.JABBER_SERVER.equals(namespaceUri) ||
NamespaceURIs.JABBER_CLIENT.equals(namespaceUri);
}
I am not entirely sure this the correct way to handle it... but it works.
It should also log at least debug level when StanzaHandlerLookup returns
SERVICE_UNAVAILABLE_STANZA_ERROR_HANDLER it would have saved days of
debugging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VYSPER-329) Server To Server inbound messages in jabber:server namespace, delivery fails
[
https://issues.apache.org/jira/browse/VYSPER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471303#comment-13471303
]
Niklas Gustavsson commented on VYSPER-329:
--
However, it makes me wonder how s2s worked before?
jabber:server namespaced stanzas are rewritten into jabber:client in
ProtocolWorker, not sure what causes the Openfire stanzas not to work properly
in Vysper. jabber:server stanzas should indeed be supported.
Server To Server inbound messages in jabber:server namespace, delivery fails
Key: VYSPER-329
URL: https://issues.apache.org/jira/browse/VYSPER-329
Project: VYSPER
Issue Type: Bug
Components: server-to-server
Affects Versions: 0.8
Reporter: Justin Spears
Priority: Critical
Original Estimate: 24h
Remaining Estimate: 24h
When recieving messages from external servers, if the message is in the
jabber:server namespace the message is not recognized and is sent to the
ServiceUnavailableHandler. This includes all IQ/Presence/... messages.
This was discovered testing against Openfire 3.2. According to a quick look
of the rfc these should be accepted.
Easy fix it is to change XMPPCoreStanzaHandler to check for either namespace
protected boolean verifyNamespace(Stanza stanza) {
String namespaceUri = stanza.getNamespaceURI();
return NamespaceURIs.JABBER_SERVER.equals(namespaceUri) ||
NamespaceURIs.JABBER_CLIENT.equals(namespaceUri);
}
I am not entirely sure this the correct way to handle it... but it works.
It should also log at least debug level when StanzaHandlerLookup returns
SERVICE_UNAVAILABLE_STANZA_ERROR_HANDLER it would have saved days of
debugging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (VYSPER-329) Server To Server inbound messages in jabber:server namespace, delivery fails
[
https://issues.apache.org/jira/browse/VYSPER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471303#comment-13471303
]
Niklas Gustavsson edited comment on VYSPER-329 at 10/7/12 7:59 PM:
---
However, it makes me wonder how s2s worked before?
Edit: reread the code properly
The way it's supposed to work is that jabber:server namespaced stanzas are
rewritten into jabber:client in ProtocolWorker but that clearly comes too late.
I haven't tested s2s for some time, so I'm not sure what broke it. When
implemented, Openfire was one of the servers that it was tested against.
was (Author: niklas):
However, it makes me wonder how s2s worked before?
jabber:server namespaced stanzas are rewritten into jabber:client in
ProtocolWorker, not sure what causes the Openfire stanzas not to work properly
in Vysper. jabber:server stanzas should indeed be supported.
Server To Server inbound messages in jabber:server namespace, delivery fails
Key: VYSPER-329
URL: https://issues.apache.org/jira/browse/VYSPER-329
Project: VYSPER
Issue Type: Bug
Components: server-to-server
Affects Versions: 0.8
Reporter: Justin Spears
Priority: Critical
Original Estimate: 24h
Remaining Estimate: 24h
When recieving messages from external servers, if the message is in the
jabber:server namespace the message is not recognized and is sent to the
ServiceUnavailableHandler. This includes all IQ/Presence/... messages.
This was discovered testing against Openfire 3.2. According to a quick look
of the rfc these should be accepted.
Easy fix it is to change XMPPCoreStanzaHandler to check for either namespace
protected boolean verifyNamespace(Stanza stanza) {
String namespaceUri = stanza.getNamespaceURI();
return NamespaceURIs.JABBER_SERVER.equals(namespaceUri) ||
NamespaceURIs.JABBER_CLIENT.equals(namespaceUri);
}
I am not entirely sure this the correct way to handle it... but it works.
It should also log at least debug level when StanzaHandlerLookup returns
SERVICE_UNAVAILABLE_STANZA_ERROR_HANDLER it would have saved days of
debugging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-434) Cannot use FTP commands with Hadoop 1.0.3
[ https://issues.apache.org/jira/browse/FTPSERVER-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-434. --- Resolution: Won't Fix Assignee: Niklas Gustavsson HDFS-over-FTP is not part of FtpServer, so you will probably have more luck asking the developers of the HDFS-over-FTP project, e.g. at https://github.com/iponweb/hdfs-over-ftp Cannot use FTP commands with Hadoop 1.0.3 - Key: FTPSERVER-434 URL: https://issues.apache.org/jira/browse/FTPSERVER-434 Project: FtpServer Issue Type: Bug Components: Server Affects Versions: 1.0.3 Environment: Ubuntu 12.04 LTS Reporter: Rahul Dutta Assignee: Niklas Gustavsson When i am running HDFS-over-FTP and try to run any ftp command after logging in i get the response 200 Command PORT okay. 150 File status okay; about to open data connection. 550 Requested action not taken. and the log says 2012-09-25 22:19:51,904 : WARN : DefaultFtpHandler : RequestHandler.service() java.lang.NullPointerException at org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:453) at org.apache.hadoop.contrib.ftp.HdfsFileObject.getPermissions(HdfsFileObject.java:112) at org.apache.hadoop.contrib.ftp.HdfsFileObject.hasWritePermission(HdfsFileObject.java:207) at org.apache.ftpserver.command.MKD.execute(MKD.java:85) at org.apache.ftpserver.DefaultFtpHandler.messageReceived(DefaultFtpHandler.java:137) at org.apache.ftpserver.listener.nio.FtpHandlerAdapter.messageReceived(FtpHandlerAdapter.java:60) at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:752) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:414) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:49) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:832) at org.apache.ftpserver.filter.FtpLoggingFilter.messageReceived(FtpLoggingFilter.java:81) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:414) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:49) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:832) at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:60) at org.apache.mina.filter.logging.MdcInjectionFilter.filter(MdcInjectionFilter.java:137) at org.apache.mina.filter.util.CommonEventFilter.messageReceived(CommonEventFilter.java:70) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:414) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:49) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:832) at org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:379) at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:173) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:414) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:49) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:832) at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:60) at org.apache.mina.core.session.IoEvent.run(IoEvent.java:64) at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:551) at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(OrderedThreadPoolExecutor.java:543) at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThreadPoolExecutor.java:487) at java.lang.Thread.run(Thread.java:722) Please help me solve this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-425) Duplicate package org.apache.ftpserver.ftplet in ftpserver-core
[ https://issues.apache.org/jira/browse/FTPSERVER-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-425. --- Resolution: Fixed Assignee: Niklas Gustavsson Fixed in r1385176 and r1385165 Duplicate package org.apache.ftpserver.ftplet in ftpserver-core --- Key: FTPSERVER-425 URL: https://issues.apache.org/jira/browse/FTPSERVER-425 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.5, 1.0.6 Reporter: Joao Assuncao Assignee: Niklas Gustavsson Priority: Minor Attachments: core.diff, FTPSERVER-425.patch Original Estimate: 1h Remaining Estimate: 1h The package org.apache.ftpserver.ftplet is copied from ftplet-api into ftpserver when the bundle is assembled. When I disabled the bundle plugin in the pom for the core the package mentioned isn't copied. This page might provide some insight: http://felix.apache.org/site/apache-felix-bundle-plugin-faq.html#ApacheFelixBundlePluginFAQ-WhydoIseemoreclassesinmybundleafterupgradingtomavenbundleplugin2.0.0%253F Removing the line org.apache.ftpserver.* in private-package seems to solve the isssue The duplicate package is an issue when running inside an OSGI framework. In Apache Felix 3.2.2 I get a ClassCastException when I try to install a FtpLet -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-425) Duplicate package org.apache.ftpserver.ftplet in ftpserver-core
[ https://issues.apache.org/jira/browse/FTPSERVER-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13427653#comment-13427653 ] Niklas Gustavsson commented on FTPSERVER-425: - Thanks for reporting and sorry for the slow acting on this! The proposed patch won't work since a bunch of packages from core won't be included in the bundle. Instead, as the Felix link proposes, we seem to be able to remove the entire Private-package tag which generates a bundle without the org.apache.ftpserver.ftplet package, but all others. Also, the imports seems to look like expected. I'll upload a new proposed patch, please verify if this works for you before I commit it. Duplicate package org.apache.ftpserver.ftplet in ftpserver-core --- Key: FTPSERVER-425 URL: https://issues.apache.org/jira/browse/FTPSERVER-425 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.5, 1.0.6 Reporter: Joao Assuncao Priority: Minor Attachments: core.diff Original Estimate: 1h Remaining Estimate: 1h The package org.apache.ftpserver.ftplet is copied from ftplet-api into ftpserver when the bundle is assembled. When I disabled the bundle plugin in the pom for the core the package mentioned isn't copied. This page might provide some insight: http://felix.apache.org/site/apache-felix-bundle-plugin-faq.html#ApacheFelixBundlePluginFAQ-WhydoIseemoreclassesinmybundleafterupgradingtomavenbundleplugin2.0.0%253F Removing the line org.apache.ftpserver.* in private-package seems to solve the isssue The duplicate package is an issue when running inside an OSGI framework. In Apache Felix 3.2.2 I get a ClassCastException when I try to install a FtpLet -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-425) Duplicate package org.apache.ftpserver.ftplet in ftpserver-core
[ https://issues.apache.org/jira/browse/FTPSERVER-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-425: Attachment: FTPSERVER-425.patch Duplicate package org.apache.ftpserver.ftplet in ftpserver-core --- Key: FTPSERVER-425 URL: https://issues.apache.org/jira/browse/FTPSERVER-425 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.5, 1.0.6 Reporter: Joao Assuncao Priority: Minor Attachments: FTPSERVER-425.patch, core.diff Original Estimate: 1h Remaining Estimate: 1h The package org.apache.ftpserver.ftplet is copied from ftplet-api into ftpserver when the bundle is assembled. When I disabled the bundle plugin in the pom for the core the package mentioned isn't copied. This page might provide some insight: http://felix.apache.org/site/apache-felix-bundle-plugin-faq.html#ApacheFelixBundlePluginFAQ-WhydoIseemoreclassesinmybundleafterupgradingtomavenbundleplugin2.0.0%253F Removing the line org.apache.ftpserver.* in private-package seems to solve the isssue The duplicate package is an issue when running inside an OSGI framework. In Apache Felix 3.2.2 I get a ClassCastException when I try to install a FtpLet -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-433) Issues with data transfer for explicit SSL connections
[ https://issues.apache.org/jira/browse/FTPSERVER-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13427657#comment-13427657 ] Niklas Gustavsson commented on FTPSERVER-433: - It's hard to tell from the provided logs, but I would guess this is a network problem on the ports used for the data connection. Given you connect to localhost, I'm guessing that would exclude firewalls. You could run with SSL debugging enabled on the server, but I'm not sure that will tell you much more: -Djavax.net.debug=all http://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/ReadDebug.html Issues with data transfer for explicit SSL connections -- Key: FTPSERVER-433 URL: https://issues.apache.org/jira/browse/FTPSERVER-433 Project: FtpServer Issue Type: Bug Environment: Linux, java version 1.6.0_30, apache-ftpserver-1.0.5 Reporter: Søren Juul When using the sample configuration with SSL in explicit mode, some clients (e.g. FileZilla) have problems transferring. There is not problems browsing data, but when uploading the transfers cuts out regularly, and the transfer connections must be restarted. Bellow is sample output from the server log and FileZilla log. Server log: http://pastebin.com/VBbvux2G FileZilla log: http://pastebin.com/NP6Yh44s -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FTPSERVER-431) AITH SSL does not set data connection as protected
Niklas Gustavsson created FTPSERVER-431: --- Summary: AITH SSL does not set data connection as protected Key: FTPSERVER-431 URL: https://issues.apache.org/jira/browse/FTPSERVER-431 Project: FtpServer Issue Type: Bug Affects Versions: 1.0.6 Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 1.0.7 As per http://mail-archives.apache.org/mod_mbox/mina-ftpserver-users/201110.mbox/%3CCADsK-6N0M=jbhUhHF=C1D48htP+O5asn0YqsBvw7V6VnM=i...@mail.gmail.com%3E FtpServer does not correctly support AUTH SSL, nor AUTH TLS-P. We should use the patch provided in the mail thread and also support the deprecated auth types. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-431) AUTH SSL does not set data connection as protected
[ https://issues.apache.org/jira/browse/FTPSERVER-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-431: Summary: AUTH SSL does not set data connection as protected (was: AITH SSL does not set data connection as protected) AUTH SSL does not set data connection as protected -- Key: FTPSERVER-431 URL: https://issues.apache.org/jira/browse/FTPSERVER-431 Project: FtpServer Issue Type: Bug Affects Versions: 1.0.6 Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 1.0.7, 1.1.0 As per http://mail-archives.apache.org/mod_mbox/mina-ftpserver-users/201110.mbox/%3CCADsK-6N0M=jbhUhHF=C1D48htP+O5asn0YqsBvw7V6VnM=i...@mail.gmail.com%3E FtpServer does not correctly support AUTH SSL, nor AUTH TLS-P. We should use the patch provided in the mail thread and also support the deprecated auth types. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-431) AUTH SSL does not set data connection as protected
[ https://issues.apache.org/jira/browse/FTPSERVER-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-431. --- Resolution: Fixed Fixed in r1332844 and r1332855 AUTH SSL does not set data connection as protected -- Key: FTPSERVER-431 URL: https://issues.apache.org/jira/browse/FTPSERVER-431 Project: FtpServer Issue Type: Bug Affects Versions: 1.0.6 Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 1.0.7, 1.1.0 As per http://mail-archives.apache.org/mod_mbox/mina-ftpserver-users/201110.mbox/%3CCADsK-6N0M=jbhUhHF=C1D48htP+O5asn0YqsBvw7V6VnM=i...@mail.gmail.com%3E FtpServer does not correctly support AUTH SSL, nor AUTH TLS-P. We should use the patch provided in the mail thread and also support the deprecated auth types. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (VYSPER-306) Websocket plugin too tightly bound to Jetty
[ https://issues.apache.org/jira/browse/VYSPER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed VYSPER-306. Resolution: Fixed Implemented support for Tomcat (and generalized the code in general) in r1328861. Websocket plugin too tightly bound to Jetty --- Key: VYSPER-306 URL: https://issues.apache.org/jira/browse/VYSPER-306 Project: VYSPER Issue Type: Bug Components: extension Affects Versions: 0.7 Reporter: Stig Runar Vangen Assignee: Niklas Gustavsson Labels: extension, websocket I tried to integrate the websocket plugin into our system. Instead of setting up a jetty endpoint I wanted to use an existing server. This works fine if the server you want to integrate against is a Jetty server. In my case, the server is a Tomcat server. This resulted in Jetty-based errors when accessing the target address. The implementation should be server-independent, so that it could be used in more contexts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-424) Leak of allowed passive ports
[ https://issues.apache.org/jira/browse/FTPSERVER-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13093161#comment-13093161 ] Niklas Gustavsson commented on FTPSERVER-424: - I've commtted a fix in rev 1162981 in https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.x . Could you please verify that this fixes your problem and we'll try to get a quick release out? Leak of allowed passive ports - Key: FTPSERVER-424 URL: https://issues.apache.org/jira/browse/FTPSERVER-424 Project: FtpServer Issue Type: Bug Affects Versions: 1.0.6 Reporter: Taras Puchko In several hours after start the server cannot accept passive connections if allowed passive ports are configured. This is caused by FTPSERVER-420, org.apache.ftpserver.impl.PassivePorts.reserveNextPort() lines 218-219, where the value removed from the freeList might be different from the value added to the usedList, if checkPortUnbound returns false before. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-842) Crash on Android
[
https://issues.apache.org/jira/browse/DIRMINA-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13061970#comment-13061970
]
Niklas Gustavsson commented on DIRMINA-842:
---
I tested on the emulator, I do not have access to a real phone. I did get some
OOMs and had to increase the memory for applications. Other than that, no
changes was needed.
Crash on Android
Key: DIRMINA-842
URL: https://issues.apache.org/jira/browse/DIRMINA-842
Project: MINA
Issue Type: Bug
Environment: android 2.2 (emulator)
Reporter: Kaja Hovi
Assignee: Niklas Gustavsson
Labels: android, ssl
I tried to run VYSPER on android, with just one fix - getting bks keystore
instead of jks (or just KeyStore ks =
KeyStore.getInstance(KeyStore.getDefaultType()); to make it work on both
platforms) , I used portecle to convert VYSPER default jks certificate into
bks format.
When I run server on android and try to autenticate, I get following
exception:
06-30 21:36:40.109: ERROR/L4J(342): 1178740 [NioProcessor-2] ERROR
org.apache.mina.filter.ssl.SslHandler - Invalid Handshaking
StateNOT_HANDSHAKING while processing the Handshake for session 3
06-30 21:36:40.109: WARN/L4J(342): 1178743 [NioProcessor-2] WARN
org.apache.vysper.mina.XmppIoHandlerAdapter - error caught on transportation
layer: {}
06-30 21:36:40.116: WARN/System.err(342): java.lang.IllegalStateException:
Invalid Handshaking StateNOT_HANDSHAKING while processing the Handshake for
session 3
06-30 21:36:40.116: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:593)
06-30 21:36:40.126: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.writeNetBuffer(SslHandler.java:632)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:586)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.messageReceived(SslHandler.java:349)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:476)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:119)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:426)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:693)
06-30 21:36:40.176: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:646)
06-30 21:36:40.193: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:635)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:67)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1079)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
06-30 21:36:40.206: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1068)
06-30 21:36:40.215: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:561)
06-30 21:36:40.215: WARN/System.err(342): at
java.lang.Thread.run(Thread.java:1096)
Any ideas what might cause this and how to fix it?
Same project works fine in JRE (with both bks and jks).
I found similar issue here (mina+android):
http://androiddiscuss.com/1-android-discuss/1022.html
I hope I am posting in correct place, since it is also about project VYSPER
and it seems possibly like android sdk bug, sorry if not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-842) Crash on Android
[
https://issues.apache.org/jira/browse/DIRMINA-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13062041#comment-13062041
]
Niklas Gustavsson commented on DIRMINA-842:
---
Using the android command, you can edit the allowed memory per application in
the AVD definition. The default was 46 Mb I think, I increase it to 128 Mb
Crash on Android
Key: DIRMINA-842
URL: https://issues.apache.org/jira/browse/DIRMINA-842
Project: MINA
Issue Type: Bug
Environment: android 2.2 (emulator)
Reporter: Kaja Hovi
Assignee: Niklas Gustavsson
Labels: android, ssl
I tried to run VYSPER on android, with just one fix - getting bks keystore
instead of jks (or just KeyStore ks =
KeyStore.getInstance(KeyStore.getDefaultType()); to make it work on both
platforms) , I used portecle to convert VYSPER default jks certificate into
bks format.
When I run server on android and try to autenticate, I get following
exception:
06-30 21:36:40.109: ERROR/L4J(342): 1178740 [NioProcessor-2] ERROR
org.apache.mina.filter.ssl.SslHandler - Invalid Handshaking
StateNOT_HANDSHAKING while processing the Handshake for session 3
06-30 21:36:40.109: WARN/L4J(342): 1178743 [NioProcessor-2] WARN
org.apache.vysper.mina.XmppIoHandlerAdapter - error caught on transportation
layer: {}
06-30 21:36:40.116: WARN/System.err(342): java.lang.IllegalStateException:
Invalid Handshaking StateNOT_HANDSHAKING while processing the Handshake for
session 3
06-30 21:36:40.116: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:593)
06-30 21:36:40.126: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.writeNetBuffer(SslHandler.java:632)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:586)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.messageReceived(SslHandler.java:349)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:476)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:119)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:426)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:693)
06-30 21:36:40.176: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:646)
06-30 21:36:40.193: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:635)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:67)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1079)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
06-30 21:36:40.206: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1068)
06-30 21:36:40.215: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:561)
06-30 21:36:40.215: WARN/System.err(342): at
java.lang.Thread.run(Thread.java:1096)
Any ideas what might cause this and how to fix it?
Same project works fine in JRE (with both bks and jks).
I found similar issue here (mina+android):
http://androiddiscuss.com/1-android-discuss/1022.html
I hope I am posting in correct place, since it is also about project VYSPER
and it seems possibly like android sdk bug, sorry if not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-842) Crash on Android
[
https://issues.apache.org/jira/browse/DIRMINA-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13061174#comment-13061174
]
Niklas Gustavsson commented on DIRMINA-842:
---
Could you provide the output of logcat?
Crash on Android
Key: DIRMINA-842
URL: https://issues.apache.org/jira/browse/DIRMINA-842
Project: MINA
Issue Type: Bug
Environment: android 2.2 (emulator)
Reporter: Kaja Hovi
Assignee: Niklas Gustavsson
Labels: android, ssl
I tried to run VYSPER on android, with just one fix - getting bks keystore
instead of jks (or just KeyStore ks =
KeyStore.getInstance(KeyStore.getDefaultType()); to make it work on both
platforms) , I used portecle to convert VYSPER default jks certificate into
bks format.
When I run server on android and try to autenticate, I get following
exception:
06-30 21:36:40.109: ERROR/L4J(342): 1178740 [NioProcessor-2] ERROR
org.apache.mina.filter.ssl.SslHandler - Invalid Handshaking
StateNOT_HANDSHAKING while processing the Handshake for session 3
06-30 21:36:40.109: WARN/L4J(342): 1178743 [NioProcessor-2] WARN
org.apache.vysper.mina.XmppIoHandlerAdapter - error caught on transportation
layer: {}
06-30 21:36:40.116: WARN/System.err(342): java.lang.IllegalStateException:
Invalid Handshaking StateNOT_HANDSHAKING while processing the Handshake for
session 3
06-30 21:36:40.116: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:593)
06-30 21:36:40.126: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.writeNetBuffer(SslHandler.java:632)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:586)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.messageReceived(SslHandler.java:349)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:476)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:119)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:426)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:693)
06-30 21:36:40.176: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:646)
06-30 21:36:40.193: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:635)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:67)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1079)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
06-30 21:36:40.206: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1068)
06-30 21:36:40.215: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:561)
06-30 21:36:40.215: WARN/System.err(342): at
java.lang.Thread.run(Thread.java:1096)
Any ideas what might cause this and how to fix it?
Same project works fine in JRE (with both bks and jks).
I found similar issue here (mina+android):
http://androiddiscuss.com/1-android-discuss/1022.html
I hope I am posting in correct place, since it is also about project VYSPER
and it seems possibly like android sdk bug, sorry if not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-842) Crash on Android
[
https://issues.apache.org/jira/browse/DIRMINA-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059426#comment-13059426
]
Niklas Gustavsson commented on DIRMINA-842:
---
Alright, I've analysed this on Android 3.0. With a patch to Vysper to enable
BKS keystores (or any other type. Will commit to Vysper) I get the same
behavior. It seems like the SSL implementation in Android will end up in the
state NOT_HANDSHAKING rather than FINISHED when done. The following patch to
MINA will fix things:
Index: src/main/java/org/apache/mina/filter/ssl/SslHandler.java
===
--- src/main/java/org/apache/mina/filter/ssl/SslHandler.java(revision
1142628)
+++ src/main/java/org/apache/mina/filter/ssl/SslHandler.java(working copy)
@@ -509,6 +510,7 @@
for (;;) {
switch (handshakeStatus) {
case FINISHED:
+case NOT_HANDSHAKING:
if ( LOGGER.isDebugEnabled()) {
LOGGER.debug({} processing the FINISHED state,
sslFilter.getSessionInfo(session));
}
With this patch in place, I can connect to Vysper running on the Android
emulator. Pretty cool actually :-)
Now, do we want this patch in MINA? I'm not familiar enough with this
particular code to understand the dangers.
Crash on Android
Key: DIRMINA-842
URL: https://issues.apache.org/jira/browse/DIRMINA-842
Project: MINA
Issue Type: Bug
Environment: android 2.2 (emulator)
Reporter: Kaja Hovi
Assignee: Niklas Gustavsson
Labels: android, ssl
I tried to run VYSPER on android, with just one fix - getting bks keystore
instead of jks (or just KeyStore ks =
KeyStore.getInstance(KeyStore.getDefaultType()); to make it work on both
platforms) , I used portecle to convert VYSPER default jks certificate into
bks format.
When I run server on android and try to autenticate, I get following
exception:
06-30 21:36:40.109: ERROR/L4J(342): 1178740 [NioProcessor-2] ERROR
org.apache.mina.filter.ssl.SslHandler - Invalid Handshaking
StateNOT_HANDSHAKING while processing the Handshake for session 3
06-30 21:36:40.109: WARN/L4J(342): 1178743 [NioProcessor-2] WARN
org.apache.vysper.mina.XmppIoHandlerAdapter - error caught on transportation
layer: {}
06-30 21:36:40.116: WARN/System.err(342): java.lang.IllegalStateException:
Invalid Handshaking StateNOT_HANDSHAKING while processing the Handshake for
session 3
06-30 21:36:40.116: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:593)
06-30 21:36:40.126: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.writeNetBuffer(SslHandler.java:632)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:586)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.messageReceived(SslHandler.java:349)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:476)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:119)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:426)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:693)
06-30 21:36:40.176: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:646)
06-30 21:36:40.193: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:635)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:67)
06-30 21:36:40.196: WARN/System.err(342): at
[jira] [Commented] (DIRMINA-842) Crash on Android
[
https://issues.apache.org/jira/browse/DIRMINA-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059588#comment-13059588
]
Niklas Gustavsson commented on DIRMINA-842:
---
My project for running Vysper on Android is now up on Github:
https://github.com/protocol7/vysper-on-android
Crash on Android
Key: DIRMINA-842
URL: https://issues.apache.org/jira/browse/DIRMINA-842
Project: MINA
Issue Type: Bug
Environment: android 2.2 (emulator)
Reporter: Kaja Hovi
Assignee: Niklas Gustavsson
Labels: android, ssl
I tried to run VYSPER on android, with just one fix - getting bks keystore
instead of jks (or just KeyStore ks =
KeyStore.getInstance(KeyStore.getDefaultType()); to make it work on both
platforms) , I used portecle to convert VYSPER default jks certificate into
bks format.
When I run server on android and try to autenticate, I get following
exception:
06-30 21:36:40.109: ERROR/L4J(342): 1178740 [NioProcessor-2] ERROR
org.apache.mina.filter.ssl.SslHandler - Invalid Handshaking
StateNOT_HANDSHAKING while processing the Handshake for session 3
06-30 21:36:40.109: WARN/L4J(342): 1178743 [NioProcessor-2] WARN
org.apache.vysper.mina.XmppIoHandlerAdapter - error caught on transportation
layer: {}
06-30 21:36:40.116: WARN/System.err(342): java.lang.IllegalStateException:
Invalid Handshaking StateNOT_HANDSHAKING while processing the Handshake for
session 3
06-30 21:36:40.116: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:593)
06-30 21:36:40.126: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.writeNetBuffer(SslHandler.java:632)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:586)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.messageReceived(SslHandler.java:349)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:476)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:119)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:426)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:693)
06-30 21:36:40.176: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:646)
06-30 21:36:40.193: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:635)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:67)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1079)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
06-30 21:36:40.206: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1068)
06-30 21:36:40.215: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:561)
06-30 21:36:40.215: WARN/System.err(342): at
java.lang.Thread.run(Thread.java:1096)
Any ideas what might cause this and how to fix it?
Same project works fine in JRE (with both bks and jks).
I found similar issue here (mina+android):
http://androiddiscuss.com/1-android-discuss/1022.html
I hope I am posting in correct place, since it is also about project VYSPER
and it seems possibly like android sdk bug, sorry if not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VYSPER-291) Add configuration of keystore type
Add configuration of keystore type -- Key: VYSPER-291 URL: https://issues.apache.org/jira/browse/VYSPER-291 Project: VYSPER Issue Type: Improvement Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 Some JVM does not support JKS keystores, e.g. Android. And in some cases, you might want to use other keystores for other reasons. Thus, Vysper should support configuring the keystore type. Vysper currently hardcode this to JKS in AbstractTLSContextFactory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (VYSPER-291) Add configuration of keystore type
[ https://issues.apache.org/jira/browse/VYSPER-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed VYSPER-291. Resolution: Fixed Fixed in rev 1142793 Add configuration of keystore type -- Key: VYSPER-291 URL: https://issues.apache.org/jira/browse/VYSPER-291 Project: VYSPER Issue Type: Improvement Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 Some JVM does not support JKS keystores, e.g. Android. And in some cases, you might want to use other keystores for other reasons. Thus, Vysper should support configuring the keystore type. Vysper currently hardcode this to JKS in AbstractTLSContextFactory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (VYSPER-188) java.security.KeyStoreException running XMPPServer with Apache Harmony
[ https://issues.apache.org/jira/browse/VYSPER-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed VYSPER-188. Resolution: Fixed Fix Version/s: 0.8 Assignee: Niklas Gustavsson Configuring the keystore type now support in rev r1142793. java.security.KeyStoreException running XMPPServer with Apache Harmony -- Key: VYSPER-188 URL: https://issues.apache.org/jira/browse/VYSPER-188 Project: VYSPER Issue Type: Bug Components: authentication Environment: Ubuntu 9.10 Apache Harmony harmony 5.0 M12a Reporter: Jean-Sebastien Delfino Assignee: Niklas Gustavsson Fix For: 0.8 Running XMPPServer on Apache Harmony 5.0 M12a causes this exception: java.lang.RuntimeException: java.security.KeyStoreException: KeyStore JKS implementation not found at org.apache.vysper.xmpp.server.DefaultServerRuntimeContext.setTlsContextFactory(DefaultServerRuntimeContext.java:204) at org.apache.vysper.xmpp.server.XMPPServer.start(XMPPServer.java:117) at test.TestVysperServer.main(TestVysperServer.java:60) Caused by: java.security.KeyStoreException: KeyStore JKS implementation not found at java.security.KeyStore.getInstance(KeyStore.java:120) at org.apache.vysper.xmpp.cryptography.AbstractTLSContextFactory.createSSLContext(AbstractTLSContextFactory.java:76) at org.apache.vysper.xmpp.cryptography.AbstractTLSContextFactory.getSSLContext(AbstractTLSContextFactory.java:70) at org.apache.vysper.xmpp.server.DefaultServerRuntimeContext.setTlsContextFactory(DefaultServerRuntimeContext.java:202) at org.apache.vysper.xmpp.server.XMPPServer.start(XMPPServer.java:117) ... 1 more The same test [1] runs OK with other JDKs. Vysper currently hardcodes the Keystore type to JKS [2], which is not supported by Harmony [3] There should be a way to make this configurable and support another Keystore type like Bouncy Castle BKS (perhaps a setter method on AbstractTLSContextFactory and allow for injecting a TLSContextFactory into XMPPServer.) [1] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/components/chat/test/TestVysperServer.java [2] http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/cryptography/AbstractTLSContextFactory.java [3] http://issues.apache.org/jira/browse/HARMONY-6098 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VYSPER-290) Crash on Android
[
https://issues.apache.org/jira/browse/VYSPER-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058472#comment-13058472
]
Niklas Gustavsson commented on VYSPER-290:
--
Can confirm this problem, we should fix it.
Crash on Android
Key: VYSPER-290
URL: https://issues.apache.org/jira/browse/VYSPER-290
Project: VYSPER
Issue Type: Bug
Environment: android 2.2 (emulator)
Reporter: Kaja Hovi
Labels: android, ssl
I tried to run VYSPER on android, with just one fix - getting bks keystore
instead of jks (or just KeyStore ks =
KeyStore.getInstance(KeyStore.getDefaultType()); to make it work on both
platforms) , I used portecle to convert VYSPER default jks certificate into
bks format.
When I run server on android and try to autenticate, I get following
exception:
06-30 21:36:40.109: ERROR/L4J(342): 1178740 [NioProcessor-2] ERROR
org.apache.mina.filter.ssl.SslHandler - Invalid Handshaking
StateNOT_HANDSHAKING while processing the Handshake for session 3
06-30 21:36:40.109: WARN/L4J(342): 1178743 [NioProcessor-2] WARN
org.apache.vysper.mina.XmppIoHandlerAdapter - error caught on transportation
layer: {}
06-30 21:36:40.116: WARN/System.err(342): java.lang.IllegalStateException:
Invalid Handshaking StateNOT_HANDSHAKING while processing the Handshake for
session 3
06-30 21:36:40.116: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:593)
06-30 21:36:40.126: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.writeNetBuffer(SslHandler.java:632)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:586)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.messageReceived(SslHandler.java:349)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:476)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:119)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:426)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:693)
06-30 21:36:40.176: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:646)
06-30 21:36:40.193: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:635)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:67)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1079)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
06-30 21:36:40.206: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1068)
06-30 21:36:40.215: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:561)
06-30 21:36:40.215: WARN/System.err(342): at
java.lang.Thread.run(Thread.java:1096)
Any ideas what might cause this and how to fix it?
Same project works fine in JRE (with both bks and jks).
I found similar issue here (mina+android):
http://androiddiscuss.com/1-android-discuss/1022.html
I hope I am posting in correct place, since it is also about project VYSPER
and it seems possibly like android sdk bug, sorry if not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (VYSPER-290) Crash on Android
[
https://issues.apache.org/jira/browse/VYSPER-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niklas Gustavsson reassigned VYSPER-290:
Assignee: Niklas Gustavsson
Crash on Android
Key: VYSPER-290
URL: https://issues.apache.org/jira/browse/VYSPER-290
Project: VYSPER
Issue Type: Bug
Environment: android 2.2 (emulator)
Reporter: Kaja Hovi
Assignee: Niklas Gustavsson
Labels: android, ssl
I tried to run VYSPER on android, with just one fix - getting bks keystore
instead of jks (or just KeyStore ks =
KeyStore.getInstance(KeyStore.getDefaultType()); to make it work on both
platforms) , I used portecle to convert VYSPER default jks certificate into
bks format.
When I run server on android and try to autenticate, I get following
exception:
06-30 21:36:40.109: ERROR/L4J(342): 1178740 [NioProcessor-2] ERROR
org.apache.mina.filter.ssl.SslHandler - Invalid Handshaking
StateNOT_HANDSHAKING while processing the Handshake for session 3
06-30 21:36:40.109: WARN/L4J(342): 1178743 [NioProcessor-2] WARN
org.apache.vysper.mina.XmppIoHandlerAdapter - error caught on transportation
layer: {}
06-30 21:36:40.116: WARN/System.err(342): java.lang.IllegalStateException:
Invalid Handshaking StateNOT_HANDSHAKING while processing the Handshake for
session 3
06-30 21:36:40.116: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:593)
06-30 21:36:40.126: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.writeNetBuffer(SslHandler.java:632)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:586)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.messageReceived(SslHandler.java:349)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:476)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:119)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:426)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:693)
06-30 21:36:40.176: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:646)
06-30 21:36:40.193: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:635)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:67)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1079)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
06-30 21:36:40.206: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1068)
06-30 21:36:40.215: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:561)
06-30 21:36:40.215: WARN/System.err(342): at
java.lang.Thread.run(Thread.java:1096)
Any ideas what might cause this and how to fix it?
Same project works fine in JRE (with both bks and jks).
I found similar issue here (mina+android):
http://androiddiscuss.com/1-android-discuss/1022.html
I hope I am posting in correct place, since it is also about project VYSPER
and it seems possibly like android sdk bug, sorry if not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VYSPER-290) Crash on Android
[
https://issues.apache.org/jira/browse/VYSPER-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058471#comment-13058471
]
Niklas Gustavsson commented on VYSPER-290:
--
Reported in the wrong JIRA project, moved to VYSPER project
Crash on Android
Key: VYSPER-290
URL: https://issues.apache.org/jira/browse/VYSPER-290
Project: VYSPER
Issue Type: Bug
Environment: android 2.2 (emulator)
Reporter: Kaja Hovi
Labels: android, ssl
I tried to run VYSPER on android, with just one fix - getting bks keystore
instead of jks (or just KeyStore ks =
KeyStore.getInstance(KeyStore.getDefaultType()); to make it work on both
platforms) , I used portecle to convert VYSPER default jks certificate into
bks format.
When I run server on android and try to autenticate, I get following
exception:
06-30 21:36:40.109: ERROR/L4J(342): 1178740 [NioProcessor-2] ERROR
org.apache.mina.filter.ssl.SslHandler - Invalid Handshaking
StateNOT_HANDSHAKING while processing the Handshake for session 3
06-30 21:36:40.109: WARN/L4J(342): 1178743 [NioProcessor-2] WARN
org.apache.vysper.mina.XmppIoHandlerAdapter - error caught on transportation
layer: {}
06-30 21:36:40.116: WARN/System.err(342): java.lang.IllegalStateException:
Invalid Handshaking StateNOT_HANDSHAKING while processing the Handshake for
session 3
06-30 21:36:40.116: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:593)
06-30 21:36:40.126: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.writeNetBuffer(SslHandler.java:632)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:586)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.messageReceived(SslHandler.java:349)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:476)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:119)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:426)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:693)
06-30 21:36:40.176: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:646)
06-30 21:36:40.193: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:635)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:67)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1079)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
06-30 21:36:40.206: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1068)
06-30 21:36:40.215: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:561)
06-30 21:36:40.215: WARN/System.err(342): at
java.lang.Thread.run(Thread.java:1096)
Any ideas what might cause this and how to fix it?
Same project works fine in JRE (with both bks and jks).
I found similar issue here (mina+android):
http://androiddiscuss.com/1-android-discuss/1022.html
I hope I am posting in correct place, since it is also about project VYSPER
and it seems possibly like android sdk bug, sorry if not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Moved] (VYSPER-290) Crash on Android
[
https://issues.apache.org/jira/browse/VYSPER-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niklas Gustavsson moved DIRMINA-841 to VYSPER-290:
--
Component/s: (was: Core)
Affects Version/s: (was: 2.0.2)
Key: VYSPER-290 (was: DIRMINA-841)
Project: VYSPER (was: MINA)
Crash on Android
Key: VYSPER-290
URL: https://issues.apache.org/jira/browse/VYSPER-290
Project: VYSPER
Issue Type: Bug
Environment: android 2.2 (emulator)
Reporter: Kaja Hovi
Labels: android, ssl
I tried to run VYSPER on android, with just one fix - getting bks keystore
instead of jks (or just KeyStore ks =
KeyStore.getInstance(KeyStore.getDefaultType()); to make it work on both
platforms) , I used portecle to convert VYSPER default jks certificate into
bks format.
When I run server on android and try to autenticate, I get following
exception:
06-30 21:36:40.109: ERROR/L4J(342): 1178740 [NioProcessor-2] ERROR
org.apache.mina.filter.ssl.SslHandler - Invalid Handshaking
StateNOT_HANDSHAKING while processing the Handshake for session 3
06-30 21:36:40.109: WARN/L4J(342): 1178743 [NioProcessor-2] WARN
org.apache.vysper.mina.XmppIoHandlerAdapter - error caught on transportation
layer: {}
06-30 21:36:40.116: WARN/System.err(342): java.lang.IllegalStateException:
Invalid Handshaking StateNOT_HANDSHAKING while processing the Handshake for
session 3
06-30 21:36:40.116: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:593)
06-30 21:36:40.126: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.writeNetBuffer(SslHandler.java:632)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:586)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.messageReceived(SslHandler.java:349)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:476)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:119)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:426)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:693)
06-30 21:36:40.176: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:646)
06-30 21:36:40.193: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:635)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:67)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1079)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
06-30 21:36:40.206: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1068)
06-30 21:36:40.215: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:561)
06-30 21:36:40.215: WARN/System.err(342): at
java.lang.Thread.run(Thread.java:1096)
Any ideas what might cause this and how to fix it?
Same project works fine in JRE (with both bks and jks).
I found similar issue here (mina+android):
http://androiddiscuss.com/1-android-discuss/1022.html
I hope I am posting in correct place, since it is also about project VYSPER
and it seems possibly like android sdk bug, sorry if not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (VYSPER-289) Mistake in documentation
[ https://issues.apache.org/jira/browse/VYSPER-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed VYSPER-289. Resolution: Fixed Assignee: Niklas Gustavsson Thanks, fixed now (will take some time to replicate)! Mistake in documentation Key: VYSPER-289 URL: https://issues.apache.org/jira/browse/VYSPER-289 Project: VYSPER Issue Type: Bug Affects Versions: 0.7 Environment: windows Reporter: Kaja Hovi Assignee: Niklas Gustavsson Priority: Trivial Labels: documentation I hope I am posting correct issue type, sorry if not. In documentation at: http://mina.apache.org/vysper/embed-into-another-application.html There is for example line of code: accountManagement.addUser(us...@myembeddedjabber.com, password1); but in version 0.7 method: org.apache.vysper.xmpp.authorization.AccountManagement.addUser accepts first parameter of type: org.apache.vysper.xmpp.addressing.Entity I guess the new correct way could be this: accountManagement.addUser(EntityImpl.parse(us...@myembeddedjabber.com), password1); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VYSPER-290) Crash on Android
[
https://issues.apache.org/jira/browse/VYSPER-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058522#comment-13058522
]
Niklas Gustavsson commented on VYSPER-290:
--
Yes, you're probably right. I'll move it back.
Crash on Android
Key: VYSPER-290
URL: https://issues.apache.org/jira/browse/VYSPER-290
Project: VYSPER
Issue Type: Bug
Environment: android 2.2 (emulator)
Reporter: Kaja Hovi
Assignee: Niklas Gustavsson
Labels: android, ssl
I tried to run VYSPER on android, with just one fix - getting bks keystore
instead of jks (or just KeyStore ks =
KeyStore.getInstance(KeyStore.getDefaultType()); to make it work on both
platforms) , I used portecle to convert VYSPER default jks certificate into
bks format.
When I run server on android and try to autenticate, I get following
exception:
06-30 21:36:40.109: ERROR/L4J(342): 1178740 [NioProcessor-2] ERROR
org.apache.mina.filter.ssl.SslHandler - Invalid Handshaking
StateNOT_HANDSHAKING while processing the Handshake for session 3
06-30 21:36:40.109: WARN/L4J(342): 1178743 [NioProcessor-2] WARN
org.apache.vysper.mina.XmppIoHandlerAdapter - error caught on transportation
layer: {}
06-30 21:36:40.116: WARN/System.err(342): java.lang.IllegalStateException:
Invalid Handshaking StateNOT_HANDSHAKING while processing the Handshake for
session 3
06-30 21:36:40.116: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:593)
06-30 21:36:40.126: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.writeNetBuffer(SslHandler.java:632)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:586)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.messageReceived(SslHandler.java:349)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:476)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:119)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:426)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:693)
06-30 21:36:40.176: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:646)
06-30 21:36:40.193: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:635)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:67)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1079)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
06-30 21:36:40.206: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1068)
06-30 21:36:40.215: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:561)
06-30 21:36:40.215: WARN/System.err(342): at
java.lang.Thread.run(Thread.java:1096)
Any ideas what might cause this and how to fix it?
Same project works fine in JRE (with both bks and jks).
I found similar issue here (mina+android):
http://androiddiscuss.com/1-android-discuss/1022.html
I hope I am posting in correct place, since it is also about project VYSPER
and it seems possibly like android sdk bug, sorry if not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Moved] (DIRMINA-842) Crash on Android
[
https://issues.apache.org/jira/browse/DIRMINA-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niklas Gustavsson moved VYSPER-290 to DIRMINA-842:
--
Key: DIRMINA-842 (was: VYSPER-290)
Project: MINA (was: VYSPER)
Crash on Android
Key: DIRMINA-842
URL: https://issues.apache.org/jira/browse/DIRMINA-842
Project: MINA
Issue Type: Bug
Environment: android 2.2 (emulator)
Reporter: Kaja Hovi
Assignee: Niklas Gustavsson
Labels: android, ssl
I tried to run VYSPER on android, with just one fix - getting bks keystore
instead of jks (or just KeyStore ks =
KeyStore.getInstance(KeyStore.getDefaultType()); to make it work on both
platforms) , I used portecle to convert VYSPER default jks certificate into
bks format.
When I run server on android and try to autenticate, I get following
exception:
06-30 21:36:40.109: ERROR/L4J(342): 1178740 [NioProcessor-2] ERROR
org.apache.mina.filter.ssl.SslHandler - Invalid Handshaking
StateNOT_HANDSHAKING while processing the Handshake for session 3
06-30 21:36:40.109: WARN/L4J(342): 1178743 [NioProcessor-2] WARN
org.apache.vysper.mina.XmppIoHandlerAdapter - error caught on transportation
layer: {}
06-30 21:36:40.116: WARN/System.err(342): java.lang.IllegalStateException:
Invalid Handshaking StateNOT_HANDSHAKING while processing the Handshake for
session 3
06-30 21:36:40.116: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:593)
06-30 21:36:40.126: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.writeNetBuffer(SslHandler.java:632)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:586)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslHandler.messageReceived(SslHandler.java:349)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:476)
06-30 21:36:40.137: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
06-30 21:36:40.155: WARN/System.err(342): at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:119)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:426)
06-30 21:36:40.166: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:693)
06-30 21:36:40.176: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:646)
06-30 21:36:40.193: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:635)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:67)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1079)
06-30 21:36:40.196: WARN/System.err(342): at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
06-30 21:36:40.206: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1068)
06-30 21:36:40.215: WARN/System.err(342): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:561)
06-30 21:36:40.215: WARN/System.err(342): at
java.lang.Thread.run(Thread.java:1096)
Any ideas what might cause this and how to fix it?
Same project works fine in JRE (with both bks and jks).
I found similar issue here (mina+android):
http://androiddiscuss.com/1-android-discuss/1022.html
I hope I am posting in correct place, since it is also about project VYSPER
and it seems possibly like android sdk bug, sorry if not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VYSPER-288) Announcing in-band registration although StartTLS might be required (first)
[ https://issues.apache.org/jira/browse/VYSPER-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056733#comment-13056733 ] Niklas Gustavsson commented on VYSPER-288: -- Depending on what we mean by default, it is enabled in org.apache.vysper.xmpp.server.ServerMain. I would support removing it as enabled in that class, as well as only support it over TLS (if that works with the common clients). Let me know if you want me to work on this. Announcing in-band registration although StartTLS might be required (first) --- Key: VYSPER-288 URL: https://issues.apache.org/jira/browse/VYSPER-288 Project: VYSPER Issue Type: Bug Reporter: Bernd Fondermann Priority: Blocker Right now, in-band registration is announced before a mandatory switch to TLS has been accomplished. I think we should not do that. However, I don't know if the feature still works over TLS. But I'd strongly suspect so, because, hey, it's a registration. After crossreading XEP-0077, I don't see why we should allow for doing regs over an unencrypted wire. WDYT? (Marking as a blocker, because of potential security implications. However, in-band is not enabled by default, is it?) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VYSPER-288) Announcing in-band registration although StartTLS might be required (first)
[ https://issues.apache.org/jira/browse/VYSPER-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056747#comment-13056747 ] Niklas Gustavsson commented on VYSPER-288: -- I've already created a patch and it works just fine with libpurple and Psi, so I say we go for it. Also, I think we should allow in-band regs on servers where TLS has been disabled, similar to plain auth. But I'll leave that to you're other work. Announcing in-band registration although StartTLS might be required (first) --- Key: VYSPER-288 URL: https://issues.apache.org/jira/browse/VYSPER-288 Project: VYSPER Issue Type: Bug Reporter: Bernd Fondermann Priority: Blocker Right now, in-band registration is announced before a mandatory switch to TLS has been accomplished. I think we should not do that. However, I don't know if the feature still works over TLS. But I'd strongly suspect so, because, hey, it's a registration. After crossreading XEP-0077, I don't see why we should allow for doing regs over an unencrypted wire. WDYT? (Marking as a blocker, because of potential security implications. However, in-band is not enabled by default, is it?) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-375) [FindBugs] NativeFtpFile implements equals(), but does not - hashCode()
[ https://issues.apache.org/jira/browse/FTPSERVER-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-375. --- Resolution: Fixed Assignee: Niklas Gustavsson Closing with Sebbs patch in place [FindBugs] NativeFtpFile implements equals(), but does not - hashCode() --- Key: FTPSERVER-375 URL: https://issues.apache.org/jira/browse/FTPSERVER-375 Project: FtpServer Issue Type: Wish Components: Core Reporter: Sergey Vladimirov Assignee: Niklas Gustavsson Priority: Minor Labels: equality, findbugs Fix For: 1.0.6, 1.1.0 Attachments: FTPSERVER-375.patch In fact, i can't find why it need to implement equals() in first place. If for any map - then hashCode() will also be required. For example, this.file.getCanonicalFile().hashCode() Anyway, could we please have a comment why do we need equals() method? :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FTPSERVER-422) Client tests might fail on IBM JVMs due to NPE in Thread.interrupt()
Client tests might fail on IBM JVMs due to NPE in Thread.interrupt() Key: FTPSERVER-422 URL: https://issues.apache.org/jira/browse/FTPSERVER-422 Project: FtpServer Issue Type: Improvement Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Priority: Minor Fix For: 1.0.6, 1.1.0 Some versions of the IBM JVM contains a bug in Thread.interrupt() which might cause an NPE. In FtpServer, we sometime gets this in our client tests. IBM APAR: http://www-01.ibm.com/support/docview.wss?uid=swg1IZ52037wv=1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-422) Client tests might fail on IBM JVMs due to NPE in Thread.interrupt()
[ https://issues.apache.org/jira/browse/FTPSERVER-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-422. --- Resolution: Fixed Fixed in rev 1138753 and 1138754 Client tests might fail on IBM JVMs due to NPE in Thread.interrupt() Key: FTPSERVER-422 URL: https://issues.apache.org/jira/browse/FTPSERVER-422 Project: FtpServer Issue Type: Improvement Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Priority: Minor Fix For: 1.0.6, 1.1.0 Some versions of the IBM JVM contains a bug in Thread.interrupt() which might cause an NPE. In FtpServer, we sometime gets this in our client tests. IBM APAR: http://www-01.ibm.com/support/docview.wss?uid=swg1IZ52037wv=1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-375) [FindBugs] NativeFtpFile implements equals(), but does not - hashCode()
[ https://issues.apache.org/jira/browse/FTPSERVER-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13053422#comment-13053422 ] Niklas Gustavsson commented on FTPSERVER-375: - Patch looks good, feel free to commit. As for equals (and hashCode()) ignoring user and fileName, this is on purpose. equals only attempts to see if the physical file is the same, not the user scoped file (which user/fileName represents). [FindBugs] NativeFtpFile implements equals(), but does not - hashCode() --- Key: FTPSERVER-375 URL: https://issues.apache.org/jira/browse/FTPSERVER-375 Project: FtpServer Issue Type: Wish Components: Core Reporter: Sergey Vladimirov Priority: Minor Labels: equality, findbugs Fix For: 1.0.6, 1.1.0 Attachments: FTPSERVER-375.patch In fact, i can't find why it need to implement equals() in first place. If for any map - then hashCode() will also be required. For example, this.file.getCanonicalFile().hashCode() Anyway, could we please have a comment why do we need equals() method? :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-418) Ignored/invalid assertion failure in FtpLetReturnDefaultTest.testLogin()
[ https://issues.apache.org/jira/browse/FTPSERVER-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-418. --- Resolution: Fixed Fix Version/s: 1.1.0 1.0.6 Assignee: Niklas Gustavsson Very nice catch! Fixed in rev 1138603 and 1138613 Ignored/invalid assertion failure in FtpLetReturnDefaultTest.testLogin() - Key: FTPSERVER-418 URL: https://issues.apache.org/jira/browse/FTPSERVER-418 Project: FtpServer Issue Type: Bug Reporter: Sebb Assignee: Niklas Gustavsson Fix For: 1.0.6, 1.1.0 The FtpLetReturnDefaultTest.testLogin() test defines a callback which overrides the onLogin method. The onLogin method includes the following assertion: assertNotNull(session.getUserArgument()); However, this will have no effect (other than generating a log message if the level allows it) because the method is called by a different thread from the test case. Note that the null check is currently being triggered, but the test is not failing. Either the null check is incorrect, or there is a bug that is not being detected. Either way, something needs to be fixed... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-375) [FindBugs] NativeFtpFile implements equals(), but does not - hashCode()
[ https://issues.apache.org/jira/browse/FTPSERVER-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051676#comment-13051676 ] Niklas Gustavsson commented on FTPSERVER-375: - Yes, we do use equals() so that's required to work as before. Not so worried about speed, as the equals (currently at least) check goes hand in hand with a lot of other I/O. Agreed that the hashCode() implementation can be simplified, will fix. On the case that the canonical file might change, that seems consistent with that equals() will also change in this case. All of this said, we do not currently use FtpFile in a hash map as far as I know, so it's a bit theoretical. [FindBugs] NativeFtpFile implements equals(), but does not - hashCode() --- Key: FTPSERVER-375 URL: https://issues.apache.org/jira/browse/FTPSERVER-375 Project: FtpServer Issue Type: Wish Components: Core Reporter: Sergey Vladimirov Priority: Minor Labels: equality, findbugs Fix For: 1.0.6, 1.1.0 In fact, i can't find why it need to implement equals() in first place. If for any map - then hashCode() will also be required. For example, this.file.getCanonicalFile().hashCode() Anyway, could we please have a comment why do we need equals() method? :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-404) Server certificate shipped in ftpserver.jks has expired
[ https://issues.apache.org/jira/browse/FTPSERVER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-404. --- Resolution: Fixed Assignee: Niklas Gustavsson Fixed in rev 1137421 and 1137422. Did not keep the expired certificate as the only purpose is to serve as an example, which must always be replaced. Server certificate shipped in ftpserver.jks has expired --- Key: FTPSERVER-404 URL: https://issues.apache.org/jira/browse/FTPSERVER-404 Project: FtpServer Issue Type: Bug Reporter: Sebb Assignee: Niklas Gustavsson Fix For: 1.0.6, 1.1.0 The server certificate in ftpserver.jks has expired. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-419) PassivePorts.reserveNextPort() is not synchronized
[ https://issues.apache.org/jira/browse/FTPSERVER-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-419. --- Resolution: Fixed Fix Version/s: 1.1.0 1.0.6 Assignee: Niklas Gustavsson Fixed in rev 1137251 and 1137252. PassivePorts.reserveNextPort() is not synchronized -- Key: FTPSERVER-419 URL: https://issues.apache.org/jira/browse/FTPSERVER-419 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.5 Reporter: Allen Firstenberg Assignee: Niklas Gustavsson Fix For: 1.0.6, 1.1.0 PassivePorts.reserveNextPort() is not synchronized, nor is there a synchronized block inside it. Both it and releasePort(int) should probably be synchronized on either this or a common sync object to ensure there is no race condition. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FTPSERVER-421) Upgrade to MINA 2.0.4
Upgrade to MINA 2.0.4 - Key: FTPSERVER-421 URL: https://issues.apache.org/jira/browse/FTPSERVER-421 Project: FtpServer Issue Type: Improvement Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 1.0.6, 1.1.0 With MINA 2.0.4 out, we should upgrade FtpServer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-420) When picking a passive port, use random port from the pool instead of lowest port
[ https://issues.apache.org/jira/browse/FTPSERVER-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-420. --- Resolution: Fixed Fix Version/s: 1.1.0 1.0.6 Assignee: Niklas Gustavsson Fixed in rev 1137251 and 1137252. Thanks for your work on this Allen! When picking a passive port, use random port from the pool instead of lowest port - Key: FTPSERVER-420 URL: https://issues.apache.org/jira/browse/FTPSERVER-420 Project: FtpServer Issue Type: Improvement Components: Core Reporter: Allen Firstenberg Assignee: Niklas Gustavsson Fix For: 1.0.6, 1.1.0 Attachments: DataConnectionConfigurationFactory.java.diff, PassivePorts.java, PassivePorts.java.diff, PassivePortsTest.java As discussed on the mailing list http://www.mail-archive.com/ftpserver-users@mina.apache.org/msg01635.html , passive ports are allocated from the pool based on the lowest available port from the list. This may cause problems with some firewalls or clients that may not release the port as quickly as the server expects. It is also a minor security risk to provide an easily guessable port for passive connections. Discussion on the list centered around other options to allocate ports, focusing on a random port assignment from the available pool. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-264) It takes about 1 minute and 100% CPU to set a wide passive port range (org.apache.ftpserver.DefaultDataConnectionConfiguration$Passive.SetPorts())
[ https://issues.apache.org/jira/browse/FTPSERVER-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-264. --- Resolution: Fixed Fix Version/s: 1.0.6 Fixed in rev 1137251 and 1137252. It takes about 1 minute and 100% CPU to set a wide passive port range (org.apache.ftpserver.DefaultDataConnectionConfiguration$Passive.SetPorts()) Key: FTPSERVER-264 URL: https://issues.apache.org/jira/browse/FTPSERVER-264 Project: FtpServer Issue Type: Bug Components: Server Affects Versions: 1.0.0-M2 Environment: Windows Reporter: Fred Moore Assignee: Niklas Gustavsson Fix For: 1.0.6, 1.1.0 We observed a long (about 1 minute) plateau of 100% CPU when trying to setPorts() in org.apache.ftpserver.DefaultDataConnectionConfiguration$Passive with wide port ranges such as 2122-65535. We observed that FTPServer internally performs an apparently very expensive scan on this range. Can this be made less CPU intensive and quicker (to shorten server downtime and reduce resource consumption in production)? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-421) Upgrade to MINA 2.0.4
[ https://issues.apache.org/jira/browse/FTPSERVER-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-421. --- Resolution: Fixed Fixed in rev 1137254 and 1137255 Upgrade to MINA 2.0.4 - Key: FTPSERVER-421 URL: https://issues.apache.org/jira/browse/FTPSERVER-421 Project: FtpServer Issue Type: Improvement Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 1.0.6, 1.1.0 With MINA 2.0.4 out, we should upgrade FtpServer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-420) When picking a passive port, use random port from the pool instead of lowest port
[ https://issues.apache.org/jira/browse/FTPSERVER-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051323#comment-13051323 ] Niklas Gustavsson commented on FTPSERVER-420: - I've reviewed the patch and think it's very good. Still making some very minor changes before I will commit it. When picking a passive port, use random port from the pool instead of lowest port - Key: FTPSERVER-420 URL: https://issues.apache.org/jira/browse/FTPSERVER-420 Project: FtpServer Issue Type: Improvement Components: Core Reporter: Allen Firstenberg Attachments: DataConnectionConfigurationFactory.java.diff, PassivePorts.java, PassivePorts.java.diff, PassivePortsTest.java As discussed on the mailing list http://www.mail-archive.com/ftpserver-users@mina.apache.org/msg01635.html , passive ports are allocated from the pool based on the lowest available port from the list. This may cause problems with some firewalls or clients that may not release the port as quickly as the server expects. It is also a minor security risk to provide an easily guessable port for passive connections. Discussion on the list centered around other options to allocate ports, focusing on a random port assignment from the available pool. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-420) When picking a passive port, use random port from the pool instead of lowest port
[ https://issues.apache.org/jira/browse/FTPSERVER-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050663#comment-13050663 ] Niklas Gustavsson commented on FTPSERVER-420: - From an initial review, it looks good. However, I'm missing the check if the port is currently in use. This is required as ports can be used by other processes. When picking a passive port, use random port from the pool instead of lowest port - Key: FTPSERVER-420 URL: https://issues.apache.org/jira/browse/FTPSERVER-420 Project: FtpServer Issue Type: Improvement Components: Core Reporter: Allen Firstenberg Attachments: DataConnectionConfigurationFactory.java.diff, PassivePorts.java, PassivePorts.java.diff As discussed on the mailing list http://www.mail-archive.com/ftpserver-users@mina.apache.org/msg01635.html, passive ports are allocated from the pool based on the lowest available port from the list. This may cause problems with some firewalls or clients that may not release the port as quickly as the server expects. It is also a minor security risk to provide an easily guessable port for passive connections. Discussion on the list centered around other options to allocate ports, focusing on a random port assignment from the available pool. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-420) When picking a passive port, use random port from the pool instead of lowest port
[ https://issues.apache.org/jira/browse/FTPSERVER-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050689#comment-13050689 ] Niklas Gustavsson commented on FTPSERVER-420: - Sorry, completely missed it. Could you also update the test case as that's now broken since the random assignments? When picking a passive port, use random port from the pool instead of lowest port - Key: FTPSERVER-420 URL: https://issues.apache.org/jira/browse/FTPSERVER-420 Project: FtpServer Issue Type: Improvement Components: Core Reporter: Allen Firstenberg Attachments: DataConnectionConfigurationFactory.java.diff, PassivePorts.java, PassivePorts.java.diff As discussed on the mailing list http://www.mail-archive.com/ftpserver-users@mina.apache.org/msg01635.html, passive ports are allocated from the pool based on the lowest available port from the list. This may cause problems with some firewalls or clients that may not release the port as quickly as the server expects. It is also a minor security risk to provide an easily guessable port for passive connections. Discussion on the list centered around other options to allocate ports, focusing on a random port assignment from the available pool. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-390) FTPServer disabling anonymous not compatible with Windows Explorer
[ https://issues.apache.org/jira/browse/FTPSERVER-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-390: Fix Version/s: (was: 1.0.6) 1.1.0 1.0.7 FTPServer disabling anonymous not compatible with Windows Explorer -- Key: FTPSERVER-390 URL: https://issues.apache.org/jira/browse/FTPSERVER-390 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.5 Reporter: Matthew Schulze Assignee: Niklas Gustavsson Fix For: 1.0.7, 1.1.0 When using Windows Explorer to attempt to connect to an FTP connection, it first attempts an anonymous login and then prompts the user for credentials after failure. Disabling anonymous login on the current version of Apache FTP Server returns a 530 response and immediately closes the connection, preventing the credentials dialog from appearing in Explorer and causing an error dialog to be displayed. If the USER command is successful and the anonymous user is rejected after the PASS command is sent with a 421 response sent by the server, Windows Explorer is able to handle the login process properly. To maintain maximum compatibility, anonymous user checks should all be handled in the PASS command. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-377) [FindBugs] Dereference of the result of readLine() without nullcheck in AddUser
[ https://issues.apache.org/jira/browse/FTPSERVER-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-377: Fix Version/s: (was: 1.0.6) 1.0.7 [FindBugs] Dereference of the result of readLine() without nullcheck in AddUser --- Key: FTPSERVER-377 URL: https://issues.apache.org/jira/browse/FTPSERVER-377 Project: FtpServer Issue Type: Bug Components: Server Reporter: Sergey Vladimirov Priority: Trivial Labels: console, findbugs, npe, ui Fix For: 1.0.7, 1.1.0 Since it's for management only, we don't care if admin will have java exceptions as a response... do we? Especially if stream is terminated already. But may be explicit handling is better. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-360) When no passive ports are available error out immediately rather than waiting for a port to become available
[ https://issues.apache.org/jira/browse/FTPSERVER-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-360: Fix Version/s: (was: 1.0.6) 1.0.7 When no passive ports are available error out immediately rather than waiting for a port to become available Key: FTPSERVER-360 URL: https://issues.apache.org/jira/browse/FTPSERVER-360 Project: FtpServer Issue Type: Bug Affects Versions: 1.0.4 Reporter: Sai Pullabhotla Assignee: Sai Pullabhotla Fix For: 1.0.7, 1.1.0 Attachments: FTPSERVER-360.patch Based on the filed issue, http://issues.apache.org/jira/browse/FTPSERVER-359, we probably want to quick fix the code to error out right away when no passive port is available. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-366) Fix interim problems with SiteTest.testSiteStat()
[ https://issues.apache.org/jira/browse/FTPSERVER-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-366: Fix Version/s: (was: 1.0.6) 1.0.7 Fix interim problems with SiteTest.testSiteStat() - Key: FTPSERVER-366 URL: https://issues.apache.org/jira/browse/FTPSERVER-366 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.4 Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 1.0.7, 1.1.0 SiteTest.testSiteStat() fails intermittently for us in Hudson and generates pretty useless error message. We should investigate why it fails, or at least add some reasonable assertion messages. Example of a failed test: http://hudson.zones.apache.org/hudson/view/FtpServer/job/ftpserver-trunk-jdk1.6-ibm-ubuntu/org.apache.ftpserver$ftpserver-core/57/testReport/junit/org.apache.ftpserver.clienttests/SiteTest/testSiteStat/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-339) Commands Dropped After Successful File Upload
[ https://issues.apache.org/jira/browse/FTPSERVER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-339: Fix Version/s: (was: 1.0.6) 1.0.7 Commands Dropped After Successful File Upload - Key: FTPSERVER-339 URL: https://issues.apache.org/jira/browse/FTPSERVER-339 Project: FtpServer Issue Type: Bug Affects Versions: 1.0.3 Reporter: Nick Padgett Assignee: Niklas Gustavsson Priority: Critical Fix For: 1.0.7, 1.1.0 After my ftp client successfully uploads a file, it sends a QUIT request. This QUIT request doesn't always appear to be logged by the FtpServer which results in the connection idling and the FtpServer subsequently closes the connection. We experience this issue often when uploading large files (2+GB) or multiple medium size files (~1 GB). When the QUIT is received before the FtpServer issues a 226 transfer complete message, the server sends a 226 transfer complete message , the a 221 goodbye message before closing the connection. When the QUIT is received after the FtpServer issues a 226 transfer complete message, sometimes the QUIT is processed on the existing thread and sometimes it is processed on a new thread. In either case, the server sends a 221 goodbye message and closed the connection. This leads me to believe that a QUIT message could be sent to the server in the time between when the first thread is being closed and the second thread is being opened. Below are logs from my FtpServer that illustrate all of these scenarios. This issue occurs very frequently and is resulting in the user believing their uploads failed. QUIT received before 226 transfer complete sent: 2009-11-04 14:32:31,936 [pool-4-thread-8] INFO org.apache.ftpserver.command.impl.STOR - File uploaded /1024/2009/11/02/7558_7W5oJqfN_event.wmv 2009-11-04 14:32:31,937 [pool-4-thread-8] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 150 File status okay; about to open data connection. 2009-11-04 14:32:32,104 [pool-4-thread-8] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: QUIT 2009-11-04 14:32:32,104 [pool-4-thread-8] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 226 Transfer complete. 2009-11-04 14:32:32,105 [pool-4-thread-8] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 221 Goodbye. 2009-11-04 14:32:32,105 [pool-4-thread-8] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - CLOSED QUIT received after 226 transfer complete sent on the same thread: 2009-11-03 19:25:23,958 [pool-4-thread-697] INFO org.apache.ftpserver.command.impl.STOR - File uploaded /1017/2009/10/09/7235_xVJpQ8tT_event.wmv 2009-11-03 19:25:23,958 [pool-4-thread-697] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 150 File status okay; about to open data connection. 2009-11-03 19:25:23,968 [pool-4-thread-697] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 226 Transfer complete. 2009-11-03 19:25:23,991 [pool-4-thread-697] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: QUIT 2009-11-03 19:25:23,992 [pool-4-thread-697] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 221 Goodbye. 2009-11-03 19:25:23,992 [pool-4-thread-697] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - CLOSED QUIT received after the 226 transfer complete sent on a new thread: 2009-11-03 04:43:16,551 [pool-4-thread-662] INFO org.apache.ftpserver.command.impl.STOR - File uploaded /1030/2009/11/02/7580_GxDwum7M_event.wmv 2009-11-03 04:43:16,552 [pool-4-thread-662] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 150 File status okay; about to open data connection. 2009-11-03 04:43:16,552 [pool-4-thread-662] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 226 Transfer complete. 2009-11-03 04:43:16,595 [pool-4-thread-667] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: QUIT 2009-11-03 04:43:16,598 [pool-4-thread-667] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 221 Goodbye. 2009-11-03 04:43:16,598 [pool-4-thread-667] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - CLOSED QUIT NOT received because the FtpServer is between threads: 2009-11-04 02:05:18,328 [pool-4-thread-16] INFO org.apache.ftpserver.command.impl.STOR - File uploaded /1051/2008/11/15/7400_NHftLRzu_event.mp4 2009-11-04 02:05:18,329 [pool-4-thread-16] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 150 File status okay; about to open data connection. 2009-11-04 02:05:18,397 [pool-4-thread-16] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT:
[jira] [Updated] (FTPSERVER-364) Incorrect behavior when max logins limit is reached
[ https://issues.apache.org/jira/browse/FTPSERVER-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-364: Fix Version/s: (was: 1.0.6) 1.0.7 Incorrect behavior when max logins limit is reached --- Key: FTPSERVER-364 URL: https://issues.apache.org/jira/browse/FTPSERVER-364 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.4 Reporter: Sai Pullabhotla Priority: Minor Fix For: 1.0.7, 1.1.0 When max logins limit is reached, the server currently behaves as below: Accepts connections from new clients and keeps them open Let's the new clients issue some commands (like I can go ahead and issue as many invalid commands as I want) When the client sends a valid USER command with username argument, the server then figures out that it has reached the max limit. I think t would probably makes sense to change the behavior as follows: When a new client comes in, check if we reached the cap, and if so, send 421 message right away, instead of sending a 2xxx reply. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-365) Overload FtpIoSession.getDataConnection to indicate whether or not a new DataConnectionFactory be created
[ https://issues.apache.org/jira/browse/FTPSERVER-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-365: Fix Version/s: (was: 1.0.6) 1.0.7 Overload FtpIoSession.getDataConnection to indicate whether or not a new DataConnectionFactory be created - Key: FTPSERVER-365 URL: https://issues.apache.org/jira/browse/FTPSERVER-365 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.4 Reporter: Sai Pullabhotla Priority: Trivial Fix For: 1.0.7, 1.1.0 It would be nice to overload the above mentioned method with a boolean parameter which indicates if a new DataConnectionFactory is to be created. Currently, we always create one if one does not exist already for the session. We try to create one even when the session is closing (for example when the control connection is refused by the blacklist filter), which does not make much sense. Having this overloaded method would be useful when the session is closing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-378) [FindBugs] Method DefaultFtpStatistics::setLogin() call passes null for nonnull parameter of new DefaultFtpStatistics$UserLogins(InetAddress)
[ https://issues.apache.org/jira/browse/FTPSERVER-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-378: Fix Version/s: (was: 1.0.6) 1.0.7 [FindBugs] Method DefaultFtpStatistics::setLogin() call passes null for nonnull parameter of new DefaultFtpStatistics$UserLogins(InetAddress) - Key: FTPSERVER-378 URL: https://issues.apache.org/jira/browse/FTPSERVER-378 Project: FtpServer Issue Type: Bug Components: Core Reporter: Sergey Vladimirov Priority: Minor Labels: findbugs, npe Fix For: 1.0.7, 1.1.0 If session.getRemoteAddress() is not instanceof InetSocketAddress, then address is null. But UserLogins do not accept nulls as argument (null can't be a key for ConcurrentHashMap) I think 'fake' NULL address constant shall be introduced in DefaultFtpStatistics for this case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-406) StringBuffer = StringBuilder for internal use
[ https://issues.apache.org/jira/browse/FTPSERVER-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-406. --- Assignee: Sebb StringBuffer = StringBuilder for internal use -- Key: FTPSERVER-406 URL: https://issues.apache.org/jira/browse/FTPSERVER-406 Project: FtpServer Issue Type: Improvement Reporter: Sebb Assignee: Sebb Priority: Minor Fix For: 1.0.6, 1.1.0 Attachments: StringBuilder.patch StringBuilder should be used in preference to StringBuffer for local variables -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-376) [FindBugs] Possible null pointer dereference of passivePorts in PassivePorts::init
[ https://issues.apache.org/jira/browse/FTPSERVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-376. --- Resolution: Fixed Assignee: Niklas Gustavsson Closed by FTPSERVER-415 [FindBugs] Possible null pointer dereference of passivePorts in PassivePorts::init Key: FTPSERVER-376 URL: https://issues.apache.org/jira/browse/FTPSERVER-376 Project: FtpServer Issue Type: Bug Components: Server Reporter: Sergey Vladimirov Assignee: Niklas Gustavsson Priority: Minor Labels: findbugs, npe Fix For: 1.0.6, 1.1.0 Possible null pointer dereference of passivePorts in PassivePorts::init(final int[] passivePorts, boolean checkIfBound) (line 165) NPE can occur if passivePorts argument is null. But this code is internal and i can't find a place that can pass null to the method. Anyway, suppose the case with null better be handled (with creation of empty array) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-405) Make Map field final (improve thread-safety)
[ https://issues.apache.org/jira/browse/FTPSERVER-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-405. --- Make Map field final (improve thread-safety) Key: FTPSERVER-405 URL: https://issues.apache.org/jira/browse/FTPSERVER-405 Project: FtpServer Issue Type: Improvement Components: Ftplets Reporter: Sebb Assignee: Sebb Fix For: 1.1.0 Attachments: DefaultFtpletContainer.patch Patch to make the field final -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-405) Make Map field final (improve thread-safety)
[ https://issues.apache.org/jira/browse/FTPSERVER-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-405: Fix Version/s: (was: 1.0.6) Assignee: Sebb Make Map field final (improve thread-safety) Key: FTPSERVER-405 URL: https://issues.apache.org/jira/browse/FTPSERVER-405 Project: FtpServer Issue Type: Improvement Components: Ftplets Reporter: Sebb Assignee: Sebb Fix For: 1.1.0 Attachments: DefaultFtpletContainer.patch Patch to make the field final -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-417) distribution POM dependencies can be pruned
[ https://issues.apache.org/jira/browse/FTPSERVER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042016#comment-13042016 ] Niklas Gustavsson commented on FTPSERVER-417: - The dependencies are used to populate the distributions, or am I missing something? distribution POM dependencies can be pruned --- Key: FTPSERVER-417 URL: https://issues.apache.org/jira/browse/FTPSERVER-417 Project: FtpServer Issue Type: Bug Reporter: Sebb Priority: Minor As far as I can tell, none of the dependency entries in the distribution POM are needed because there is no code in the module. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-416) FtpServer core no longer needs ORO
[ https://issues.apache.org/jira/browse/FTPSERVER-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-416. --- Resolution: Fixed Fix Version/s: 1.1.0 1.0.6 Assignee: Niklas Gustavsson Fixed in rev 1130075 and 1130078 FtpServer core no longer needs ORO -- Key: FTPSERVER-416 URL: https://issues.apache.org/jira/browse/FTPSERVER-416 Project: FtpServer Issue Type: Bug Reporter: Sebb Assignee: Niklas Gustavsson Priority: Minor Fix For: 1.0.6, 1.1.0 The dependency entries for ORO can be removed from the parent POM and from the core POM -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-415) NPE in PassivePorts(int[] passivePorts, boolean checkIfBound) constructor
[
https://issues.apache.org/jira/browse/FTPSERVER-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niklas Gustavsson closed FTPSERVER-415.
---
Resolution: Fixed
Fix Version/s: 1.1.0
1.0.6
Assignee: Niklas Gustavsson
This has been reported before, so about time we do something about it. Passing
null should not be allowed. I've added an explicit null check to make this
clear. Committed in rev 1130138 and 1130141.
NPE in PassivePorts(int[] passivePorts, boolean checkIfBound) constructor
-
Key: FTPSERVER-415
URL: https://issues.apache.org/jira/browse/FTPSERVER-415
Project: FtpServer
Issue Type: Bug
Components: Core
Reporter: Sebb
Assignee: Niklas Gustavsson
Fix For: 1.0.6, 1.1.0
The PassivePorts(int[] passivePorts, boolean checkIfBound) constructor allows
passivePorts to be null, but then uses it to create the parallel
reservedPorts list:
if (passivePorts != null) {
this.passivePorts = passivePorts.clone();
} else {
this.passivePorts = null; // sets field to null
}
reservedPorts = new boolean[passivePorts.length]; // = possible NPE
here
If null is really allowed as a parameter, it should be handled properly.
Either set reservedPorts to null as well, or (perhaps safer) create an empty
passivePorts array (and empty reservedPorts array).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-414) STAT / creates invalid directory listing (with Patch)
[
https://issues.apache.org/jira/browse/FTPSERVER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niklas Gustavsson closed FTPSERVER-414.
---
Resolution: Fixed
Fix Version/s: 1.1.0
1.0.6
Assignee: Niklas Gustavsson
STAT / creates invalid directory listing (with Patch)
-
Key: FTPSERVER-414
URL: https://issues.apache.org/jira/browse/FTPSERVER-414
Project: FtpServer
Issue Type: Bug
Components: Server
Affects Versions: 1.0.5
Reporter: Emmeran Seehuber
Assignee: Niklas Gustavsson
Fix For: 1.0.6, 1.1.0
Some ftp clients (e.g. Cyberduck on Mac OS X) use the STAT command to list
directores. The reply contains an invalid status code in the last line, which
causes the ftp client to ignore the last line. So the last file in the
directory does not show up in the ftp client listing:
614869 [pool-3-thread-6] INFO
org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: STAT /
615085 [pool-3-thread-6] INFO
org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 200---w--- 1
roto...@rototor.de roto...@rototor.de21581 Jan 1 1970 uxz.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 5788 Jan 1
1970 abc.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 415447 Jan 1
1970 def.pdf
200 --w--- 1 roto...@rototor.de roto...@rototor.de 822782 Jan
1 1970 xyz.pdf
I dont know if this is a bug in the ftp client. But at least the following
patch to the STAT command fixes the problem for me:
diff --git a/org/apache/ftpserver/command/impl/STAT.java
b/org/apache/ftpserver/command/impl/STAT.java
index 19674b2..5ca76c1 100644
--- a/org/apache/ftpserver/command/impl/STAT.java
+++ b/org/apache/ftpserver/command/impl/STAT.java
@@ -77,10 +77,6 @@ public class STAT extends AbstractCommand {
String dirList = directoryLister.listFiles(parsedArg,
session.getFileSystemView(), LIST_FILE_FORMATER);
+ // DefaultFtpReply prepends the status code to the last line.
+// This causes the STAT directory listing to loose the last
directory entry in some clients
+// e.g. Cyberduck
+ dirList +=\n;
session
.write(new DefaultFtpReply(
With this patch applied the output looks like this:
615085 [pool-3-thread-6] INFO
org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 200---w--- 1
roto...@rototor.de roto...@rototor.de21581 Jan 1 1970 uxz.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 5788 Jan 1
1970 abc.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 415447 Jan 1
1970 def.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 822782 Jan 1
1970 xyz.pdf
200
And know the clients work correctly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-414) STAT / creates invalid directory listing (with Patch)
[
https://issues.apache.org/jira/browse/FTPSERVER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041573#comment-13041573
]
Niklas Gustavsson commented on FTPSERVER-414:
-
Excellent, thanks for this analysis.
Now fixed in rev 1129664 and 1129665.
STAT / creates invalid directory listing (with Patch)
-
Key: FTPSERVER-414
URL: https://issues.apache.org/jira/browse/FTPSERVER-414
Project: FtpServer
Issue Type: Bug
Components: Server
Affects Versions: 1.0.5
Reporter: Emmeran Seehuber
Fix For: 1.0.6, 1.1.0
Some ftp clients (e.g. Cyberduck on Mac OS X) use the STAT command to list
directores. The reply contains an invalid status code in the last line, which
causes the ftp client to ignore the last line. So the last file in the
directory does not show up in the ftp client listing:
614869 [pool-3-thread-6] INFO
org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: STAT /
615085 [pool-3-thread-6] INFO
org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 200---w--- 1
roto...@rototor.de roto...@rototor.de21581 Jan 1 1970 uxz.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 5788 Jan 1
1970 abc.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 415447 Jan 1
1970 def.pdf
200 --w--- 1 roto...@rototor.de roto...@rototor.de 822782 Jan
1 1970 xyz.pdf
I dont know if this is a bug in the ftp client. But at least the following
patch to the STAT command fixes the problem for me:
diff --git a/org/apache/ftpserver/command/impl/STAT.java
b/org/apache/ftpserver/command/impl/STAT.java
index 19674b2..5ca76c1 100644
--- a/org/apache/ftpserver/command/impl/STAT.java
+++ b/org/apache/ftpserver/command/impl/STAT.java
@@ -77,10 +77,6 @@ public class STAT extends AbstractCommand {
String dirList = directoryLister.listFiles(parsedArg,
session.getFileSystemView(), LIST_FILE_FORMATER);
+ // DefaultFtpReply prepends the status code to the last line.
+// This causes the STAT directory listing to loose the last
directory entry in some clients
+// e.g. Cyberduck
+ dirList +=\n;
session
.write(new DefaultFtpReply(
With this patch applied the output looks like this:
615085 [pool-3-thread-6] INFO
org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 200---w--- 1
roto...@rototor.de roto...@rototor.de21581 Jan 1 1970 uxz.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 5788 Jan 1
1970 abc.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 415447 Jan 1
1970 def.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 822782 Jan 1
1970 xyz.pdf
200
And know the clients work correctly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-414) STAT / creates invalid directory listing (with Patch)
[
https://issues.apache.org/jira/browse/FTPSERVER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041037#comment-13041037
]
Niklas Gustavsson commented on FTPSERVER-414:
-
The reason for asking is if we should change this for all multi-line replies,
or only for STAT. We're compliant with the RFC as far as I can tell, so this is
likely a bug in Cyberduck. Have you reported this to the Cyberduck devs?
That said, the RFC says that test on the last line is optional, so I would
think that the patch would work.
From the RFC:
Thus the format for multi-line replies is that the first line
will begin with the exact required reply code, followed
immediately by a Hyphen, - (also known as Minus), followed by
text. The last line will begin with the same code, followed
immediately by Space SP, optionally some text, and the Telnet
end-of-line code.
For example:
123-First line
Second line
234 A line beginning with numbers
123 The last line
STAT / creates invalid directory listing (with Patch)
-
Key: FTPSERVER-414
URL: https://issues.apache.org/jira/browse/FTPSERVER-414
Project: FtpServer
Issue Type: Bug
Components: Server
Affects Versions: 1.0.5
Reporter: Emmeran Seehuber
Some ftp clients (e.g. Cyberduck on Mac OS X) use the STAT command to list
directores. The reply contains an invalid status code in the last line, which
causes the ftp client to ignore the last line. So the last file in the
directory does not show up in the ftp client listing:
614869 [pool-3-thread-6] INFO
org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: STAT /
615085 [pool-3-thread-6] INFO
org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 200---w--- 1
roto...@rototor.de roto...@rototor.de21581 Jan 1 1970 uxz.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 5788 Jan 1
1970 abc.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 415447 Jan 1
1970 def.pdf
200 --w--- 1 roto...@rototor.de roto...@rototor.de 822782 Jan
1 1970 xyz.pdf
I dont know if this is a bug in the ftp client. But at least the following
patch to the STAT command fixes the problem for me:
diff --git a/org/apache/ftpserver/command/impl/STAT.java
b/org/apache/ftpserver/command/impl/STAT.java
index 19674b2..5ca76c1 100644
--- a/org/apache/ftpserver/command/impl/STAT.java
+++ b/org/apache/ftpserver/command/impl/STAT.java
@@ -77,10 +77,6 @@ public class STAT extends AbstractCommand {
String dirList = directoryLister.listFiles(parsedArg,
session.getFileSystemView(), LIST_FILE_FORMATER);
+ // DefaultFtpReply prepends the status code to the last line.
+// This causes the STAT directory listing to loose the last
directory entry in some clients
+// e.g. Cyberduck
+ dirList +=\n;
session
.write(new DefaultFtpReply(
With this patch applied the output looks like this:
615085 [pool-3-thread-6] INFO
org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 200---w--- 1
roto...@rototor.de roto...@rototor.de21581 Jan 1 1970 uxz.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 5788 Jan 1
1970 abc.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 415447 Jan 1
1970 def.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 822782 Jan 1
1970 xyz.pdf
200
And know the clients work correctly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VYSPER-283) Rename UserAuthorization to UserAuthentication
Rename UserAuthorization to UserAuthentication -- Key: VYSPER-283 URL: https://issues.apache.org/jira/browse/VYSPER-283 Project: VYSPER Issue Type: Improvement Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Priority: Minor Fix For: 0.8 We use authorize in places where we really mean authenticate. The primarily thing to change is UserAuthorization and related classes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (VYSPER-283) Rename UserAuthorization to UserAuthentication
[ https://issues.apache.org/jira/browse/VYSPER-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed VYSPER-283. Resolution: Fixed Fixed in rev 1129185 and r1129186 Rename UserAuthorization to UserAuthentication -- Key: VYSPER-283 URL: https://issues.apache.org/jira/browse/VYSPER-283 Project: VYSPER Issue Type: Improvement Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Priority: Minor Fix For: 0.8 We use authorize in places where we really mean authenticate. The primarily thing to change is UserAuthorization and related classes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VYSPER-284) Remove deprecated UserAuthentication.verifyCredentials(String, String, Object)
Remove deprecated UserAuthentication.verifyCredentials(String, String, Object) -- Key: VYSPER-284 URL: https://issues.apache.org/jira/browse/VYSPER-284 Project: VYSPER Issue Type: Improvement Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 UserAuthentication.verifyCredentials(String, String, Object) is deprecated and could now be removed. Since we're still on a 0.x release, no great need to maintain API stability. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-413) STAT command returns wrong 200 state
[ https://issues.apache.org/jira/browse/FTPSERVER-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041251#comment-13041251 ] Niklas Gustavsson commented on FTPSERVER-413: - Fixed to use another, incorrect reply code first. Now fixed again in rev 1129318 and 1129319. STAT command returns wrong 200 state Key: FTPSERVER-413 URL: https://issues.apache.org/jira/browse/FTPSERVER-413 Project: FtpServer Issue Type: Bug Affects Versions: 1.0.5 Reporter: Mark Struberg Assignee: Niklas Gustavsson Fix For: 1.0.6, 1.1.0 I'm now using MINA FtpServer for the Integration Tests of Apache mavens wagon-ftp. While upgrding from a 8 year old avalon based ftpserver jar, I figured that a unit test is broken. This has to do with FtpServer returning a 200 state which is imo invalid. According to the officla RFC http://www.faqs.org/rfcs/rfc959.html STAT may only return the following codes: STAT 211, 212, 213 450 500, 501, 502, 421, 530 I think returning 200 (command ok) after a STAT command is a bug. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-414) STAT / creates invalid directory listing (with Patch)
[
https://issues.apache.org/jira/browse/FTPSERVER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041250#comment-13041250
]
Niklas Gustavsson commented on FTPSERVER-414:
-
Right, that's been reported in FTPSERVER-413, albeit my fix used incorrect
reply codes. Now fixed.
STAT / creates invalid directory listing (with Patch)
-
Key: FTPSERVER-414
URL: https://issues.apache.org/jira/browse/FTPSERVER-414
Project: FtpServer
Issue Type: Bug
Components: Server
Affects Versions: 1.0.5
Reporter: Emmeran Seehuber
Some ftp clients (e.g. Cyberduck on Mac OS X) use the STAT command to list
directores. The reply contains an invalid status code in the last line, which
causes the ftp client to ignore the last line. So the last file in the
directory does not show up in the ftp client listing:
614869 [pool-3-thread-6] INFO
org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: STAT /
615085 [pool-3-thread-6] INFO
org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 200---w--- 1
roto...@rototor.de roto...@rototor.de21581 Jan 1 1970 uxz.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 5788 Jan 1
1970 abc.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 415447 Jan 1
1970 def.pdf
200 --w--- 1 roto...@rototor.de roto...@rototor.de 822782 Jan
1 1970 xyz.pdf
I dont know if this is a bug in the ftp client. But at least the following
patch to the STAT command fixes the problem for me:
diff --git a/org/apache/ftpserver/command/impl/STAT.java
b/org/apache/ftpserver/command/impl/STAT.java
index 19674b2..5ca76c1 100644
--- a/org/apache/ftpserver/command/impl/STAT.java
+++ b/org/apache/ftpserver/command/impl/STAT.java
@@ -77,10 +77,6 @@ public class STAT extends AbstractCommand {
String dirList = directoryLister.listFiles(parsedArg,
session.getFileSystemView(), LIST_FILE_FORMATER);
+ // DefaultFtpReply prepends the status code to the last line.
+// This causes the STAT directory listing to loose the last
directory entry in some clients
+// e.g. Cyberduck
+ dirList +=\n;
session
.write(new DefaultFtpReply(
With this patch applied the output looks like this:
615085 [pool-3-thread-6] INFO
org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 200---w--- 1
roto...@rototor.de roto...@rototor.de21581 Jan 1 1970 uxz.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 5788 Jan 1
1970 abc.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 415447 Jan 1
1970 def.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 822782 Jan 1
1970 xyz.pdf
200
And know the clients work correctly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-413) STAT command returns wrong 200 state
[
https://issues.apache.org/jira/browse/FTPSERVER-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041264#comment-13041264
]
Niklas Gustavsson commented on FTPSERVER-413:
-
Ha!
int replyCode;
if(file.isDirectory()) {
replyCode = FtpReply.REPLY_212_DIRECTORY_STATUS;
} else {
replyCode = FtpReply.REPLY_213_FILE_STATUS;
}
STAT command returns wrong 200 state
Key: FTPSERVER-413
URL: https://issues.apache.org/jira/browse/FTPSERVER-413
Project: FtpServer
Issue Type: Bug
Affects Versions: 1.0.5
Reporter: Mark Struberg
Assignee: Niklas Gustavsson
Fix For: 1.0.6, 1.1.0
I'm now using MINA FtpServer for the Integration Tests of Apache mavens
wagon-ftp. While upgrding from a 8 year old avalon based ftpserver jar, I
figured that a unit test is broken.
This has to do with FtpServer returning a 200 state which is imo invalid.
According to the officla RFC http://www.faqs.org/rfcs/rfc959.html STAT may
only return the following codes:
STAT
211, 212, 213
450
500, 501, 502, 421, 530
I think returning 200 (command ok) after a STAT command is a bug.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-413) STAT command returns wrong 200 state
[ https://issues.apache.org/jira/browse/FTPSERVER-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-413. --- Resolution: Fixed Fix Version/s: 1.1.0 1.0.6 Assignee: Niklas Gustavsson Fixed in rev 1128769 and 1128770, thanks for reporting! STAT command returns wrong 200 state Key: FTPSERVER-413 URL: https://issues.apache.org/jira/browse/FTPSERVER-413 Project: FtpServer Issue Type: Bug Affects Versions: 1.0.5 Reporter: Mark Struberg Assignee: Niklas Gustavsson Fix For: 1.0.6, 1.1.0 I'm now using MINA FtpServer for the Integration Tests of Apache mavens wagon-ftp. While upgrding from a 8 year old avalon based ftpserver jar, I figured that a unit test is broken. This has to do with FtpServer returning a 200 state which is imo invalid. According to the officla RFC http://www.faqs.org/rfcs/rfc959.html STAT may only return the following codes: STAT 211, 212, 213 450 500, 501, 502, 421, 530 I think returning 200 (command ok) after a STAT command is a bug. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-414) STAT / creates invalid directory listing (with Patch)
[
https://issues.apache.org/jira/browse/FTPSERVER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13040672#comment-13040672
]
Niklas Gustavsson commented on FTPSERVER-414:
-
Do you get the same problem for other multiline replies, like MLST?
STAT / creates invalid directory listing (with Patch)
-
Key: FTPSERVER-414
URL: https://issues.apache.org/jira/browse/FTPSERVER-414
Project: FtpServer
Issue Type: Bug
Components: Server
Affects Versions: 1.0.5
Reporter: Emmeran Seehuber
Some ftp clients (e.g. Cyberduck on Mac OS X) use the STAT command to list
directores. The reply contains an invalid status code in the last line, which
causes the ftp client to ignore the last line. So the last file in the
directory does not show up in the ftp client listing:
614869 [pool-3-thread-6] INFO
org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: STAT /
615085 [pool-3-thread-6] INFO
org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 200---w--- 1
roto...@rototor.de roto...@rototor.de21581 Jan 1 1970 uxz.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 5788 Jan 1
1970 abc.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 415447 Jan 1
1970 def.pdf
200 --w--- 1 roto...@rototor.de roto...@rototor.de 822782 Jan
1 1970 xyz.pdf
I dont know if this is a bug in the ftp client. But at least the following
patch to the STAT command fixes the problem for me:
diff --git a/org/apache/ftpserver/command/impl/STAT.java
b/org/apache/ftpserver/command/impl/STAT.java
index 19674b2..5ca76c1 100644
--- a/org/apache/ftpserver/command/impl/STAT.java
+++ b/org/apache/ftpserver/command/impl/STAT.java
@@ -77,10 +77,6 @@ public class STAT extends AbstractCommand {
String dirList = directoryLister.listFiles(parsedArg,
session.getFileSystemView(), LIST_FILE_FORMATER);
+ // DefaultFtpReply prepends the status code to the last line.
+// This causes the STAT directory listing to loose the last
directory entry in some clients
+// e.g. Cyberduck
+ dirList +=\n;
session
.write(new DefaultFtpReply(
With this patch applied the output looks like this:
615085 [pool-3-thread-6] INFO
org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 200---w--- 1
roto...@rototor.de roto...@rototor.de21581 Jan 1 1970 uxz.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 5788 Jan 1
1970 abc.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 415447 Jan 1
1970 def.pdf
--w--- 1 roto...@rototor.de roto...@rototor.de 822782 Jan 1
1970 xyz.pdf
200
And know the clients work correctly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FTPSERVER-412) OPTS MLST does not handle unknown factnames correctly
[ https://issues.apache.org/jira/browse/FTPSERVER-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-412. --- Resolution: Fixed Fix Version/s: 1.1.0 1.0.6 Assignee: Niklas Gustavsson Fixed in rev 1101807 and 1101808. I did not use the provided patch, please verify if the fix solves your issue. OPTS MLST does not handle unknown factnames correctly - Key: FTPSERVER-412 URL: https://issues.apache.org/jira/browse/FTPSERVER-412 Project: FtpServer Issue Type: Bug Affects Versions: 1.0.5 Reporter: Allen Firstenberg Assignee: Niklas Gustavsson Fix For: 1.0.6, 1.1.0 Attachments: OPTS_MLST.java RFC 3659, section 7.9 states Facts requested that are not supported, or that are inappropriate to the file or directory being listed should simply be omitted from the MLSx output. This is not an error. Note that where no factname arguments are present, the client is requesting that only the file names be returned. org.apache.ftpserver.command.impl.OPTS_MLST.validateSelectedTypes() specifically returns null if one of the types requested is not found, and a null return generates the 501 from execute(). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-831) NioSocketConnector create unused Connections, even when #connect(..) is not called.
[ https://issues.apache.org/jira/browse/DIRMINA-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13025700#comment-13025700 ] Niklas Gustavsson commented on DIRMINA-831: --- I can confirm this behavior, with both 2.0.2 and 2.0.3. The sockets can be seen from netstat /a TCPniklas-winxp2:1050 localhost:1051 TIME_WAIT TCPniklas-winxp2:1052 localhost:1053 TIME_WAIT TCPniklas-winxp2:1054 localhost:1055 TIME_WAIT TCPniklas-winxp2:1056 localhost:1057 ESTABLISHED TCPniklas-winxp2:1057 localhost:1056 ESTABLISHED TCPniklas-winxp2:1058 localhost:1059 ESTABLISHED TCPniklas-winxp2:1059 localhost:1058 ESTABLISHED TCPniklas-winxp2:1060 localhost:1061 ESTABLISHED TCPniklas-winxp2:1061 localhost:1060 ESTABLISHED And, as shown in the video, they occur when the connector is created and the established sockets gets closed as soon as the connector is disposed. On OS X, I don't see this behavior. NioSocketConnector create unused Connections, even when #connect(..) is not called. --- Key: DIRMINA-831 URL: https://issues.apache.org/jira/browse/DIRMINA-831 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.2 Environment: win32, x86, winXP Reporter: Christian Schwarz Attachments: DIRMINA-831.avi, DIRMINA-831.jpg Hello, we are using Mina to access different types of network devices (Webcams, Digital-IO-Boxes, Access Control Systems,...). For every type of device we use a dedicated IoConnector because of the different protocols. Under some circumstances we get an java.net.SocketException: No buffer space available (maximum connections reached?): connect. We figured out that for every created NioSocketConnector 8 connections will be created from localhost to localhost with different ports, even if we do no connect at all. So if we use many NioSocketConnector's we quickly run out of available ports, i guess. Is it possible to tune the NioSocketConnector so it only opens a port when we call #connect(..) ? Thanks in advance Chris -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VYSPER-282) Use a dedicated class for client-to-server endpoints
Use a dedicated class for client-to-server endpoints Key: VYSPER-282 URL: https://issues.apache.org/jira/browse/VYSPER-282 Project: VYSPER Issue Type: Improvement Affects Versions: 0.7 Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 Vysper currently has a dedicated endpoint for server-to-server communication, S2SEndpoint. For symmetry, we should have the same for client-to-server. This will also allow typed endpoints, where the endpoint knows what type it is and only supports that kind of communication. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (VYSPER-281) Relaying to external servers should be disabled by default
[ https://issues.apache.org/jira/browse/VYSPER-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed VYSPER-281. Resolution: Fixed Fixed in rev 1085929 Relaying to external servers should be disabled by default -- Key: VYSPER-281 URL: https://issues.apache.org/jira/browse/VYSPER-281 Project: VYSPER Issue Type: Bug Components: core protocol Affects Versions: 0.7 Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 In 0.7, a change which made external relaying on by default was included by mistake. Relaying to external servers should be a decided on by the administrator before being activated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VYSPER-281) Relaying to external servers should be disabled by default
Relaying to external servers should be disabled by default -- Key: VYSPER-281 URL: https://issues.apache.org/jira/browse/VYSPER-281 Project: VYSPER Issue Type: Bug Components: core protocol Affects Versions: 0.7 Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 In 0.7, a change which made external relaying on by default was included by mistake. Relaying to external servers should be a decided on by the administrator before being activated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-409) Requesting number of active transfers in FtpStatistics
[ https://issues.apache.org/jira/browse/FTPSERVER-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-409: Affects Version/s: (was: WISHLIST) Fix Version/s: 1.1.0 Requesting number of active transfers in FtpStatistics -- Key: FTPSERVER-409 URL: https://issues.apache.org/jira/browse/FTPSERVER-409 Project: FtpServer Issue Type: Improvement Reporter: Stepan Koltsov Fix For: 1.1.0 FtpStatistics has handy getCurrentConnectionNumber parameter. This value includes connections, that has no transfers. Requesting also getCurrentUploadsNumber, getCurrentDownloadsNumbers. Needed for monitoring. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VYSPER-279) Support adding modules to XMPPServer before start() is called
Support adding modules to XMPPServer before start() is called - Key: VYSPER-279 URL: https://issues.apache.org/jira/browse/VYSPER-279 Project: VYSPER Issue Type: Improvement Affects Versions: 0.7, 0.6 Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 XMPPServer will currently throw an NPE if a module is added before the server is started since the ServerRuntimeContext has not been created. We should support adding modules both before and after starting the server. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (VYSPER-276) Implement XEP-0065 - SOCKS5 bytestreams
[ https://issues.apache.org/jira/browse/VYSPER-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed VYSPER-276. Resolution: Fixed SOCKS5 bytestreams for TCP (direct and mediated) fully implemented. Implement XEP-0065 - SOCKS5 bytestreams --- Key: VYSPER-276 URL: https://issues.apache.org/jira/browse/VYSPER-276 Project: VYSPER Issue Type: New Feature Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 Implement XEP-0065 - SOCKS5 bytestreams support in Vysper, including an embedded proxy server. Smack now has improved support for SOCKS5 mediated connections, should be useful for integration testing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VYSPER-280) Support username/password authentication for SOCKS5 connections
Support username/password authentication for SOCKS5 connections --- Key: VYSPER-280 URL: https://issues.apache.org/jira/browse/VYSPER-280 Project: VYSPER Issue Type: Improvement Reporter: Niklas Gustavsson The current implementation of the SOCKS5 bytestream proxy does not support username/password authentication of SOCKS5 connections. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-405) Make Map field final (improve thread-safety)
[ https://issues.apache.org/jira/browse/FTPSERVER-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-405: Fix Version/s: 1.1.0 1.0.6 Make Map field final (improve thread-safety) Key: FTPSERVER-405 URL: https://issues.apache.org/jira/browse/FTPSERVER-405 Project: FtpServer Issue Type: Improvement Components: Ftplets Reporter: Sebb Fix For: 1.0.6, 1.1.0 Attachments: DefaultFtpletContainer.patch Patch to make the field final -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-404) Server certificate shipped in ftpserver.jks has expired
[ https://issues.apache.org/jira/browse/FTPSERVER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-404: Fix Version/s: 1.1.0 1.0.6 Server certificate shipped in ftpserver.jks has expired --- Key: FTPSERVER-404 URL: https://issues.apache.org/jira/browse/FTPSERVER-404 Project: FtpServer Issue Type: Bug Reporter: Sebb Fix For: 1.0.6, 1.1.0 The server certificate in ftpserver.jks has expired. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-406) StringBuffer = StringBuilder for internal use
[ https://issues.apache.org/jira/browse/FTPSERVER-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-406: Fix Version/s: 1.1.0 1.0.6 StringBuffer = StringBuilder for internal use -- Key: FTPSERVER-406 URL: https://issues.apache.org/jira/browse/FTPSERVER-406 Project: FtpServer Issue Type: Improvement Reporter: Sebb Priority: Minor Fix For: 1.0.6, 1.1.0 Attachments: StringBuilder.patch StringBuilder should be used in preference to StringBuffer for local variables -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VYSPER-276) Implement XEP-0065 - SOCKS5 bytestreams
Implement XEP-0065 - SOCKS5 bytestreams --- Key: VYSPER-276 URL: https://issues.apache.org/jira/browse/VYSPER-276 Project: VYSPER Issue Type: New Feature Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 Implement XEP-0065 - SOCKS5 bytestreams support in Vysper, including an embedded proxy server. Smack now has improved support for SOCKS5 mediated connections, should be useful for integration testing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VYSPER-276) Implement XEP-0065 - SOCKS5 bytestreams
[ https://issues.apache.org/jira/browse/VYSPER-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009855#comment-13009855 ] Niklas Gustavsson commented on VYSPER-276: -- Namespace added in rev 1084364. Implement XEP-0065 - SOCKS5 bytestreams --- Key: VYSPER-276 URL: https://issues.apache.org/jira/browse/VYSPER-276 Project: VYSPER Issue Type: New Feature Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 Implement XEP-0065 - SOCKS5 bytestreams support in Vysper, including an embedded proxy server. Smack now has improved support for SOCKS5 mediated connections, should be useful for integration testing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VYSPER-277) Implement close lifecycle method for Modules
Implement close lifecycle method for Modules Key: VYSPER-277 URL: https://issues.apache.org/jira/browse/VYSPER-277 Project: VYSPER Issue Type: Improvement Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 Modules support initialize for setting up resources, but does not have a close() method for releasing resources. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (VYSPER-277) Implement close lifecycle method for Modules
[ https://issues.apache.org/jira/browse/VYSPER-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed VYSPER-277. Resolution: Fixed Fixed in rev 1084371. Implement close lifecycle method for Modules Key: VYSPER-277 URL: https://issues.apache.org/jira/browse/VYSPER-277 Project: VYSPER Issue Type: Improvement Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 Modules support initialize for setting up resources, but does not have a close() method for releasing resources. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VYSPER-278) Implement relaying of disco stanzas to full JIDs
Implement relaying of disco stanzas to full JIDs Key: VYSPER-278 URL: https://issues.apache.org/jira/browse/VYSPER-278 Project: VYSPER Issue Type: Improvement Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 For SOCKS5 bytestreams with Smack, discovery of a connected clients features are used by sending IQ disco stanzas to the full JID of the client. However, Vysper will not relay these to the client and will instead return an empty list of features. For this, we need to implement IQ stanza relaying and handling relaying disco IQ get and results in DiscoInfoIQHandler -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VYSPER-278) Implement relaying of disco stanzas to full JIDs
[ https://issues.apache.org/jira/browse/VYSPER-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009883#comment-13009883 ] Niklas Gustavsson commented on VYSPER-278: -- Implemented in rev 1084393. Implement relaying of disco stanzas to full JIDs Key: VYSPER-278 URL: https://issues.apache.org/jira/browse/VYSPER-278 Project: VYSPER Issue Type: Improvement Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 For SOCKS5 bytestreams with Smack, discovery of a connected clients features are used by sending IQ disco stanzas to the full JID of the client. However, Vysper will not relay these to the client and will instead return an empty list of features. For this, we need to implement IQ stanza relaying and handling relaying disco IQ get and results in DiscoInfoIQHandler -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (VYSPER-275) Race condition in stanza handling
Race condition in stanza handling -- Key: VYSPER-275 URL: https://issues.apache.org/jira/browse/VYSPER-275 Project: VYSPER Issue Type: Bug Components: core protocol Affects Versions: 0.7 Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 Stanzas received by Vysper is currently queued for processing in QueueStanzaProcessor. However, this implementation will not maintain order of stanzas within a session. So, if a client (or other server) sends multiple stanzas they might not be handled in order. This is against the spec and can lead to undesired behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (VYSPER-275) Race condition in stanza handling
[ https://issues.apache.org/jira/browse/VYSPER-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed VYSPER-275. Resolution: Fixed Fixed in rev 1081498 by using OrderedThreadPoolExecutor instead of QueuedStanzaProcessor Race condition in stanza handling -- Key: VYSPER-275 URL: https://issues.apache.org/jira/browse/VYSPER-275 Project: VYSPER Issue Type: Bug Components: core protocol Affects Versions: 0.7 Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 Stanzas received by Vysper is currently queued for processing in QueueStanzaProcessor. However, this implementation will not maintain order of stanzas within a session. So, if a client (or other server) sends multiple stanzas they might not be handled in order. This is against the spec and can lead to undesired behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (VYSPER-274) Typo in link reference in HTML project page.
[ https://issues.apache.org/jira/browse/VYSPER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed VYSPER-274. Resolution: Fixed Assignee: Niklas Gustavsson Thanks for reporting, now fixed (mirrors should be updated within a few hours) Typo in link reference in HTML project page. Key: VYSPER-274 URL: https://issues.apache.org/jira/browse/VYSPER-274 Project: VYSPER Issue Type: Bug Environment: any web browser Reporter: Brian Edwards Assignee: Niklas Gustavsson Priority: Trivial Labels: site On http://mina.apache.org/vysper/ HTML element DIV id=subProjectsNavBar contains a link to the AsyncWeb sister project. However the URL the href references, http://mina.apache.org/asyncWeb ,isn't found on the server. The valid resource is located at http://mina.apache.org/asyncweb Uppercase 'W' needs to be changed to lowercase 'w' -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FTPSERVER-403) FTP would periodically hang in MDC
[ https://issues.apache.org/jira/browse/FTPSERVER-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003353#comment-13003353 ] Niklas Gustavsson commented on FTPSERVER-403: - What version of slf4j are you using and have you tried upgrading slf4j? FTP would periodically hang in MDC -- Key: FTPSERVER-403 URL: https://issues.apache.org/jira/browse/FTPSERVER-403 Project: FtpServer Issue Type: Bug Components: Core, Server Affects Versions: 1.0.3, 1.0.4, 1.0.5 Environment: Encountered it both on Linux and FreeBSD, both on Sun JVM 1.6 and OpenJDK 6. Reporter: ArtemGr FTP works fine for the most time but once in a while (depended on how often the FTP is used) it would hang, consuming 100% CPU, in java.util.HashMap.removeEntryForKey (HashMap.java:586) java.util.HashMap.remove (HashMap.java:555) org.slf4j.helpers.BasicMDCAdapter.remove (BasicMDCAdapter.java:91) org.slf4j.MDC.remove (MDC.java:156) org.apache.mina.filter.logging.MdcInjectionFilter.filter (MdcInjectionFilter.java:141) org.apache.mina.filter.util.CommonEventFilter.messageSent (CommonEventFilter.java:75) org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageSent (DefaultIoFilterChain.java:462) org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300 (DefaultIoFilterChain.java:46) org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageSent (DefaultIoFilterChain.java:802) org.apache.mina.filter.codec.ProtocolCodecFilter.messageSent (ProtocolCodecFilter.java:287) org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageSent (DefaultIoFilterChain.java:462) org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300 (DefaultIoFilterChain.java:46) org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageSent (DefaultIoFilterChain.java:802) org.apache.mina.core.filterchain.IoFilterEvent.fire (IoFilterEvent.java:80) org.apache.mina.core.session.IoEvent.run (IoEvent.java:63) org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask (OrderedThreadPoolExecutor.java:780) org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks (OrderedThreadPoolExecutor.java:772) org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run (OrderedThreadPoolExecutor.java:714) The only MDC-related code that our application adds is the following in the UserManager.authenticate implementation: Map context = MDC.getCopyOfContextMap(); if (context != null) System.out.println (FTP user logged in: + context); return user; Seems like a synchronization issue to me. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (VYSPER-272) VCard will be returned as escaped text rather than inlined XML
VCard will be returned as escaped text rather than inlined XML -- Key: VYSPER-272 URL: https://issues.apache.org/jira/browse/VYSPER-272 Project: VYSPER Issue Type: Bug Affects Versions: 0.7 Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 When getting a VCard, it's currently rendered and inserted as text. However, this will be treated as text and escaped on output. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (VYSPER-273) Setting VCard for other user will not return error
Setting VCard for other user will not return error -- Key: VYSPER-273 URL: https://issues.apache.org/jira/browse/VYSPER-273 Project: VYSPER Issue Type: Bug Affects Versions: 0.7 Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 When trying to set another users VCard, currently no error will be returned and it will instead update the sending users vcard -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (VYSPER-272) VCard will be returned as escaped text rather than inlined XML
[ https://issues.apache.org/jira/browse/VYSPER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed VYSPER-272. Resolution: Fixed Fixed in rev 1078457. VCard will be returned as escaped text rather than inlined XML -- Key: VYSPER-272 URL: https://issues.apache.org/jira/browse/VYSPER-272 Project: VYSPER Issue Type: Bug Affects Versions: 0.7 Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 When getting a VCard, it's currently rendered and inserted as text. However, this will be treated as text and escaped on output. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (VYSPER-273) Setting VCard for other user will not return error
[ https://issues.apache.org/jira/browse/VYSPER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed VYSPER-273. Resolution: Fixed Fixed in rev 1078457. Setting VCard for other user will not return error -- Key: VYSPER-273 URL: https://issues.apache.org/jira/browse/VYSPER-273 Project: VYSPER Issue Type: Bug Affects Versions: 0.7 Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Fix For: 0.8 When trying to set another users VCard, currently no error will be returned and it will instead update the sending users vcard -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
