[jira] [Commented] (CSV-196) Store the information of raw data read by lexer
[ https://issues.apache.org/jira/browse/CSV-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15865306#comment-15865306 ] Benedikt Ritter commented on CSV-196: - I've asked the ML to comment on the proposal. > Store the information of raw data read by lexer > --- > > Key: CSV-196 > URL: https://issues.apache.org/jira/browse/CSV-196 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.4 >Reporter: Matt Sun > Labels: patch > Fix For: Patch Needed > > Original Estimate: 48h > Remaining Estimate: 48h > > It will be good to have CSVParser class to store the info of whether a field > was enclosed by quotes in the original source file. > For example, for this data sample: > A, B, C > a1, "b1", c1 > CSVParser gives us record a1, b1, c1, which is helpful because it parsed > double quotes, but we also lost the information of original data at the same > time. We can't tell from the CSVRecord returned whether the original data is > enclosed by double quotes or not. > In our use case, we are integrating Apache Hadoop APIs with Commons CSV. CSV > is one kind of input of Hadoop Jobs, which should support splitting input > data. To accurately split a CSV file into pieces, we need to count the bytes > of data CSVParser actually read. CSVParser doesn't have accurate information > of whether a field was enclosed by quotes, neither does it store raw data of > the original source. Downstream users of commons CSVParser is not able to get > those info. > To suggest a fix: Extend the token/CSVRecord to have a boolean field > indicating whether the column was enclosed by quotes. While Lexer is doing > getNextToken, set the flag if a field is encapsulated and successfully parsed. > I find another issue reported with similar request, but it was marked as > resolved: [CSV91] > https://issues.apache.org/jira/browse/CSV-91?jql=project%20%3D%20CSV%20AND%20text%20~%20%22with%20quotes%22 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CSV-196) Store the information of raw data read by lexer
[ https://issues.apache.org/jira/browse/CSV-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15865296#comment-15865296 ] Benedikt Ritter commented on CSV-196: - [~mattsun] so you don't need to know which bytes have been read, but rather need information about the characters? Do you think storing the additional characters will have a significant impact on performance? Maybe this should be opt-in for the user, so he can configure it. > Store the information of raw data read by lexer > --- > > Key: CSV-196 > URL: https://issues.apache.org/jira/browse/CSV-196 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.4 >Reporter: Matt Sun > Labels: patch > Fix For: Patch Needed > > Original Estimate: 48h > Remaining Estimate: 48h > > It will be good to have CSVParser class to store the info of whether a field > was enclosed by quotes in the original source file. > For example, for this data sample: > A, B, C > a1, "b1", c1 > CSVParser gives us record a1, b1, c1, which is helpful because it parsed > double quotes, but we also lost the information of original data at the same > time. We can't tell from the CSVRecord returned whether the original data is > enclosed by double quotes or not. > In our use case, we are integrating Apache Hadoop APIs with Commons CSV. CSV > is one kind of input of Hadoop Jobs, which should support splitting input > data. To accurately split a CSV file into pieces, we need to count the bytes > of data CSVParser actually read. CSVParser doesn't have accurate information > of whether a field was enclosed by quotes, neither does it store raw data of > the original source. Downstream users of commons CSVParser is not able to get > those info. > To suggest a fix: Extend the token/CSVRecord to have a boolean field > indicating whether the column was enclosed by quotes. While Lexer is doing > getNextToken, set the flag if a field is encapsulated and successfully parsed. > I find another issue reported with similar request, but it was marked as > resolved: [CSV91] > https://issues.apache.org/jira/browse/CSV-91?jql=project%20%3D%20CSV%20AND%20text%20~%20%22with%20quotes%22 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (VALIDATOR-418) UrlValidatorTest: testIsValid() does not run all tests
[ https://issues.apache.org/jira/browse/VALIDATOR-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter resolved VALIDATOR-418. --- Resolution: Fixed Assignee: Benedikt Ritter Fix Version/s: 1.6 > UrlValidatorTest: testIsValid() does not run all tests > -- > > Key: VALIDATOR-418 > URL: https://issues.apache.org/jira/browse/VALIDATOR-418 > Project: Commons Validator > Issue Type: Bug >Reporter: Robert McGuigan >Assignee: Benedikt Ritter >Priority: Minor > Fix For: 1.6 > > Attachments: Validator-418-test.patch > > > The method testIsValid() does not iterate through all possible combinations > of scheme, authority, etc. Namely, the last element in testUrlScheme is > skipped. This is due to a bug in incrementTestPartsIndex, which returns > false (indicating the maximum set of indices has been reached) prematurely. > Incidentally, the last test scheme currently present is the empty scheme "". > This test case has been removed in the provided patch because the url string > parser appears to assume that the scheme is nonempty. (e.g. if the scheme is > empty, the scheme field will often be populated with the authority data). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (VALIDATOR-418) UrlValidatorTest: testIsValid() does not run all tests
[
https://issues.apache.org/jira/browse/VALIDATOR-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15865257#comment-15865257
]
Benedikt Ritter commented on VALIDATOR-418:
---
{code}
~/w/a/c/commons-validator > svn ci -m "VALIDATOR-418: UrlValidatorTest:
testIsValid() does not run all tests. Thanks to Robert McGuigan."
SendingRELEASE-NOTES.txt
Sendingsrc/changes/changes.xml
Sending
src/test/java/org/apache/commons/validator/routines/UrlValidatorTest.java
Transmitting file data ...done
Committing transaction...
Committed revision 1782919.
{code}
Thank you!
> UrlValidatorTest: testIsValid() does not run all tests
> --
>
> Key: VALIDATOR-418
> URL: https://issues.apache.org/jira/browse/VALIDATOR-418
> Project: Commons Validator
> Issue Type: Bug
>Reporter: Robert McGuigan
>Priority: Minor
> Attachments: Validator-418-test.patch
>
>
> The method testIsValid() does not iterate through all possible combinations
> of scheme, authority, etc. Namely, the last element in testUrlScheme is
> skipped. This is due to a bug in incrementTestPartsIndex, which returns
> false (indicating the maximum set of indices has been reached) prematurely.
> Incidentally, the last test scheme currently present is the empty scheme "".
> This test case has been removed in the provided patch because the url string
> parser appears to assume that the scheme is nonempty. (e.g. if the scheme is
> empty, the scheme field will often be populated with the authority data).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (VALIDATOR-418) UrlValidatorTest: testIsValid() does not run all tests
[ https://issues.apache.org/jira/browse/VALIDATOR-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert McGuigan updated VALIDATOR-418: -- Attachment: Validator-418-test.patch In UrlValidatorTest.java, fixes incrementTestPartsIndex() to properly cycle through all indices; and removes the test case where the scheme is the empty string. > UrlValidatorTest: testIsValid() does not run all tests > -- > > Key: VALIDATOR-418 > URL: https://issues.apache.org/jira/browse/VALIDATOR-418 > Project: Commons Validator > Issue Type: Bug >Reporter: Robert McGuigan >Priority: Minor > Attachments: Validator-418-test.patch > > > The method testIsValid() does not iterate through all possible combinations > of scheme, authority, etc. Namely, the last element in testUrlScheme is > skipped. This is due to a bug in incrementTestPartsIndex, which returns > false (indicating the maximum set of indices has been reached) prematurely. > Incidentally, the last test scheme currently present is the empty scheme "". > This test case has been removed in the provided patch because the url string > parser appears to assume that the scheme is nonempty. (e.g. if the scheme is > empty, the scheme field will often be populated with the authority data). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (VALIDATOR-418) UrlValidatorTest: testIsValid() does not run all tests
Robert McGuigan created VALIDATOR-418: - Summary: UrlValidatorTest: testIsValid() does not run all tests Key: VALIDATOR-418 URL: https://issues.apache.org/jira/browse/VALIDATOR-418 Project: Commons Validator Issue Type: Bug Reporter: Robert McGuigan Priority: Minor The method testIsValid() does not iterate through all possible combinations of scheme, authority, etc. Namely, the last element in testUrlScheme is skipped. This is due to a bug in incrementTestPartsIndex, which returns false (indicating the maximum set of indices has been reached) prematurely. Incidentally, the last test scheme currently present is the empty scheme "". This test case has been removed in the provided patch because the url string parser appears to assume that the scheme is nonempty. (e.g. if the scheme is empty, the scheme field will often be populated with the authority data). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CRYPTO-133) OpenSslCryptoRandomNative.nextRandBytes not thread safe
[
https://issues.apache.org/jira/browse/CRYPTO-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15864362#comment-15864362
]
Marcelo Vanzin commented on CRYPTO-133:
---
bq. If the Javadoc does not state that the code is thread-safe, then no
assumptions can be made about thread-safety.
Fair but, in this case, a little weird, since related APIs like
{{java.util.Random}} and {{java.security.SecureRandom}} are thread-safe. So
it's not really unreasonable to expect this API to be thread-safe too.
> OpenSslCryptoRandomNative.nextRandBytes not thread safe
> ---
>
> Key: CRYPTO-133
> URL: https://issues.apache.org/jira/browse/CRYPTO-133
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Hendrik Saly
>
> Seems that AbstractRandomTest.testRandomBytesMultiThreaded is failing for
> OpenSslCryptoRandomNative.nextRandBytes.
> Testcase throws exceptions like
> {code}
> java.lang.IllegalArgumentException: The nextRandBytes method failed
> at
> org.apache.commons.crypto.random.OpenSslCryptoRandom.nextBytes(OpenSslCryptoRandom.java:108)
> at
> org.apache.commons.crypto.random.AbstractRandomTest.checkRandomBytes(AbstractRandomTest.java:94)
> at
> org.apache.commons.crypto.random.AbstractRandomTest.access$000(AbstractRandomTest.java:30)
> at
> org.apache.commons.crypto.random.AbstractRandomTest$1.run(AbstractRandomTest.java:63)
> {code}
> When adding a 'synchronized' modifier to
> OpenSslCryptoRandomNative.nextRandBytes it works.
> So IMHO there are two bugs that need to be resolved:
> 1) fix testcase AbstractRandomTest.testRandomBytesMultiThreaded in that way
> that it fails when exception are thrown
> 2) fix OpenSslCryptoRandomNative.nextRandBytes no be thread safe (of course
> not by adding 'synchronized', seems like locks_setup() is broken somehow in
> https://github.com/apache/commons-crypto/blob/master/src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c#L299
>
> The testcase can be fixed with something like this
> {code}
> @Test(timeout = 12)
> public void testRandomBytesMultiThreaded() throws Exception {
> final int threadCount = 100;
> final AtomicBoolean hasErrors = new AtomicBoolean();
> try (final CryptoRandom random = getCryptoRandom()) {
> final List threads = new ArrayList<>(threadCount);
> for (int i = 0; i < threadCount; i++) {
> Thread t = new Thread(new Runnable() {
> @Override
> public void run() {
> try {
>
> checkRandomBytes(random, 10);
>
> checkRandomBytes(random, 1000);
>
> checkRandomBytes(random, 10);
> } catch (Exception e) {
> hasErrors.set(true);
> e.printStackTrace();
> }
> }
> });
> t.start();
> threads.add(t);
> }
> for (Thread t : threads) {
> if (!t.getState().equals(State.NEW)) {
> t.join();
> }
> }
>
> if(hasErrors.get()) {
> Assert.fail();
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CRYPTO-125) CryptoOutputStream does not call write in a loop when underlying channel works in non-block mode.
[
https://issues.apache.org/jira/browse/CRYPTO-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15864349#comment-15864349
]
Marcelo Vanzin commented on CRYPTO-125:
---
Hi there,
I don't think this fix is correct. The issue here is that
{{CryptoOutputStream}} is not really following the API defined by
{{WritableByteChannel}}. That API allows the channel to write less data than
available in the input buffer (and the calling code needs to be able to handle
that situation). That's required for non-blocking I/O.
This change will cause really high CPU usage if the underlying channel is
non-blocking and is not ready for write, and will undesirably block I/O threads
in that situation (e.g., instead of giving control back to the application so
it can write to other channels that are ready, it will go into a busy loop
until this one output channel becomes ready).
> CryptoOutputStream does not call write in a loop when underlying channel
> works in non-block mode.
> -
>
> Key: CRYPTO-125
> URL: https://issues.apache.org/jira/browse/CRYPTO-125
> Project: Commons Crypto
> Issue Type: Bug
> Components: Stream
>Affects Versions: 1.0.0
>Reporter: Junjie Chen
>Assignee: Junjie Chen
> Fix For: 1.1.0
>
>
> The encrypt function call output.write without loop which lead to data loss
> when creating the output encryption stream with a SocketChannel and works in
> non-block mode.
> As suggested, it should be call as following way:
> while(buf.hasRemaining()) {
> channel.write(buf);
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CSV-196) Store the information of raw data read by lexer
[ https://issues.apache.org/jira/browse/CSV-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sun updated CSV-196: - Labels: patch (was: easyfix features patch) > Store the information of raw data read by lexer > --- > > Key: CSV-196 > URL: https://issues.apache.org/jira/browse/CSV-196 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.4 >Reporter: Matt Sun > Labels: patch > Fix For: Patch Needed > > Original Estimate: 48h > Remaining Estimate: 48h > > It will be good to have CSVParser class to store the info of whether a field > was enclosed by quotes in the original source file. > For example, for this data sample: > A, B, C > a1, "b1", c1 > CSVParser gives us record a1, b1, c1, which is helpful because it parsed > double quotes, but we also lost the information of original data at the same > time. We can't tell from the CSVRecord returned whether the original data is > enclosed by double quotes or not. > In our use case, we are integrating Apache Hadoop APIs with Commons CSV. CSV > is one kind of input of Hadoop Jobs, which should support splitting input > data. To accurately split a CSV file into pieces, we need to count the bytes > of data CSVParser actually read. CSVParser doesn't have accurate information > of whether a field was enclosed by quotes, neither does it store raw data of > the original source. Downstream users of commons CSVParser is not able to get > those info. > To suggest a fix: Extend the token/CSVRecord to have a boolean field > indicating whether the column was enclosed by quotes. While Lexer is doing > getNextToken, set the flag if a field is encapsulated and successfully parsed. > I find another issue reported with similar request, but it was marked as > resolved: [CSV91] > https://issues.apache.org/jira/browse/CSV-91?jql=project%20%3D%20CSV%20AND%20text%20~%20%22with%20quotes%22 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NET-601) IMAPClient.select cannot select mailbox in some cases with æøå, spaces and sub-folders
[
https://issues.apache.org/jira/browse/NET-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15864208#comment-15864208
]
Johnny Haugen Sørgård commented on NET-601:
---
Configured Thunderbird to maximum verbose level. (since it works).
Looking at the log I found that in some cases the transferred foldername used
\\ as folder - subfolder separator. In other cases Thunderbird transferred
as folder - subfolder separator. So rewriting folder-select routine seems
to work:
if (!imapClient.select(fName)){
fName = fName.replace("\\", "");
imapClient.select(fName));
}
> IMAPClient.select cannot select mailbox in some cases with æøå, spaces and
> sub-folders
> --
>
> Key: NET-601
> URL: https://issues.apache.org/jira/browse/NET-601
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.5
> Environment: eclipse on ubuntu workstation and ibm domino server on
> ubuntu server. Connecting to IMAP on an IBM Domino server.
>Reporter: Johnny Haugen Sørgård
> Attachments: import_startssl_to_javahome.windows.zip,
> testCommonsNetIMAPselect.java
>
>
> Partial response from LIST:
> AAAB LIST "" "*"
> * LIST (\HasNoChildren) "\\" "Backup log"
> * LIST (\Noinferiors \HasNoChildren) "\\" Inbox
> * LIST (\HasNoChildren) "\\" M
> * LIST (\HasChildren) "\\" Presis
> * LIST (\HasNoChildren) "\\" {24}
> Presis\Bod Industri
> * LIST (\HasNoChildren) "\\" {11}
> Presis\Done
> * LIST (\HasNoChildren) "\\" {15}
> Presis\id filer
> Trying to select Presis\Bodø Industri fails like this
> AAAB SELECT "Presis\Bod Industri"
> AAAB NO SELECT failure, cannot select mailbox: Folder not found in IMAP name
> space
> And trying to select Presis\id filer fails like this
> AAAB SELECT "Presis\id filer"
> AAAB NO SELECT failure, cannot select mailbox: Folder not found in IMAP name
> space
> So far it seems like select fails when folder has more than one:
> * none US-ASCII
> * space
> * sub-folder separator
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CSV-196) Store the information of raw data read by lexer
[ https://issues.apache.org/jira/browse/CSV-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15864138#comment-15864138 ] Matt Sun commented on CSV-196: -- I just changed the title because I realized that the problem is more complicated than previously thought. Delimiter information might not be the only information missing for downstream user. Again, same scenario as described, Commons CSV library is being used with Hadoop library as an input format (csv). To support splitting the input of Hadoop jobs, the program needs to know how much input file has been read (thus working within the split boundary). And to leverage the capability of CSVParser, we usually want to "ignoreSurroundingSpace", "trim" and also handling "encapsulator". Thus, for a csv field like A, "B" , C the parser gives us back A, B and C. It seems to the java program that there are only three characters read from input file, which is not true. So now what I'm proposing: using another StringBuilder in token which stores the raw data read for the token, including space and encapsulator. Maintainers, what do you think? > Store the information of raw data read by lexer > --- > > Key: CSV-196 > URL: https://issues.apache.org/jira/browse/CSV-196 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.4 >Reporter: Matt Sun > Labels: easyfix, features, patch > Fix For: Patch Needed > > Original Estimate: 48h > Remaining Estimate: 48h > > It will be good to have CSVParser class to store the info of whether a field > was enclosed by quotes in the original source file. > For example, for this data sample: > A, B, C > a1, "b1", c1 > CSVParser gives us record a1, b1, c1, which is helpful because it parsed > double quotes, but we also lost the information of original data at the same > time. We can't tell from the CSVRecord returned whether the original data is > enclosed by double quotes or not. > In our use case, we are integrating Apache Hadoop APIs with Commons CSV. CSV > is one kind of input of Hadoop Jobs, which should support splitting input > data. To accurately split a CSV file into pieces, we need to count the bytes > of data CSVParser actually read. CSVParser doesn't have accurate information > of whether a field was enclosed by quotes, neither does it store raw data of > the original source. Downstream users of commons CSVParser is not able to get > those info. > To suggest a fix: Extend the token/CSVRecord to have a boolean field > indicating whether the column was enclosed by quotes. While Lexer is doing > getNextToken, set the flag if a field is encapsulated and successfully parsed. > I find another issue reported with similar request, but it was marked as > resolved: [CSV91] > https://issues.apache.org/jira/browse/CSV-91?jql=project%20%3D%20CSV%20AND%20text%20~%20%22with%20quotes%22 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CSV-196) Store the information of raw data read by lexer
[ https://issues.apache.org/jira/browse/CSV-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sun updated CSV-196: - Summary: Store the information of raw data read by lexer (was: Store the info of whether a field is enclosed by quotes) > Store the information of raw data read by lexer > --- > > Key: CSV-196 > URL: https://issues.apache.org/jira/browse/CSV-196 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.4 >Reporter: Matt Sun > Labels: easyfix, features, patch > Fix For: Patch Needed > > Original Estimate: 48h > Remaining Estimate: 48h > > It will be good to have CSVParser class to store the info of whether a field > was enclosed by quotes in the original source file. > For example, for this data sample: > A, B, C > a1, "b1", c1 > CSVParser gives us record a1, b1, c1, which is helpful because it parsed > double quotes, but we also lost the information of original data at the same > time. We can't tell from the CSVRecord returned whether the original data is > enclosed by double quotes or not. > In our use case, we are integrating Apache Hadoop APIs with Commons CSV. CSV > is one kind of input of Hadoop Jobs, which should support splitting input > data. To accurately split a CSV file into pieces, we need to count the bytes > of data CSVParser actually read. CSVParser doesn't have accurate information > of whether a field was enclosed by quotes, neither does it store raw data of > the original source. Downstream users of commons CSVParser is not able to get > those info. > To suggest a fix: Extend the token/CSVRecord to have a boolean field > indicating whether the column was enclosed by quotes. While Lexer is doing > getNextToken, set the flag if a field is encapsulated and successfully parsed. > I find another issue reported with similar request, but it was marked as > resolved: [CSV91] > https://issues.apache.org/jira/browse/CSV-91?jql=project%20%3D%20CSV%20AND%20text%20~%20%22with%20quotes%22 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NET-601) IMAPClient.select cannot select mailbox in some cases with æøå, spaces and sub-folders
[
https://issues.apache.org/jira/browse/NET-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15864064#comment-15864064
]
Johnny Haugen Sørgård commented on NET-601:
---
Even at highest debug-verbose level there was no information at the server log
when failing to select a folder.
> IMAPClient.select cannot select mailbox in some cases with æøå, spaces and
> sub-folders
> --
>
> Key: NET-601
> URL: https://issues.apache.org/jira/browse/NET-601
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.5
> Environment: eclipse on ubuntu workstation and ibm domino server on
> ubuntu server. Connecting to IMAP on an IBM Domino server.
>Reporter: Johnny Haugen Sørgård
> Attachments: import_startssl_to_javahome.windows.zip,
> testCommonsNetIMAPselect.java
>
>
> Partial response from LIST:
> AAAB LIST "" "*"
> * LIST (\HasNoChildren) "\\" "Backup log"
> * LIST (\Noinferiors \HasNoChildren) "\\" Inbox
> * LIST (\HasNoChildren) "\\" M
> * LIST (\HasChildren) "\\" Presis
> * LIST (\HasNoChildren) "\\" {24}
> Presis\Bod Industri
> * LIST (\HasNoChildren) "\\" {11}
> Presis\Done
> * LIST (\HasNoChildren) "\\" {15}
> Presis\id filer
> Trying to select Presis\Bodø Industri fails like this
> AAAB SELECT "Presis\Bod Industri"
> AAAB NO SELECT failure, cannot select mailbox: Folder not found in IMAP name
> space
> And trying to select Presis\id filer fails like this
> AAAB SELECT "Presis\id filer"
> AAAB NO SELECT failure, cannot select mailbox: Folder not found in IMAP name
> space
> So far it seems like select fails when folder has more than one:
> * none US-ASCII
> * space
> * sub-folder separator
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NET-601) IMAPClient.select cannot select mailbox in some cases with æøå, spaces and sub-folders
[
https://issues.apache.org/jira/browse/NET-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15864032#comment-15864032
]
Johnny Haugen Sørgård commented on NET-601:
---
Have create 2 subfolders:
Presis\\asciiOnly
Presis\\ascii subfolder with spaces
Sorry, that I didn't test against other servers. Have tested against
outlook.com. Seems to work without any flaws.
The server with issues runs IBM Domino. I will configure server, add some more
debug-information, and see if it will shed some light to the problem.
> IMAPClient.select cannot select mailbox in some cases with æøå, spaces and
> sub-folders
> --
>
> Key: NET-601
> URL: https://issues.apache.org/jira/browse/NET-601
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.5
> Environment: eclipse on ubuntu workstation and ibm domino server on
> ubuntu server. Connecting to IMAP on an IBM Domino server.
>Reporter: Johnny Haugen Sørgård
> Attachments: import_startssl_to_javahome.windows.zip,
> testCommonsNetIMAPselect.java
>
>
> Partial response from LIST:
> AAAB LIST "" "*"
> * LIST (\HasNoChildren) "\\" "Backup log"
> * LIST (\Noinferiors \HasNoChildren) "\\" Inbox
> * LIST (\HasNoChildren) "\\" M
> * LIST (\HasChildren) "\\" Presis
> * LIST (\HasNoChildren) "\\" {24}
> Presis\Bod Industri
> * LIST (\HasNoChildren) "\\" {11}
> Presis\Done
> * LIST (\HasNoChildren) "\\" {15}
> Presis\id filer
> Trying to select Presis\Bodø Industri fails like this
> AAAB SELECT "Presis\Bod Industri"
> AAAB NO SELECT failure, cannot select mailbox: Folder not found in IMAP name
> space
> And trying to select Presis\id filer fails like this
> AAAB SELECT "Presis\id filer"
> AAAB NO SELECT failure, cannot select mailbox: Folder not found in IMAP name
> space
> So far it seems like select fails when folder has more than one:
> * none US-ASCII
> * space
> * sub-folder separator
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (NET-614) IMAP fails to quote/encode mailbox names
Sebb created NET-614: Summary: IMAP fails to quote/encode mailbox names Key: NET-614 URL: https://issues.apache.org/jira/browse/NET-614 Project: Commons Net Issue Type: Bug Components: IMAP Reporter: Sebb Mailbox names need to be quoted if they contain spaces. If the contain non-ASCII characters then they also need to be encoded [1] There may be other parameters that are not being encoded/quoted correctly. [1] https://tools.ietf.org/html/rfc3501#section-5.1.3 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NET-601) IMAPClient.select cannot select mailbox in some cases with æøå, spaces and sub-folders
[
https://issues.apache.org/jira/browse/NET-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863883#comment-15863883
]
Sebb commented on NET-601:
--
I don't get the same problem when using IMAP with Yahoo. I've not tried
non-ASCII, but spaces in sub-folders work fine.
Likewise with GMail, though that is not true IMAP.
> IMAPClient.select cannot select mailbox in some cases with æøå, spaces and
> sub-folders
> --
>
> Key: NET-601
> URL: https://issues.apache.org/jira/browse/NET-601
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.5
> Environment: eclipse on ubuntu workstation and ibm domino server on
> ubuntu server. Connecting to IMAP on an IBM Domino server.
>Reporter: Johnny Haugen Sørgård
> Attachments: import_startssl_to_javahome.windows.zip,
> testCommonsNetIMAPselect.java
>
>
> Partial response from LIST:
> AAAB LIST "" "*"
> * LIST (\HasNoChildren) "\\" "Backup log"
> * LIST (\Noinferiors \HasNoChildren) "\\" Inbox
> * LIST (\HasNoChildren) "\\" M
> * LIST (\HasChildren) "\\" Presis
> * LIST (\HasNoChildren) "\\" {24}
> Presis\Bod Industri
> * LIST (\HasNoChildren) "\\" {11}
> Presis\Done
> * LIST (\HasNoChildren) "\\" {15}
> Presis\id filer
> Trying to select Presis\Bodø Industri fails like this
> AAAB SELECT "Presis\Bod Industri"
> AAAB NO SELECT failure, cannot select mailbox: Folder not found in IMAP name
> space
> And trying to select Presis\id filer fails like this
> AAAB SELECT "Presis\id filer"
> AAAB NO SELECT failure, cannot select mailbox: Folder not found in IMAP name
> space
> So far it seems like select fails when folder has more than one:
> * none US-ASCII
> * space
> * sub-folder separator
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (VFS-525) FtpFileObject.exists() output not impacted by refresh() after file deletion
[
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863803#comment-15863803
]
Henri Hagberg commented on VFS-525:
---
Same is happening in VFS 2.1 when checking file size
{code}
// Reports same size on first and subsequent calls even if size changes
file.refresh();
long size = file.getContent().getSize();
// Reports (changed) file size correctly
FileObject parent = file.getParent();
parent.getType();
parent.refresh();
file.refresh();
long size = file.getContent().getSize();
{code}
> FtpFileObject.exists() output not impacted by refresh() after file deletion
> ---
>
> Key: VFS-525
> URL: https://issues.apache.org/jira/browse/VFS-525
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Windows 7 [Version 6.1.7601]
> java version "1.6.0_31"
> Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
> Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)
> commonc vfs 2.0
> commons net 3.3
>Reporter: Volker Bergmann
>Priority: Critical
> Labels: FTP,, cache, exists
>
> Context: I store a file in an FTP directory and poll the FTP file (using
> FtpFileObject.exists()) until it is imported by another system and deleted on
> the FTP folder.
> Issue: On the first lookup, the file is present and FtpFileObject.exists()
> returns true correctly. That's OK, but after the file has been deleted,
> FtpFileObject.exists() continues to return true, even when using
> CacheStrategy.MANUAL and calling FtpFileObject.refresh().
> Observations: Upon refresh() there is a complex interaction between the file
> and parent folder object as well as the code of AbstractFileObject and
> FtpFileObject. The issue seems to stem from the fact that for the existence
> check of a file, its parent file object is queried for its #children
> attribute which caches the child entries. On the one hand, the child file
> seems to clear the link to the parent folder, causing a detach() of the
> parent, but since the parent folder already is in detached state, it does not
> clear its #children attribute.
> By the way: I consider it a poor inheritance design if a child class
> attribute
> FtpFileObject: private Map children
> shadows a parent class attribute
> AbstractFileObject: private FileName[] children
> At least it makes debugging more cumbersome.
> Workaround: The issue stems from the fact that the parent FtpFileObject is
> not cleared correctly because attached==false. Thus I use a call to the
> parent's getType() method which causes an attach() and, finally, attached==
> true and then call refresh() on the parent and the child:
> // This is a workaround for VFS 2.0's flaws in the
> // handling of attached/detached state and caching:
> FileObject parent = file.getParent();
> parent.getType(); // assure that parent folder is attached
> parent.refresh(); // detach parent folder and clear child object cache
> // (works only if attached before)
> // ...end of workaround
> file.refresh();
> System.out.println("File.exists(): {}", file.exists());
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NET-601) IMAPClient.select cannot select mailbox in some cases with æøå, spaces and sub-folders
[
https://issues.apache.org/jira/browse/NET-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863795#comment-15863795
]
Sebb commented on NET-601:
--
I can reproduce the problems.
There does not seem to be a sub-folder with a non-ascii name and with no space
- would it be possible to set one up?
> IMAPClient.select cannot select mailbox in some cases with æøå, spaces and
> sub-folders
> --
>
> Key: NET-601
> URL: https://issues.apache.org/jira/browse/NET-601
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.5
> Environment: eclipse on ubuntu workstation and ibm domino server on
> ubuntu server. Connecting to IMAP on an IBM Domino server.
>Reporter: Johnny Haugen Sørgård
> Attachments: import_startssl_to_javahome.windows.zip,
> testCommonsNetIMAPselect.java
>
>
> Partial response from LIST:
> AAAB LIST "" "*"
> * LIST (\HasNoChildren) "\\" "Backup log"
> * LIST (\Noinferiors \HasNoChildren) "\\" Inbox
> * LIST (\HasNoChildren) "\\" M
> * LIST (\HasChildren) "\\" Presis
> * LIST (\HasNoChildren) "\\" {24}
> Presis\Bod Industri
> * LIST (\HasNoChildren) "\\" {11}
> Presis\Done
> * LIST (\HasNoChildren) "\\" {15}
> Presis\id filer
> Trying to select Presis\Bodø Industri fails like this
> AAAB SELECT "Presis\Bod Industri"
> AAAB NO SELECT failure, cannot select mailbox: Folder not found in IMAP name
> space
> And trying to select Presis\id filer fails like this
> AAAB SELECT "Presis\id filer"
> AAAB NO SELECT failure, cannot select mailbox: Folder not found in IMAP name
> space
> So far it seems like select fails when folder has more than one:
> * none US-ASCII
> * space
> * sub-folder separator
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (NET-606) Thread hangs when invoke connect method
[
https://issues.apache.org/jira/browse/NET-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-606.
--
Resolution: Cannot Reproduce
Sorry, but we don't have the resources to investigate bugs in obsolete versions
of code.
If you can reproduce the issue with the current code, please re-open with full
details.
> Thread hangs when invoke connect method
> ---
>
> Key: NET-606
> URL: https://issues.apache.org/jira/browse/NET-606
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.2
>Reporter: zhengweixiong
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> ftp hangs when trying connect. stack as follows.
> {noformat}
> "UpdateBrowSerParam" #633 prio=5 os_prio=0 tid=0x7f60610cc000 nid=0x2165
> runnable [0x7f6037403000]
>java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:170)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
> at sun.security.ssl.InputRecord.read(InputRecord.java:503)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
> - locked <0x0006d44fdd70> (a java.lang.Object)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
> - locked <0x0006d44fdda0> (a java.lang.Object)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
> at
> org.apache.commons.net.ftp.FTPSClient.sslNegotiation(FTPSClient.java:263)
> at
> org.apache.commons.net.ftp.FTPSClient._connectAction_(FTPSClient.java:192)
> at org.apache.commons.net.SocketClient.connect(SocketClient.java:164)
> at org.apache.commons.net.SocketClient.connect(SocketClient.java:184)
> at
> com.swimap.prs.utils.ftp.FTPSTransfer.initFTPSClient(FTPSTransfer.java:96)
> at
> com.swimap.prs.utils.ftp.FTPSTransfer.initFtpsClient(FTPSTransfer.java:336)
> at com.swimap.prs.utils.ftp.FTPSTransfer.upload(FTPSTransfer.java:236)
> at
> com.swimap.prs.application.paimgr.session.impl.TransferFileService.uploadFile(TransferFileService.java:57)
> {noformat}
> this issue happen sometimes when the other times is ok.
> code as follows:
> {code}
> ftps = new FTPSClient("TLSv1.2", true);
> ftps.setConnectTimeout(1);
> ftps.setDataTimeout(2);
> ftps.setControlEncoding("UTF-8");
> ftps.connect(ftpServerInfo.getIp());
> ftps.setSoTimeout(2);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NET-601) IMAPClient.select cannot select mailbox in some cases with æøå, spaces and sub-folders
[
https://issues.apache.org/jira/browse/NET-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863687#comment-15863687
]
Sebb commented on NET-601:
--
Thanks, I have managed to login now.
I had to use Java 1.7 as well as add the cert (I added that locally, and
defined javax.net.ssl.trustStore as I don't want to change the default Java
store)
> IMAPClient.select cannot select mailbox in some cases with æøå, spaces and
> sub-folders
> --
>
> Key: NET-601
> URL: https://issues.apache.org/jira/browse/NET-601
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.5
> Environment: eclipse on ubuntu workstation and ibm domino server on
> ubuntu server. Connecting to IMAP on an IBM Domino server.
>Reporter: Johnny Haugen Sørgård
> Attachments: import_startssl_to_javahome.windows.zip,
> testCommonsNetIMAPselect.java
>
>
> Partial response from LIST:
> AAAB LIST "" "*"
> * LIST (\HasNoChildren) "\\" "Backup log"
> * LIST (\Noinferiors \HasNoChildren) "\\" Inbox
> * LIST (\HasNoChildren) "\\" M
> * LIST (\HasChildren) "\\" Presis
> * LIST (\HasNoChildren) "\\" {24}
> Presis\Bod Industri
> * LIST (\HasNoChildren) "\\" {11}
> Presis\Done
> * LIST (\HasNoChildren) "\\" {15}
> Presis\id filer
> Trying to select Presis\Bodø Industri fails like this
> AAAB SELECT "Presis\Bod Industri"
> AAAB NO SELECT failure, cannot select mailbox: Folder not found in IMAP name
> space
> And trying to select Presis\id filer fails like this
> AAAB SELECT "Presis\id filer"
> AAAB NO SELECT failure, cannot select mailbox: Folder not found in IMAP name
> space
> So far it seems like select fails when folder has more than one:
> * none US-ASCII
> * space
> * sub-folder separator
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CRYPTO-133) OpenSslCryptoRandomNative.nextRandBytes not thread safe
[
https://issues.apache.org/jira/browse/CRYPTO-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863642#comment-15863642
]
Sebb commented on CRYPTO-133:
-
If the Javadoc does not state that the code is thread-safe, then no assumptions
can be made about thread-safety.
> OpenSslCryptoRandomNative.nextRandBytes not thread safe
> ---
>
> Key: CRYPTO-133
> URL: https://issues.apache.org/jira/browse/CRYPTO-133
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Hendrik Saly
>
> Seems that AbstractRandomTest.testRandomBytesMultiThreaded is failing for
> OpenSslCryptoRandomNative.nextRandBytes.
> Testcase throws exceptions like
> {code}
> java.lang.IllegalArgumentException: The nextRandBytes method failed
> at
> org.apache.commons.crypto.random.OpenSslCryptoRandom.nextBytes(OpenSslCryptoRandom.java:108)
> at
> org.apache.commons.crypto.random.AbstractRandomTest.checkRandomBytes(AbstractRandomTest.java:94)
> at
> org.apache.commons.crypto.random.AbstractRandomTest.access$000(AbstractRandomTest.java:30)
> at
> org.apache.commons.crypto.random.AbstractRandomTest$1.run(AbstractRandomTest.java:63)
> {code}
> When adding a 'synchronized' modifier to
> OpenSslCryptoRandomNative.nextRandBytes it works.
> So IMHO there are two bugs that need to be resolved:
> 1) fix testcase AbstractRandomTest.testRandomBytesMultiThreaded in that way
> that it fails when exception are thrown
> 2) fix OpenSslCryptoRandomNative.nextRandBytes no be thread safe (of course
> not by adding 'synchronized', seems like locks_setup() is broken somehow in
> https://github.com/apache/commons-crypto/blob/master/src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c#L299
>
> The testcase can be fixed with something like this
> {code}
> @Test(timeout = 12)
> public void testRandomBytesMultiThreaded() throws Exception {
> final int threadCount = 100;
> final AtomicBoolean hasErrors = new AtomicBoolean();
> try (final CryptoRandom random = getCryptoRandom()) {
> final List threads = new ArrayList<>(threadCount);
> for (int i = 0; i < threadCount; i++) {
> Thread t = new Thread(new Runnable() {
> @Override
> public void run() {
> try {
>
> checkRandomBytes(random, 10);
>
> checkRandomBytes(random, 1000);
>
> checkRandomBytes(random, 10);
> } catch (Exception e) {
> hasErrors.set(true);
> e.printStackTrace();
> }
> }
> });
> t.start();
> threads.add(t);
> }
> for (Thread t : threads) {
> if (!t.getState().equals(State.NEW)) {
> t.join();
> }
> }
>
> if(hasErrors.get()) {
> Assert.fail();
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NET-477) TFTP sendFile retry broken
[ https://issues.apache.org/jira/browse/NET-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863636#comment-15863636 ] Sebb commented on NET-477: -- yes, see the dev list > TFTP sendFile retry broken > -- > > Key: NET-477 > URL: https://issues.apache.org/jira/browse/NET-477 > Project: Commons Net > Issue Type: Bug > Components: TFTP >Affects Versions: 3.1, 3.2 > Environment: Linux 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 > 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0_26" > Java(TM) SE Runtime Environment (build 1.6.0_26-b03) > Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) >Reporter: John Walton > Fix For: 3.6 > > > TFTPClient.java sendFile() method does not retry after initial timeout. > Between revisons 1088720 & 1229692 the 'continue' statements were changed to > 'continue _sendPacket'. After the initial timeout of bufferedReceive() these > cause the control to flow to the outer loop and never retry. If the control > did flow accordingly, the retry would loop indefinitely since the timeouts > variable is reset to zero each time as well. > I am using a workaround by calling bufferedSend(sent) just before continue, > in place of the 'continue _sendPacket' statement. > It looks as if similar logic was applied to the receiveFile() method as well. > Revision:1229692 > Time:01/10/2012 01:14 PM > Author:sebb > Path:http://svn.apache.org/repos/asf/commons/proper/net/trunk/src/main/java/org/apache/commons/net/tftp/TFTPClient.java > Message:NET-410 Apache Commons TFTP does not handle RFC 783 retransmits -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (VALIDATOR-313) The example doesn't work
[ https://issues.apache.org/jira/browse/VALIDATOR-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863630#comment-15863630 ] Sebb commented on VALIDATOR-313: OK. As I recall, the fix version is updated when the bug has been fixed so I removed it. I.e. fix version is actual version when fixed rather than when the fix is planned to be done. > The example doesn't work > > > Key: VALIDATOR-313 > URL: https://issues.apache.org/jira/browse/VALIDATOR-313 > Project: Commons Validator > Issue Type: Bug > Components: Framework >Affects Versions: 1.4.0 Release >Reporter: OblongZebra > > Exception in thread "main" org.apache.commons.validator.ValidatorException: > java.lang.ClassNotFoundException: org.apache.commons.validator.TestValidator > at > org.apache.commons.validator.ValidatorAction.loadValidationClass(ValidatorAction.java:626) > at > org.apache.commons.validator.ValidatorAction.executeValidationMethod(ValidatorAction.java:532) > at org.apache.commons.validator.Field.validateForRule(Field.java:831) > at org.apache.commons.validator.Field.validate(Field.java:911) > at org.apache.commons.validator.Form.validate(Form.java:290) > at org.apache.commons.validator.Validator.validate(Validator.java:353) > at > org.apache.commons.validator.example.ValidateExample.main(ValidateExample.java:103) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (VALIDATOR-313) The example doesn't work
[ https://issues.apache.org/jira/browse/VALIDATOR-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated VALIDATOR-313: --- Fix Version/s: (was: 1.7) > The example doesn't work > > > Key: VALIDATOR-313 > URL: https://issues.apache.org/jira/browse/VALIDATOR-313 > Project: Commons Validator > Issue Type: Bug > Components: Framework >Affects Versions: 1.4.0 Release >Reporter: OblongZebra > > Exception in thread "main" org.apache.commons.validator.ValidatorException: > java.lang.ClassNotFoundException: org.apache.commons.validator.TestValidator > at > org.apache.commons.validator.ValidatorAction.loadValidationClass(ValidatorAction.java:626) > at > org.apache.commons.validator.ValidatorAction.executeValidationMethod(ValidatorAction.java:532) > at org.apache.commons.validator.Field.validateForRule(Field.java:831) > at org.apache.commons.validator.Field.validate(Field.java:911) > at org.apache.commons.validator.Form.validate(Form.java:290) > at org.apache.commons.validator.Validator.validate(Validator.java:353) > at > org.apache.commons.validator.example.ValidateExample.main(ValidateExample.java:103) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CRYPTO-129) Change access of instance variables from package private to private (or protected if appropriate)
[ https://issues.apache.org/jira/browse/CRYPTO-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863582#comment-15863582 ] Sebb commented on CRYPTO-129: - See https://wiki.apache.org/commons/CodeStyle > Change access of instance variables from package private to private (or > protected if appropriate) > - > > Key: CRYPTO-129 > URL: https://issues.apache.org/jira/browse/CRYPTO-129 > Project: Commons Crypto > Issue Type: Bug >Affects Versions: 1.0.0 >Reporter: Gary Gregory >Assignee: Jianguo Tian > Fix For: 1.1.0 > > > Change access of instance variables from package private to private (or > protected if appropriate). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (CRYPTO-129) Change access of instance variables from package private to private (or protected if appropriate)
[ https://issues.apache.org/jira/browse/CRYPTO-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb reopened CRYPTO-129: - Protected fields should be avoided if possible. Once exposed as part of the API, that constrains future development. For example, if a protected field needs to be changed from an int to a long, that cannot be done without breaking the API. Or if the code is changed and no longer needs the field, it still has to be maintained or the functionality may be broken. And protected mutable fields should never be used in new code. It's impossible to ensure thread-safety if there are any exposed mutable fields. So for example only empty arrays can ever be safely exposed. Only constants should be exposed, and only if they really are constants that will never change. Otherwise one can run into problems with constant embedding - the Java compiler can take copies of constants from one class to another. > Change access of instance variables from package private to private (or > protected if appropriate) > - > > Key: CRYPTO-129 > URL: https://issues.apache.org/jira/browse/CRYPTO-129 > Project: Commons Crypto > Issue Type: Bug >Affects Versions: 1.0.0 >Reporter: Gary Gregory >Assignee: Jianguo Tian > Fix For: 1.1.0 > > > Change access of instance variables from package private to private (or > protected if appropriate). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (VALIDATOR-313) The example doesn't work
[ https://issues.apache.org/jira/browse/VALIDATOR-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated VALIDATOR-313: -- Fix Version/s: (was: 1.6) 1.7 > The example doesn't work > > > Key: VALIDATOR-313 > URL: https://issues.apache.org/jira/browse/VALIDATOR-313 > Project: Commons Validator > Issue Type: Bug > Components: Framework >Affects Versions: 1.4.0 Release >Reporter: OblongZebra > Fix For: 1.7 > > > Exception in thread "main" org.apache.commons.validator.ValidatorException: > java.lang.ClassNotFoundException: org.apache.commons.validator.TestValidator > at > org.apache.commons.validator.ValidatorAction.loadValidationClass(ValidatorAction.java:626) > at > org.apache.commons.validator.ValidatorAction.executeValidationMethod(ValidatorAction.java:532) > at org.apache.commons.validator.Field.validateForRule(Field.java:831) > at org.apache.commons.validator.Field.validate(Field.java:911) > at org.apache.commons.validator.Form.validate(Form.java:290) > at org.apache.commons.validator.Validator.validate(Validator.java:353) > at > org.apache.commons.validator.example.ValidateExample.main(ValidateExample.java:103) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (VALIDATOR-415) Simplify building new CreditCard validators
[ https://issues.apache.org/jira/browse/VALIDATOR-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved VALIDATOR-415. Resolution: Fixed URL: http://svn.apache.org/viewvc?rev=1782740=rev Log: VALIDATOR-415 Extend syntax to allow disjoint lengths Modified: commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/CreditCardValidator.java commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/CreditCardValidatorTest.java > Simplify building new CreditCard validators > --- > > Key: VALIDATOR-415 > URL: https://issues.apache.org/jira/browse/VALIDATOR-415 > Project: Commons Validator > Issue Type: New Feature >Reporter: Sebb > Fix For: 1.6 > > > Credit card validators currently rely on regexes. > Whilst these are flexible enough for the purpose, it is difficult to define > the REs and hard to read them. > It would be simpler if the user could provide the prefix ranges and lengths, > for example: > Amex: "34", length 15 > Discover: "644" -> "65", length 16 > (both the above have other ranges which would need to be provided separately) > This can then be converted internally into the appropriate validation > routines. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (VALIDATOR-313) The example doesn't work
[ https://issues.apache.org/jira/browse/VALIDATOR-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863335#comment-15863335 ] Benedikt Ritter commented on VALIDATOR-313: --- [~s...@apache.org] I don't think we have to fix this for 1.6 Moving this to 1.7. Maybe we should consider making Validator a multi-module project in order to get the example to work. > The example doesn't work > > > Key: VALIDATOR-313 > URL: https://issues.apache.org/jira/browse/VALIDATOR-313 > Project: Commons Validator > Issue Type: Bug > Components: Framework >Affects Versions: 1.4.0 Release >Reporter: OblongZebra > Fix For: 1.7 > > > Exception in thread "main" org.apache.commons.validator.ValidatorException: > java.lang.ClassNotFoundException: org.apache.commons.validator.TestValidator > at > org.apache.commons.validator.ValidatorAction.loadValidationClass(ValidatorAction.java:626) > at > org.apache.commons.validator.ValidatorAction.executeValidationMethod(ValidatorAction.java:532) > at org.apache.commons.validator.Field.validateForRule(Field.java:831) > at org.apache.commons.validator.Field.validate(Field.java:911) > at org.apache.commons.validator.Form.validate(Form.java:290) > at org.apache.commons.validator.Validator.validate(Validator.java:353) > at > org.apache.commons.validator.example.ValidateExample.main(ValidateExample.java:103) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (VALIDATOR-417) TimeValidator/CalendarValidator common validate code could be pushed up
[ https://issues.apache.org/jira/browse/VALIDATOR-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863553#comment-15863553 ] Sebb commented on VALIDATOR-417: There is a similar set of validate routines in DateValidator, however these return a Date rather than a Calendar so cannot be shared. This means that TimeValidator and CalendarValidator would need their own separate parent class > TimeValidator/CalendarValidator common validate code could be pushed up > --- > > Key: VALIDATOR-417 > URL: https://issues.apache.org/jira/browse/VALIDATOR-417 > Project: Commons Validator > Issue Type: Improvement >Reporter: Sebb > > The TimeValidator and CalendarValidator classes have identical validate > methods. > These could be pushed up into a common superclass. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (VALIDATOR-415) Simplify building new CreditCard validators
[ https://issues.apache.org/jira/browse/VALIDATOR-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb reopened VALIDATOR-415: Some cards use disjoint ranges, so it would be useful to support that. > Simplify building new CreditCard validators > --- > > Key: VALIDATOR-415 > URL: https://issues.apache.org/jira/browse/VALIDATOR-415 > Project: Commons Validator > Issue Type: New Feature >Reporter: Sebb > Fix For: 1.6 > > > Credit card validators currently rely on regexes. > Whilst these are flexible enough for the purpose, it is difficult to define > the REs and hard to read them. > It would be simpler if the user could provide the prefix ranges and lengths, > for example: > Amex: "34", length 15 > Discover: "644" -> "65", length 16 > (both the above have other ranges which would need to be provided separately) > This can then be converted internally into the appropriate validation > routines. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (VALIDATOR-417) TimeValidator/CalendarValidator common validate code could be pushed up
Sebb created VALIDATOR-417: -- Summary: TimeValidator/CalendarValidator common validate code could be pushed up Key: VALIDATOR-417 URL: https://issues.apache.org/jira/browse/VALIDATOR-417 Project: Commons Validator Issue Type: Improvement Reporter: Sebb The TimeValidator and CalendarValidator classes have identical validate methods. These could be pushed up into a common superclass. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NET-477) TFTP sendFile retry broken
[ https://issues.apache.org/jira/browse/NET-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863276#comment-15863276 ] Niranjana Mai TM commented on NET-477: -- Thank you, is there a tentative release date/month for the new 3.6 jar release > TFTP sendFile retry broken > -- > > Key: NET-477 > URL: https://issues.apache.org/jira/browse/NET-477 > Project: Commons Net > Issue Type: Bug > Components: TFTP >Affects Versions: 3.1, 3.2 > Environment: Linux 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 > 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0_26" > Java(TM) SE Runtime Environment (build 1.6.0_26-b03) > Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) >Reporter: John Walton > Fix For: 3.6 > > > TFTPClient.java sendFile() method does not retry after initial timeout. > Between revisons 1088720 & 1229692 the 'continue' statements were changed to > 'continue _sendPacket'. After the initial timeout of bufferedReceive() these > cause the control to flow to the outer loop and never retry. If the control > did flow accordingly, the retry would loop indefinitely since the timeouts > variable is reset to zero each time as well. > I am using a workaround by calling bufferedSend(sent) just before continue, > in place of the 'continue _sendPacket' statement. > It looks as if similar logic was applied to the receiveFile() method as well. > Revision:1229692 > Time:01/10/2012 01:14 PM > Author:sebb > Path:http://svn.apache.org/repos/asf/commons/proper/net/trunk/src/main/java/org/apache/commons/net/tftp/TFTPClient.java > Message:NET-410 Apache Commons TFTP does not handle RFC 783 retransmits -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/231 Gotcha, found this example https://github.com/Tomschi/jacob-parent/blob/ec3f1c10169c26f14ee1f61bd6622c67a73e26fc/jacob/src/main/java/com/jacob/com/LibraryLoader.java#L202 Looks like a valid use case. I'm all right with merging it, my +0. Let's now wait to see what others think about it. Thanks! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user Tomschi commented on the issue: https://github.com/apache/commons-lang/pull/231 I'am using it for the jacob-project. There i have to know, if it is a 32 or 64 bit architecture to load the correct dll library. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
