[jira] [Commented] (MATH-423) Upgrade all test code to Junit 4
[ https://issues.apache.org/jira/browse/MATH-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13012009#comment-13012009 ] Gilles commented on MATH-423: - I don't know; I never looked at the tests that were supposed to need that. However, it doesn't hurt to keep the possibility, but as I suggested, on a method basis. I propose to make the changes to the RetryRunner class and, for the time being, not add the @Retry annotation to any methods; hence we'll know if some tests, sometimes, still fail. Upgrade all test code to Junit 4 Key: MATH-423 URL: https://issues.apache.org/jira/browse/MATH-423 Project: Commons Math Issue Type: Task Reporter: Gilles Priority: Minor Fix For: 3.0 Make all tests use the JUnit 4 annotation-based syntax. -- 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-tabpanelfocusedCommentId=13012020#comment-13012020
]
Bogdan Drozdowski commented on NET-333:
---
What fields in IMAPReply are needed? The reply codes? Now, since reply parsing
is in the same class, they're just in case the user wants to check manually.
Yes, users can override the generateCommandID() method, but not only this
requires a new class (can't do this from a class that's just using IMAP), but
also the users can't override the initial tag this way.
Had a look at the code, looks good to me. I see you're testing the tag
generator - good, because I've only checked only about 30 or 40 tags in a row
(without sending any commands). On the other hand, if the generator increases
the length instead of wrapping, a new test will have to be written (but it's
not a problem right now). I've just spotted a tiny thing: in the example class,
IMAPMail.java, you have:
{code}
// enable the next line if the server certificate has expired:
// ((IMAPSClient)
imap).setTrustManager(TrustManagerUtils.getValidateServerCertificateTrustManager());
{code}
while I think it should be:
{code}
// enable the next line if the server certificate has NOT expired:
// ((IMAPSClient)
imap).setTrustManager(TrustManagerUtils.getValidateServerCertificateTrustManager());
{code}
A tiny thing, but can confuse (if I'm right). And
{code}
public String getIMAPCommand() {
return imapCommand != null ? imapCommand : name();
}
{code}
should be changed to:
{code}
public String getIMAPCommand() {
return imapCommand != null ? imapCommand : toString();
}
{code}
because, as far as I remember, toString() actually returns the name of the
constant, while name() returns something more - a more (or fully) qualified
name of the constant. Probably not the thing we want. The enum can't be
extended by user code, but looks cleaner than the original class.
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] [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-tabpanelfocusedCommentId=13012030#comment-13012030 ] Sebb commented on NET-333: -- Since generateCommandID() returns the tag, users can override the initial (and all other) tags. AFAIK, the test for generateCommandID() will work with any length of tag. It won't work if the alphabet is changed - e.g. if both upper and lower case were used. This could be fixed by looking for the number of tags returned before the last character repeats, and using that instead of 26. Agreed re comment in IMAPMail - I'll fix that. getIMAPCommand() is correct - see: http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Enum.html#name() 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] [Resolved] (JEXL-110) conceptual improvement for the language
[ https://issues.apache.org/jira/browse/JEXL-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-110. Resolution: Won't Fix Fix Version/s: 2.0.2 Assignee: Henri Biestro No news, no comment, no case; closing as wont fix. conceptual improvement for the language --- Key: JEXL-110 URL: https://issues.apache.org/jira/browse/JEXL-110 Project: Commons JEXL Issue Type: Improvement Reporter: Cristian Lorenzetto Assignee: Henri Biestro Fix For: 2.0.2 the language dont distinguish when a object is null and when is undefined we could add a keyword undefined -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LOGGING-142) Log4JLogger uses deprecated static members of Priority such as INFO
Log4JLogger uses deprecated static members of Priority such as INFO --- Key: LOGGING-142 URL: https://issues.apache.org/jira/browse/LOGGING-142 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.1 Reporter: Jingguo Yao In version 1.1.1, Log4JLogger uses deprecated static members of Priority such as INFO to construct LoggingEvent. In version 1.0.4, static members from Level are used rather than from Priority. I think that this is a regression. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOGGING-142) Log4JLogger uses deprecated static members of Priority such as INFO
[ https://issues.apache.org/jira/browse/LOGGING-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingguo Yao updated LOGGING-142: Attachment: LOGGING-142.patch Patch available. Log4JLogger uses deprecated static members of Priority such as INFO --- Key: LOGGING-142 URL: https://issues.apache.org/jira/browse/LOGGING-142 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.1 Reporter: Jingguo Yao Attachments: LOGGING-142.patch Original Estimate: 2h Remaining Estimate: 2h In version 1.1.1, Log4JLogger uses deprecated static members of Priority such as INFO to construct LoggingEvent. In version 1.0.4, static members from Level are used rather than from Priority. I think that this is a regression. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-423) Upgrade all test code to Junit 4
[ https://issues.apache.org/jira/browse/MATH-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13012162#comment-13012162 ] Luc Maisonobe commented on MATH-423: I think we still needs it, there were some failures in gump one or two weeks ago that may be related to this. It also occurred that new tests did fail (for example in CMAE optimizer, but I don't know if it was fixed since then). Sorry Gilles to have overstep on your work. I agree having retry on individual tests is better than on the all class. Upgrade all test code to Junit 4 Key: MATH-423 URL: https://issues.apache.org/jira/browse/MATH-423 Project: Commons Math Issue Type: Task Reporter: Gilles Priority: Minor Fix For: 3.0 Make all tests use the JUnit 4 annotation-based syntax. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (NET-395) Move ProtocolCommandSupport to SocketClient
[ https://issues.apache.org/jira/browse/NET-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-395. -- Resolution: Fixed Move ProtocolCommandSupport to SocketClient --- Key: NET-395 URL: https://issues.apache.org/jira/browse/NET-395 Project: Commons Net Issue Type: Improvement Reporter: Sebb All the SocketClient subclass branches currently define a ProtocolCommandSupport field and supporting methods. This seems to be unnecessary duplication; the code could be moved to the common super-class, i.e. SocketClient -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (NET-396) POP3.setState() should not be public
POP3.setState() should not be public Key: NET-396 URL: https://issues.apache.org/jira/browse/NET-396 Project: Commons Net Issue Type: Bug Components: POP3 Affects Versions: 2.2 Reporter: Sebb The POP3 method setState() is public. However, the state should only be settable by library methods, not by client code, otherwise the state checks won't work correctly. Changing the visibility would break binary compatibility. To maintain compatibility there could be a new method (package-private, which would give test cases access) which is allowed to set the state. Also change the public method to either do nothing or throw an UnsupportedOperationException. The getState() method can remain public. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
