[jira] [Updated] (NET-391) CommandSupport listener should be invoked before throwing an Exception if the reply is not valid
[ https://issues.apache.org/jira/browse/NET-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-391: - Description: The __getReply() methods check for a valid reply, and throw an exception if the reply is unexpected. This is done before the CommandSupport listener is called, because the listener needs to be passed the reply code. This means that the listener does not see invalid replies. It might be useful to pass the reply to the listener even if the validation fails. was: The __getReply() methods check for a valid reply, and throw an exception if the reply is unexpected. However at present this is generally done before the CommandSupport listener has been informed, which means that the listener won't see the reply that caused the problem. The methods should be changed to report the response before validation. Issue Type: Improvement (was: Bug) > CommandSupport listener should be invoked before throwing an Exception if the > reply is not valid > > > Key: NET-391 > URL: https://issues.apache.org/jira/browse/NET-391 > Project: Commons Net > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Sebb >Assignee: Sebb >Priority: Minor > > The __getReply() methods check for a valid reply, and throw an exception if > the reply is unexpected. > This is done before the CommandSupport listener is called, because the > listener needs to be passed the reply code. > This means that the listener does not see invalid replies. > It might be useful to pass the reply to the listener even if the validation > fails. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (NET-391) CommandSupport listener should be invoked before throwing an Exception if the reply is not valid
CommandSupport listener should be invoked before throwing an Exception if the reply is not valid Key: NET-391 URL: https://issues.apache.org/jira/browse/NET-391 Project: Commons Net Issue Type: Bug Affects Versions: 2.2 Reporter: Sebb Assignee: Sebb Priority: Minor The __getReply() methods check for a valid reply, and throw an exception if the reply is unexpected. However at present this is generally done before the CommandSupport listener has been informed, which means that the listener won't see the reply that caused the problem. The methods should be changed to report the response before validation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-333) would you provide a class used for imap protocol?
[ https://issues.apache.org/jira/browse/NET-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011636#comment-13011636 ] Sebb commented on NET-333: -- Thanks, I'll try the new example code shortly. I commented out the printouts in the example, because it's now using the command listener - there's no need for both. I'll probably remove them, as it makes it easier to see the main code. I agree getAdditionalReply() is not needed. > would you provide a class used for imap protocol? > - > > Key: NET-333 > URL: https://issues.apache.org/jira/browse/NET-333 > Project: Commons Net > Issue Type: Improvement >Reporter: iceviewer > Attachments: IMAP.zip, IMAPMail.java > > > would you provide a class used for imap protocol? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (NET-331) AS400 file timestamp format is wrong
[ https://issues.apache.org/jira/browse/NET-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008765#comment-13008765 ] Sebb edited comment on NET-331 at 3/26/11 1:39 PM: --- Should have realised earlier that the FTPClientConfig.setDefaultDateFormatStr(format) method can be used to override the default format provided by the parser. So for example: {code} FTPClient f=FTPClient(); FTPClientConfig conf = new FTPClientConfig(FTPClientConfig.SYST_UNIX); conf.setDefaultDateFormat("MM/dd/yy HH:mm:ss"); f.configure(conf); // Apply the configuration {code} Or the parser could override the preParse() method to scan the raw results and decide which format to use when the main parse is called. was (Author: s...@apache.org): Should have realised earlier that the FTPClientConfig.setDefaultDateFormatStr(format) method can be used to override the default format provided by the parser. So for example: {code} FTPClient f=FTPClient(); FTPClientConfig conf = new FTPClientConfig(FTPClientConfig.SYST_UNIX); conf.setDefaultDateFormat("MM/dd/yy HH:mm:ss"); {code} Or the parser could override the preParse() method to scan the raw results and decide which format to use when the main parse is called. > AS400 file timestamp format is wrong > > > Key: NET-331 > URL: https://issues.apache.org/jira/browse/NET-331 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 2.0 > Environment: AS400 >Reporter: Jim Urban > Original Estimate: 0h > Remaining Estimate: 0h > > There is a bug in org.apache.commons.net.ftp.parser.OS400FTPEntryParser.java. > The variable "private static final String DEFAULT_DATE_FORMAT" needs to be > changed from "yy/MM/dd HH:mm:ss"; //01/11/09 12:30:24 to "MM/dd/yy HH:mm:ss"; > //01/15/08 14:21:38 to work correctly. I have tested this on our companies > AS400 and it solved the problem we were having. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-333) would you provide a class used for imap protocol?
[ https://issues.apache.org/jira/browse/NET-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011628#comment-13011628 ] Bogdan Drozdowski commented on NET-333: --- Explicit mode doesn't hang for me: {noformat} * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN AUTH=CRAM-MD5] Dovecot ready. TLS: success='true', reply: OK Begin TLS negotiation now. LOGIN: success='true', reply: AAAB OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS] Logged in CAPA: success='true', reply: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS AAAC OK Capability completed. NOOP: success='true', reply: AAAD OK NOOP completed. SELECT: success='true', reply: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. {noformat} My code is: {code} IMAPSClient c = new IMAPSClient (false); c.setTrustManager (new X509TrustManager () { private final java.security.cert.X509Certificate[] EMPTY_X509CERTIFICATE_ARRAY = new java.security.cert.X509Certificate[]{}; /** * No-op */ public void checkClientTrusted(java.security.cert.X509Certificate[] certificates, String authType) { return; } public void checkServerTrusted(java.security.cert.X509Certificate[] certificates, String authType) throws java.security.cert.CertificateExpiredException, java.security.cert.CertificateNotYetValidException { for (int i = 0; i < certificates.length; ++i) { certificates[i].checkValidity(); } } public java.security.cert.X509Certificate[] getAcceptedIssuers() { return EMPTY_X509CERTIFICATE_ARRAY; } }); c.setEnabledProtocols (new String[] {"SSLv3", "TLSv1", "SSLv2Hello"}); c.connect ("127.0.0.1", 143); System.out.println (c.getReplyString()); boolean a; a = c.execTLS(); System.out.println ("TLS: success='" + a + "', reply: " + c.getReplyString()); a = c.login ("bogdan", "bogdan"); System.out.println ("LOGIN: success='" + a + "', reply: " + c.getReplyString()); a = c.capability(); System.out.println ("CAPA: success='" + a + "', reply: " + c.getReplyString()); a = c.noop(); System.out.println ("NOOP: success='" + a + "', reply: " + c.getReplyString()); a = c.select("inbox"); System.out.println ("SELECT: success='" + a + "', reply: " + c.getReplyString()); {code} You can seee an accept-all TrustManager, which I've used then because of the same Exception you had. You're right about the "* OK". I see two solutions: remember the last tag and scan for it in the response (your solution) or make a boolean saying that the initial response has already been received, so scanning for untagged OK responses should not happen anymore. The '*' stays as a line continuation mark, however. Lookin closer at the file in the repository: * the "// The length() ..." comment in __getReply() can be removed * the getAdditionalReply() method *probably* won't be needed any more (I don't know how does an IMAP server return a message body, but I presume it'll be followed by a tagged response anyway). I copied it from POP3Client, but IMAP probably works in a different way * IMAPMail has all responses commented-out. Just checking: was this the way it was supposed to be (just to show the usage, not the replies)? Anyway, imap.getAdditionalReply() may hang, because it waits for a line consisting of only a period, and this is probably not a part of the IMAP protocol. Sorry for not replying for so long, I had no time for this recently. > would you provide a class used for imap protocol? > - > > Key: NET-333 > URL: https://issues.apache.org/jira/browse/NET-333 > Project: Commons Net > Issue Type: Improvement >Reporter: iceviewer > Attachments: IMAP.zip, IMAPMail.java > > > would you provide a class used for imap protocol? -- This message is automatically generated by JIRA. For more information on JIRA, see: http:/