[ https://issues.apache.org/jira/browse/MATH-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786250#action_12786250
]
Jake Mannix commented on MATH-321:
----------------------------------
I'm in the process of porting my sparse SVD work from decomposer (http://decomposer.googlecode.com)
to Apache Mahout (see ticket MAHOUT-180 on the mahout JIRA), which has both non-parallized
stream-based sparse SVD (using the generalized hebbian algorithm) as well as Hadoopified Lanczos
and probabalistic partial decomposition. These are designed to scale to tens of millions
of dimensions (the GHA version), and to billions of dimensions or more (in the Hadoopified
version - add more machines to your Hadoop cluster, and you can go higher!).
> Support for Sparse (Thin) SVD
> -----------------------------
>
> Key: MATH-321
> URL: https://issues.apache.org/jira/browse/MATH-321
> Project: Commons Math
> Issue Type: New Feature
> Reporter: David Jurgens
>
> Current the SingularValueDecomposition implementation computes the full SVD. However,
for some applications, e.g. LSA, vision applications, only the most significant singular values
are needed. For these applications, the full decomposition is impractical, and for large
matrices, computationally infeasible. The sparse SVD avoids computing the unnecessary data,
and more importantly, has significantly lower computational complexity, which allows it to
scale to larger matrices.
> Other linear algebra implementation have support for the sparse svd. Both Matlab and
Octave have the svds function. C has SVDLIBC. SVDPACK is also available in Fortran and C.
However, after extensive searching, I do not believe there is any existing Java-based sparse
SVD implementation. This added functionality would be widely used for any pure Java application
that requires a sparse SVD, as the only current solution is to call out to a library in another
language.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Support for Sparse (Thin) SVD
-----------------------------
Key: MATH-321
URL: https://issues.apache.org/jira/browse/MATH-321
Project: Commons Math
Issue Type: New Feature
Reporter: David Jurgens
Current the SingularValueDecomposition implementation computes the full SVD. However, for
some applications, e.g. LSA, vision applications, only the most significant singular values
are needed. For these applications, the full decomposition is impractical, and for large
matrices, computationally infeasible. The sparse SVD avoids computing the unnecessary data,
and more importantly, has significantly lower computational complexity, which allows it to
scale to larger matrices.
Other linear algebra implementation have support for the sparse svd. Both Matlab and Octave
have the svds function. C has SVDLIBC. SVDPACK is also available in Fortran and C. However,
after extensive searching, I do not believe there is any existing Java-based sparse SVD implementation.
This added functionality would be widely used for any pure Java application that requires
a sparse SVD, as the only current solution is to call out to a library in another language.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CODEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786172#action_12786172
]
Adam Rabung commented on CODEC-95:
----------------------------------
Doh, my patch should have been 1.5 compatible (not chaining IOException), and DefaultIllegalEncodingCharacterPolicy
should allow ASCII 13 and 10.
> Base64: optionally allow strict parsing of base64 strings
> ---------------------------------------------------------
>
> Key: CODEC-95
> URL: https://issues.apache.org/jira/browse/CODEC-95
> Project: Commons Codec
> Issue Type: Improvement
> Affects Versions: 1.4
> Reporter: Adam Rabung
> Priority: Minor
> Attachments: strictMode.zip
>
>
> Currently, Codec skips base64 characters that are outside of the encode table. I realize
this is perfectly to spec, but I wonder if other users might appreciate a "strict" mode that
throws an exception when one of these illegal characters are encountered. For example, I
would love an exception to be thrown here:
> new Base64().decode("!@#$ iHaveIllegalCharsAtBeginningAndEnd %^&"));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CODEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Rabung updated CODEC-95:
-----------------------------
Attachment: strictMode.zip
Not sure how much this will really help, as I don't know much about the base 64 spec or Apache
coding guidelines (adding checked exceptions to existing methods?), but it's a start.
> Base64: optionally allow strict parsing of base64 strings
> ---------------------------------------------------------
>
> Key: CODEC-95
> URL: https://issues.apache.org/jira/browse/CODEC-95
> Project: Commons Codec
> Issue Type: Improvement
> Affects Versions: 1.4
> Reporter: Adam Rabung
> Priority: Minor
> Attachments: strictMode.zip
>
>
> Currently, Codec skips base64 characters that are outside of the encode table. I realize
this is perfectly to spec, but I wonder if other users might appreciate a "strict" mode that
throws an exception when one of these illegal characters are encountered. For example, I
would love an exception to be thrown here:
> new Base64().decode("!@#$ iHaveIllegalCharsAtBeginningAndEnd %^&"));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Base64: optionally allow strict parsing of base64 strings
---------------------------------------------------------
Key: CODEC-95
URL: https://issues.apache.org/jira/browse/CODEC-95
Project: Commons Codec
Issue Type: Improvement
Affects Versions: 1.4
Reporter: Adam Rabung
Priority: Minor
Attachments: strictMode.zip
Currently, Codec skips base64 characters that are outside of the encode table. I realize
this is perfectly to spec, but I wonder if other users might appreciate a "strict" mode that
throws an exception when one of these illegal characters are encountered. For example, I
would love an exception to be thrown here:
new Base64().decode("!@#$ iHaveIllegalCharsAtBeginningAndEnd %^&"));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
FTP: FTPFileEntryParser API samples are wrong
---------------------------------------------
Key: NET-303
URL: https://issues.apache.org/jira/browse/NET-303
Project: Commons Net
Issue Type: Bug
Reporter: Jürgen Weber
The samples in the FTPFileEntryParser API doc use non-existent methods
FTPClient.createFileList(directory, parser);
FTPClient.FTPFile[] files = f.listFiles(parser, ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/NET-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jürgen Weber updated NET-302:
-----------------------------
Summary: FTP: initiateListParsing should not cache entryParser (was: initiateListParsing
should not cache entryParser)
> FTP: initiateListParsing should not cache entryParser
> -----------------------------------------------------
>
> Key: NET-302
> URL: https://issues.apache.org/jira/browse/NET-302
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 2.0
> Environment: z/OS based ftp server
> Reporter: Jürgen Weber
>
> if you use initiateListParsing with a FTPFileEntryParser this code can fail:
> FTPClient.listFiles()
> ftp.initiateListParsing(parserKey, ...
> It seems that the listFiles() already set a parser, that gets cached and the parser in
the initiateListParsing gets ignored.
> For z/OS you can use ftp for file transfer and for submitting jobs, in the second case
you'd want another parser than for the first call.
> c.f. http://www.ibm.com/developerworks/systems/library/es-zosbatchjavav/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
initiateListParsing should not cache entryParser
------------------------------------------------
Key: NET-302
URL: https://issues.apache.org/jira/browse/NET-302
Project: Commons Net
Issue Type: Bug
Affects Versions: 2.0
Environment: z/OS based ftp server
Reporter: Jürgen Weber
if you use initiateListParsing with a FTPFileEntryParser this code can fail:
FTPClient.listFiles()
ftp.initiateListParsing(parserKey, ...
It seems that the listFiles() already set a parser, that gets cached and the parser in the
initiateListParsing gets ignored.
For z/OS you can use ftp for file transfer and for submitting jobs, in the second case you'd
want another parser than for the first call.
c.f. http://www.ibm.com/developerworks/systems/library/es-zosbatchjavav/index.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CODEC-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785630#action_12785630
]
Lorenzo Ingrillì commented on CODEC-94:
---------------------------------------
Static method Base64.encodeBase64() seems work correctly, so now i'm using it instead the
instance method encode()
this code work as expected:
{code:title=Test2.java}
import org.apache.commons.codec.binary.Base64;
public class Test2 {
public static void main(String args[]) throws Exception {
byte[] input = new byte[] {
25, 109, -39, -23, 82, -47, -88, 115,
-34, 126, -57, 16, -110, -110, 60, -7,
-123, -3, 60, 91, 112, -93, -67, -65, -71,
-107, 123, -15, -106, 86, -80, 79
};
// wrong behaviour:
// Base64 b64 = new Base64(64);
// String output = new String(b64.encode(input));
// correct behaviour:
String output = new String(Base64.encodeBase64(input));
System.out.println("*"+output+"*");
}
}
{code}
> unexpected CRLF at end of base64 encoded string
> -----------------------------------------------
>
> Key: CODEC-94
> URL: https://issues.apache.org/jira/browse/CODEC-94
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.4
> Environment: java 1.6u17
> ubuntu linux 9.10
> Reporter: Lorenzo Ingrillì
>
> Sometimes, a base64 encoded string ends inappropriately with \r\n characters.
> In the example below, i used value 64 as line lenght and the generated base64 string
lenght was 44; nevertheless string ends with CRLF .
> (i think, this bug is not related to bug #CODEC-89)
> How to reproduce:
> {code:title=Test.java|borderStyle=solid}
> public class Test {
> public static void main(String args[]) throws Exception {
> byte[] input = new byte[] {
> 25, 109, -39, -23, 82, -47, -88, 115,
> -34, 126, -57, 16, -110, -110, 60, -7,
> -123, -3, 60, 91, 112, -93, -67, -65, -71,
> -107, 123, -15, -106, 86, -80, 79
> };
> Base64 b64 = new Base64(64);
> String output = new String(b64.encode(input));
> System.out.println("*"+output+"*");
> }
> }
> {code}
> the output was: GW3Z6VLRqHPefscQkpI8+YX9PFtwo72/uZV78ZZWsE8=\r\n
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/COMMONSSITE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated COMMONSSITE-46:
---------------------------------------
Attachment: commons-parent-pom.patch
> Multi-module projects fail when using the "rc" profile in commons-parent
> ------------------------------------------------------------------------
>
> Key: COMMONSSITE-46
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-46
> Project: Commons All
> Issue Type: Bug
> Components: Commons Parent Pom
> Reporter: Niall Pemberton
> Attachments: commons-parent-pom.patch
>
>
> The "rc" profile doesn't current work with multi-module projects (when the project has
not been previously installed in your local repo for the current version)
> For example running the following command on JCI
> {code}
> mvn -Prc clean install
> {code}
> fails with the following error:
> {code}
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: Missing:
> ----------
> 1) org.apache.commons:commons-jci-core:jar:1.1-SNAPSHOT
> ...
> {code}
> I found this is caused by trying to run the site plugin in the "rc" profile:
> {code}
> <plugin>
> <artifactId>maven-site-plugin</artifactId>
> <executions>
> <execution>
> <goals>
> <goal>site</goal>
> </goals>
> <phase>package</phase>
> </execution>
> </executions>
> </plugin>
> {code}
> The intention of the above was so that when the assembly plugin ran to create the binary
distros then the site would be available to include in the distro. AFAIK we are now only shipping
javadocs in the binary distros and not any component sites. So I plan to remove the site plugin
from the "rc" profile and add a "javadoc" goal in the javadoc plugin in the "rc" profile.
This resolves the issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Multi-module projects fail when using the "rc" profile in commons-parent
------------------------------------------------------------------------
Key: COMMONSSITE-46
URL: https://issues.apache.org/jira/browse/COMMONSSITE-46
Project: Commons All
Issue Type: Bug
Components: Commons Parent Pom
Reporter: Niall Pemberton
The "rc" profile doesn't current work with multi-module projects (when the project has not
been previously installed in your local repo for the current version)
For example running the following command on JCI
{code}
mvn -Prc clean install
{code}
fails with the following error:
{code}
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error during page generation
Embedded error: Error rendering Maven report: Missing:
----------
1) org.apache.commons:commons-jci-core:jar:1.1-SNAPSHOT
...
{code}
I found this is caused by trying to run the site plugin in the "rc" profile:
{code}
<plugin>
<artifactId>maven-site-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>site</goal>
</goals>
<phase>package</phase>
</execution>
</executions>
</plugin>
{code}
The intention of the above was so that when the assembly plugin ran to create the binary distros
then the site would be available to include in the distro. AFAIK we are now only shipping
javadocs in the binary distros and not any component sites. So I plan to remove the site plugin
from the "rc" profile and add a "javadoc" goal in the javadoc plugin in the "rc" profile.
This resolves the issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/COMPRESS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785575#action_12785575
]
Christian Grobmeier commented on COMPRESS-92:
---------------------------------------------
Until now compress was meant for working with java prior version 5.
> ZipFile.getEntries() should be generified.
> ------------------------------------------
>
> Key: COMPRESS-92
> URL: https://issues.apache.org/jira/browse/COMPRESS-92
> Project: Commons Compress
> Issue Type: Improvement
> Affects Versions: 1.0
> Reporter: Sean Cote
> Priority: Minor
>
> Right now, ZipFile.getEntries() simply returns Enumeration, but it should return Enumeration<?
extends ZipArchiveEntry> so that callers don't have to cast the results, much like java.util.zip.ZipFile.entries().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/IO-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785562#action_12785562
]
Paul Benedict commented on IO-224:
----------------------------------
Great idea, Sean. The other methods could then be deprecated in 1.5. (The others shouldn't
be removed until a 2.0 release because it would break binary compatibility.)
> IOUtils.closeQuietly() should take a Closeable as a parameter.
> --------------------------------------------------------------
>
> Key: IO-224
> URL: https://issues.apache.org/jira/browse/IO-224
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
> Affects Versions: 1.4
> Reporter: Sean Cote
> Priority: Minor
>
> Right now, there are several IOUtils.closeQuietly methods that take things like InputStream,
OutputStream, Reader, Writer, but why not simply have one IOUtils.closeQuietly method which
takes a Closeable? It seems like this would simplify things and also enhance the usability
of the function.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CODEC-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785557#action_12785557
]
Julius Davies commented on CODEC-94:
------------------------------------
Just making sure this isn't a regression. Here's what I found:
- The only way to chunk the encoding in commons-codec-1.3 is via this static method:
{code}
// 76 character chunking is hard-coded.
// 64 character chunking is not possible!
Base64.encodeBase64Chunked( byte[] data );
{code}
- commons-codec-1.3 appends a final CRLF no matter what when using "chunked" mode:
[YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==
]
[YWFhYWFhYWFhYQ==
]
[YQ==
]
Question for Lorenzo: how would you feel about just calling new String().trim() yourself?
A direct byte[] trim is also possible. Involves some System.arraycopy(). Maybe commons-codec
could even offer up such a method ( bytesTrim() ).
> unexpected CRLF at end of base64 encoded string
> -----------------------------------------------
>
> Key: CODEC-94
> URL: https://issues.apache.org/jira/browse/CODEC-94
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.4
> Environment: java 1.6u17
> ubuntu linux 9.10
> Reporter: Lorenzo Ingrillì
>
> Sometimes, a base64 encoded string ends inappropriately with \r\n characters.
> In the example below, i used value 64 as line lenght and the generated base64 string
lenght was 44; nevertheless string ends with CRLF .
> (i think, this bug is not related to bug #CODEC-89)
> How to reproduce:
> {code:title=Test.java|borderStyle=solid}
> public class Test {
> public static void main(String args[]) throws Exception {
> byte[] input = new byte[] {
> 25, 109, -39, -23, 82, -47, -88, 115,
> -34, 126, -57, 16, -110, -110, 60, -7,
> -123, -3, 60, 91, 112, -93, -67, -65, -71,
> -107, 123, -15, -106, 86, -80, 79
> };
> Base64 b64 = new Base64(64);
> String output = new String(b64.encode(input));
> System.out.println("*"+output+"*");
> }
> }
> {code}
> the output was: GW3Z6VLRqHPefscQkpI8+YX9PFtwo72/uZV78ZZWsE8=\r\n
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CODEC-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785558#action_12785558
]
Julius Davies commented on CODEC-94:
------------------------------------
ps. Julius Davies is very relieved that this isn't yet another regression! Whew! Yay for
commons-codec-1.3 appending CRLF !
> unexpected CRLF at end of base64 encoded string
> -----------------------------------------------
>
> Key: CODEC-94
> URL: https://issues.apache.org/jira/browse/CODEC-94
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.4
> Environment: java 1.6u17
> ubuntu linux 9.10
> Reporter: Lorenzo Ingrillì
>
> Sometimes, a base64 encoded string ends inappropriately with \r\n characters.
> In the example below, i used value 64 as line lenght and the generated base64 string
lenght was 44; nevertheless string ends with CRLF .
> (i think, this bug is not related to bug #CODEC-89)
> How to reproduce:
> {code:title=Test.java|borderStyle=solid}
> public class Test {
> public static void main(String args[]) throws Exception {
> byte[] input = new byte[] {
> 25, 109, -39, -23, 82, -47, -88, 115,
> -34, 126, -57, 16, -110, -110, 60, -7,
> -123, -3, 60, 91, 112, -93, -67, -65, -71,
> -107, 123, -15, -106, 86, -80, 79
> };
> Base64 b64 = new Base64(64);
> String output = new String(b64.encode(input));
> System.out.println("*"+output+"*");
> }
> }
> {code}
> the output was: GW3Z6VLRqHPefscQkpI8+YX9PFtwo72/uZV78ZZWsE8=\r\n
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
IOUtils.closeQuietly() should take a Closeable as a parameter.
--------------------------------------------------------------
Key: IO-224
URL: https://issues.apache.org/jira/browse/IO-224
Project: Commons IO
Issue Type: Improvement
Components: Utilities
Affects Versions: 1.4
Reporter: Sean Cote
Priority: Minor
Right now, there are several IOUtils.closeQuietly methods that take things like InputStream,
OutputStream, Reader, Writer, but why not simply have one IOUtils.closeQuietly method which
takes a Closeable? It seems like this would simplify things and also enhance the usability
of the function.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
ZipFile.getEntries() should be generified.
------------------------------------------
Key: COMPRESS-92
URL: https://issues.apache.org/jira/browse/COMPRESS-92
Project: Commons Compress
Issue Type: Improvement
Affects Versions: 1.0
Reporter: Sean Cote
Priority: Minor
Right now, ZipFile.getEntries() simply returns Enumeration, but it should return Enumeration<?
extends ZipArchiveEntry> so that callers don't have to cast the results, much like java.util.zip.ZipFile.entries().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CODEC-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785438#action_12785438
]
Gary Gregory commented on CODEC-88:
-----------------------------------
The code comment talk about licenses that are not Apache 2.0, so I am not sure if we can use
this as is.
If you want this feature included, we need help with:
- The code must be submitted under the Apache 2.0 license.
- The code must fit in the Commons Codec style/framework/interfaces.
- The code must have unit tests.
> Base32 encoder
> --------------
>
> Key: CODEC-88
> URL: https://issues.apache.org/jira/browse/CODEC-88
> Project: Commons Codec
> Issue Type: New Feature
> Affects Versions: 1.x
> Reporter: Eric Olander
> Priority: Minor
> Attachments: Base32.java
>
>
> Any chance of getting Base32 encoding support along the lines of the existing Base64
encoder?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CODEC-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenzo Ingrillì updated CODEC-94:
----------------------------------
Description:
Sometimes, a base64 encoded string ends inappropriately with \r\n characters.
In the example below, i used value 64 as line lenght and the generated base64 string lenght
was 44; nevertheless string ends with CRLF .
(i think, this bug is not related to bug #CODEC-89)
How to reproduce:
{code:title=Test.java|borderStyle=solid}
public class Test {
public static void main(String args[]) throws Exception {
byte[] input = new byte[] {
25, 109, -39, -23, 82, -47, -88, 115,
-34, 126, -57, 16, -110, -110, 60, -7,
-123, -3, 60, 91, 112, -93, -67, -65, -71,
-107, 123, -15, -106, 86, -80, 79
};
Base64 b64 = new Base64(64);
String output = new String(b64.encode(input));
System.out.println("*"+output+"*");
}
}
{code}
the output was: GW3Z6VLRqHPefscQkpI8+YX9PFtwo72/uZV78ZZWsE8=\r\n
was:
Sometimes, a base64 encoded string ends inappropriately with \r\n characters.
In the example below, i used value 64 as line lenght and the generated base64 string lenght
was 44; nevertheless string ends with CRLF .
(i think, this bug is not related to bug #CODEC-89)
How to reproduce:
public class Test {
public static void main(String args[]) throws Exception {
byte[] input = new byte[] {
25, 109, -39, -23, 82, -47, -88, 115,
-34, 126, -57, 16, -110, -110, 60, -7,
-123, -3, 60, 91, 112, -93, -67, -65, -71,
-107, 123, -15, -106, 86, -80, 79
};
Base64 b64 = new Base64(64);
String output = new String(b64.encode(input));
System.out.println("*"+output+"*");
}
}
the output was: GW3Z6VLRqHPefscQkpI8+YX9PFtwo72/uZV78ZZWsE8=\r\n
> unexpected CRLF at end of base64 encoded string
> -----------------------------------------------
>
> Key: CODEC-94
> URL: https://issues.apache.org/jira/browse/CODEC-94
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.4
> Environment: java 1.6u17
> ubuntu linux 9.10
> Reporter: Lorenzo Ingrillì
>
> Sometimes, a base64 encoded string ends inappropriately with \r\n characters.
> In the example below, i used value 64 as line lenght and the generated base64 string
lenght was 44; nevertheless string ends with CRLF .
> (i think, this bug is not related to bug #CODEC-89)
> How to reproduce:
> {code:title=Test.java|borderStyle=solid}
> public class Test {
> public static void main(String args[]) throws Exception {
> byte[] input = new byte[] {
> 25, 109, -39, -23, 82, -47, -88, 115,
> -34, 126, -57, 16, -110, -110, 60, -7,
> -123, -3, 60, 91, 112, -93, -67, -65, -71,
> -107, 123, -15, -106, 86, -80, 79
> };
> Base64 b64 = new Base64(64);
> String output = new String(b64.encode(input));
> System.out.println("*"+output+"*");
> }
> }
> {code}
> the output was: GW3Z6VLRqHPefscQkpI8+YX9PFtwo72/uZV78ZZWsE8=\r\n
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
unexpected CRLF at end of base64 encoded string
-----------------------------------------------
Key: CODEC-94
URL: https://issues.apache.org/jira/browse/CODEC-94
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Environment: java 1.6u17
ubuntu linux 9.10
Reporter: Lorenzo Ingrillì
Sometimes, a base64 encoded string ends inappropriately with \r\n characters.
In the example below, i used value 64 as line lenght and the generated base64 string lenght
was 44; nevertheless string ends with CRLF .
(i think, this bug is not related to bug #CODEC-89)
How to reproduce:
public class Test {
public static void main(String args[]) throws Exception {
byte[] input = new byte[] {
25, 109, -39, -23, 82, -47, -88, 115,
-34, 126, -57, 16, -110, -110, 60, -7,
-123, -3, 60, 91, 112, -93, -67, -65, -71,
-107, 123, -15, -106, 86, -80, 79
};
Base64 b64 = new Base64(64);
String output = new String(b64.encode(input));
System.out.println("*"+output+"*");
}
}
the output was: GW3Z6VLRqHPefscQkpI8+YX9PFtwo72/uZV78ZZWsE8=\r\n
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CODEC-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Olander updated CODEC-88:
------------------------------
Attachment: Base32.java
This is code I ended up using - not sure about licensing issues for just including it as is
into commons-codec.
> Base32 encoder
> --------------
>
> Key: CODEC-88
> URL: https://issues.apache.org/jira/browse/CODEC-88
> Project: Commons Codec
> Issue Type: New Feature
> Affects Versions: 1.x
> Reporter: Eric Olander
> Priority: Minor
> Attachments: Base32.java
>
>
> Any chance of getting Base32 encoding support along the lines of the existing Base64
encoder?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CODEC-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated CODEC-89:
----------------------
Attachment: Base64.patch
Minimal patch to revert null ctor to 1.3 behaviour.
Note that the tests all still work, so clearly the tests are inadequate.
In fact the tests still work even if the IO Stream files are not patched.
> new Base64().encode() appends a CRLF, and chunks results into 76 character lines
> --------------------------------------------------------------------------------
>
> Key: CODEC-89
> URL: https://issues.apache.org/jira/browse/CODEC-89
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.4
> Reporter: Julius Davies
> Attachments: Base64.patch, codec-89.patch
>
>
> The instance encode() method (e.g. new Base64().encode()) appends a CRLF. Actually it's
fully chunking the output into 76 character lines. Commons-Codec-1.3 did not do this. The
static Base64.encodeBase64() method behaves the same in both 1.3 and 1.4, so this problem
only affects the instance encode() method.
> {code}
> import org.apache.commons.codec.binary.*;
> public class B64 {
> public static void main(String[] args) throws Exception {
> Base64 b64 = new Base64();
> String s1 = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
> String s2 = "aaaaaaaaaa";
> String s3 = "a";
>
> byte[] b1 = s1.getBytes("UTF-8");
> byte[] b2 = s2.getBytes("UTF-8");
> byte[] b3 = s3.getBytes("UTF-8");
> byte[] result;
> result = Base64.encodeBase64(b1);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b1);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = Base64.encodeBase64(b2);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b2);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = Base64.encodeBase64(b3);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b3);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> }
> }
> {code}
> Here's my output:
> {noformat}
> $ java -cp commons-codec-1.3.jar:. B64
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==]
> [YQ==]
> [YQ==]
> $ java -cp commons-codec-1.4.jar:. B64
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
> YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==
> ]
> [YWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==
> ]
> [YQ==]
> [YQ==
> ]
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CODEC-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785116#action_12785116
]
Sebb commented on CODEC-89:
---------------------------
Having second thoughts - although the patch looks OK, it actually changes the behaviour of
*two* constructors:
public Base64()
public Base64(boolean urlSafe)
Since the second ctor is @since 1.4, there is no need to - and therefore we should not - change
its behaviour.
The simplest fix is to change the null ctor to call this(0), and change any code that calls
the null ctor to call Base64(false) instead.
Patch to follow.
> new Base64().encode() appends a CRLF, and chunks results into 76 character lines
> --------------------------------------------------------------------------------
>
> Key: CODEC-89
> URL: https://issues.apache.org/jira/browse/CODEC-89
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.4
> Reporter: Julius Davies
> Attachments: codec-89.patch
>
>
> The instance encode() method (e.g. new Base64().encode()) appends a CRLF. Actually it's
fully chunking the output into 76 character lines. Commons-Codec-1.3 did not do this. The
static Base64.encodeBase64() method behaves the same in both 1.3 and 1.4, so this problem
only affects the instance encode() method.
> {code}
> import org.apache.commons.codec.binary.*;
> public class B64 {
> public static void main(String[] args) throws Exception {
> Base64 b64 = new Base64();
> String s1 = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
> String s2 = "aaaaaaaaaa";
> String s3 = "a";
>
> byte[] b1 = s1.getBytes("UTF-8");
> byte[] b2 = s2.getBytes("UTF-8");
> byte[] b3 = s3.getBytes("UTF-8");
> byte[] result;
> result = Base64.encodeBase64(b1);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b1);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = Base64.encodeBase64(b2);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b2);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = Base64.encodeBase64(b3);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b3);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> }
> }
> {code}
> Here's my output:
> {noformat}
> $ java -cp commons-codec-1.3.jar:. B64
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==]
> [YQ==]
> [YQ==]
> $ java -cp commons-codec-1.4.jar:. B64
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
> YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==
> ]
> [YWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==
> ]
> [YQ==]
> [YQ==
> ]
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CODEC-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785109#action_12785109
]
Sebb commented on CODEC-89:
---------------------------
Patch (dated 2009-10-28 04:52 PM) looks OK, except I think it looks odd to do:
this(NO_CHUNKING, CHUNK_SEPARATOR, urlSafe);
Why provide a CHUNK_SEPARATOR if there's no chunking?
Seems to me it would be better to use null, and make corresponding changes to the ctor
Base64(int lineLength, byte[] lineSeparator, boolean urlSafe)
so that lineSeparator == null IFF lineLength==0
This would have the benefit that accidental use of the lineSeparator would trigger an NPE.
The current code outside the ctor only accesses lineSeparator if lineLength > 0, which
is as it should be.
> new Base64().encode() appends a CRLF, and chunks results into 76 character lines
> --------------------------------------------------------------------------------
>
> Key: CODEC-89
> URL: https://issues.apache.org/jira/browse/CODEC-89
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.4
> Reporter: Julius Davies
> Attachments: codec-89.patch
>
>
> The instance encode() method (e.g. new Base64().encode()) appends a CRLF. Actually it's
fully chunking the output into 76 character lines. Commons-Codec-1.3 did not do this. The
static Base64.encodeBase64() method behaves the same in both 1.3 and 1.4, so this problem
only affects the instance encode() method.
> {code}
> import org.apache.commons.codec.binary.*;
> public class B64 {
> public static void main(String[] args) throws Exception {
> Base64 b64 = new Base64();
> String s1 = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
> String s2 = "aaaaaaaaaa";
> String s3 = "a";
>
> byte[] b1 = s1.getBytes("UTF-8");
> byte[] b2 = s2.getBytes("UTF-8");
> byte[] b3 = s3.getBytes("UTF-8");
> byte[] result;
> result = Base64.encodeBase64(b1);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b1);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = Base64.encodeBase64(b2);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b2);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = Base64.encodeBase64(b3);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b3);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> }
> }
> {code}
> Here's my output:
> {noformat}
> $ java -cp commons-codec-1.3.jar:. B64
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==]
> [YQ==]
> [YQ==]
> $ java -cp commons-codec-1.4.jar:. B64
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
> YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==
> ]
> [YWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==
> ]
> [YQ==]
> [YQ==
> ]
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LANG-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger updated LANG-560:
------------------------------
Attachment: TimedSemaphore.patch
Patch including the {{TimedSemaphore}} implementation and a unit test.
The test makes use of EasyMock, therefore this dependency is added to the pom.
> New TimedSemaphore class
> ------------------------
>
> Key: LANG-560
> URL: https://issues.apache.org/jira/browse/LANG-560
> Project: Commons Lang
> Issue Type: New Feature
> Reporter: Oliver Heger
> Fix For: 3.0
>
> Attachments: TimedSemaphore.patch
>
>
> {{TimedSemaphore}} is a specialized Semaphore implementation that also has a timing component:
In a configurable time period a given number of permits is available. Threads call the semaphore's
{{acquire()}} method to request a permit. When no more permits are available {{acquire()}}
blocks the calling thread. At the end of the time period the permits are restored, and all
blocking threads are waked up.
> The main use case for this class is to provide a convenient means for controlling the
load produced by a process. When used correctly, {{TimedSemaphore}} ensures that only a given
number of steps (e.g. database queries, file operations, or computations) are performed in
a specific time period. This may be useful for many applications.
> More information including a usage example can be found in the Javadocs of the class.
Comments or suggestions for improvements are appreciated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Add test(s) to check that encodeBase64() does not chunk output
--------------------------------------------------------------
Key: CODEC-93
URL: https://issues.apache.org/jira/browse/CODEC-93
Project: Commons Codec
Issue Type: Sub-task
Affects Versions: 1.4
Reporter: Sebb
There don't appear to be any tests to specifically check that encodeBase64(byte[]) does not
chunk output.
Also, there don't seem to be any direct tests of the following static method:
encodeBase64(byte[] binaryData, boolean isChunked, boolean urlSafe)
There are not many of some of the other static methods either.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
New TimedSemaphore class
------------------------
Key: LANG-560
URL: https://issues.apache.org/jira/browse/LANG-560
Project: Commons Lang
Issue Type: New Feature
Reporter: Oliver Heger
Fix For: 3.0
{{TimedSemaphore}} is a specialized Semaphore implementation that also has a timing component:
In a configurable time period a given number of permits is available. Threads call the semaphore's
{{acquire()}} method to request a permit. When no more permits are available {{acquire()}}
blocks the calling thread. At the end of the time period the permits are restored, and all
blocking threads are waked up.
The main use case for this class is to provide a convenient means for controlling the load
produced by a process. When used correctly, {{TimedSemaphore}} ensures that only a given number
of steps (e.g. database queries, file operations, or computations) are performed in a specific
time period. This may be useful for many applications.
More information including a usage example can be found in the Javadocs of the class. Comments
or suggestions for improvements are appreciated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Many test cases use getBytes() which uses the default platform encoding so tests may fail on
some platforms
-----------------------------------------------------------------------------------------------------------
Key: CODEC-92
URL: https://issues.apache.org/jira/browse/CODEC-92
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Sebb
Priority: Minor
Many test cases use getBytes() or new .String(byte[] bytes).
These both use the default platform encoding so the tests may fail on some platforms.
The tests should either use a known encoding (e.g. UTF-8) or should use bytes directly (e.g.
'h','e','l','l','o' instead of "hello".getBytes())
There don't seem to be any examples of such method calls in the main code, so the priority
has been set to minor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DBCP-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784807#action_12784807
]
Ondrej Tisler commented on DBCP-309:
------------------------------------
I use this code for registring JNDI inFSContext:
// JNDI with datasource
InitialContext ic = new InitialContext();
// Construct BasicDataSource reference
Configuration poolConfig = dbConfig.subset("datasource");
DriverAdapterCPDS cpds = new DriverAdapterCPDS();
cpds.setDriver(poolConfig.getString("driver.driverClassName"));
cpds.setUrl(poolConfig.getString("driver.url"));
cpds.setUser(poolConfig.getString("driver.username"));
cpds.setPassword(CryptPass.encryptPass(poolConfig.getString("driver.password")));
SharedPoolDataSource ds = new SharedPoolDataSource();
ds.setConnectionPoolDataSource(cpds);
ds.setDefaultAutoCommit(poolConfig.getBoolean("connection.defaultAutoCommit", true));
ds.setValidationQuery(poolConfig.getString("validation.validationQuery"));
ic.rebind(poolConfig.getString("[@jndi]"), ds);
log.info("JNDI datasource is inicialized");
next you can normaly use JNDI lookup:
InitialContext ic2 = new InitialContext();
ds = (DataSource) ic2.lookup(poolConfig.getString("[@jndi]"));
conn = ds.getConnection();
> First example for FSContext is invalid
> --------------------------------------
>
> Key: DBCP-309
> URL: https://issues.apache.org/jira/browse/DBCP-309
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.2.2
> Reporter: Ondrej Tisler
> Priority: Trivial
>
> First example on page http://commons.apache.org/dbcp/guide/jndi-howto.html is invalid,
with this code every call of
> InitialContext ic2 = new InitialContext();
> DataSource ds = (DataSource) ic2.lookup("jdbc/basic");
> Connection conn = ds.getConnection();
> conn.close();
> ends with new datasource with unclosed connection in it becase new Reference("javax.sql.DataSource",
"org.apache.commons.dbcp.BasicDataSourceFactory", null); reference creates new DataSource
instead using created one while calling ic2.lookup("jdbc/basic").
> At the end it ends with many opened connections to DB until JVM is ended.
> Second example I didn't test, i use direct aproach with manualy creating SharedPoolDataSource
and registring it in FSContext JNDI itself.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CODEC-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784741#action_12784741
]
Mat Booth commented on CODEC-89:
--------------------------------
> Note that the behaviour of
>
> new Base64(0).encode()
> is the same as
> Base64.encodeBase64()
So it is... Is that documented anywhere?
A note in the compatibility section of the release notes that "new Base64()" should be changed
to "new Base64(0)" would be awesome.
> new Base64().encode() appends a CRLF, and chunks results into 76 character lines
> --------------------------------------------------------------------------------
>
> Key: CODEC-89
> URL: https://issues.apache.org/jira/browse/CODEC-89
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.4
> Reporter: Julius Davies
> Attachments: codec-89.patch
>
>
> The instance encode() method (e.g. new Base64().encode()) appends a CRLF. Actually it's
fully chunking the output into 76 character lines. Commons-Codec-1.3 did not do this. The
static Base64.encodeBase64() method behaves the same in both 1.3 and 1.4, so this problem
only affects the instance encode() method.
> {code}
> import org.apache.commons.codec.binary.*;
> public class B64 {
> public static void main(String[] args) throws Exception {
> Base64 b64 = new Base64();
> String s1 = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
> String s2 = "aaaaaaaaaa";
> String s3 = "a";
>
> byte[] b1 = s1.getBytes("UTF-8");
> byte[] b2 = s2.getBytes("UTF-8");
> byte[] b3 = s3.getBytes("UTF-8");
> byte[] result;
> result = Base64.encodeBase64(b1);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b1);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = Base64.encodeBase64(b2);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b2);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = Base64.encodeBase64(b3);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b3);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> }
> }
> {code}
> Here's my output:
> {noformat}
> $ java -cp commons-codec-1.3.jar:. B64
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==]
> [YQ==]
> [YQ==]
> $ java -cp commons-codec-1.4.jar:. B64
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
> YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==
> ]
> [YWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==
> ]
> [YQ==]
> [YQ==
> ]
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CODEC-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784589#action_12784589
]
Sebb commented on CODEC-89:
---------------------------
Note that the behaviour of
new Base64(0).encode()
is the same as
Base64.encodeBase64()
> new Base64().encode() appends a CRLF, and chunks results into 76 character lines
> --------------------------------------------------------------------------------
>
> Key: CODEC-89
> URL: https://issues.apache.org/jira/browse/CODEC-89
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.4
> Reporter: Julius Davies
> Attachments: codec-89.patch
>
>
> The instance encode() method (e.g. new Base64().encode()) appends a CRLF. Actually it's
fully chunking the output into 76 character lines. Commons-Codec-1.3 did not do this. The
static Base64.encodeBase64() method behaves the same in both 1.3 and 1.4, so this problem
only affects the instance encode() method.
> {code}
> import org.apache.commons.codec.binary.*;
> public class B64 {
> public static void main(String[] args) throws Exception {
> Base64 b64 = new Base64();
> String s1 = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
> String s2 = "aaaaaaaaaa";
> String s3 = "a";
>
> byte[] b1 = s1.getBytes("UTF-8");
> byte[] b2 = s2.getBytes("UTF-8");
> byte[] b3 = s3.getBytes("UTF-8");
> byte[] result;
> result = Base64.encodeBase64(b1);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b1);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = Base64.encodeBase64(b2);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b2);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = Base64.encodeBase64(b3);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b3);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> }
> }
> {code}
> Here's my output:
> {noformat}
> $ java -cp commons-codec-1.3.jar:. B64
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==]
> [YQ==]
> [YQ==]
> $ java -cp commons-codec-1.4.jar:. B64
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
> YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==
> ]
> [YWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==
> ]
> [YQ==]
> [YQ==
> ]
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CODEC-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784460#action_12784460
]
Mat Booth commented on CODEC-89:
--------------------------------
I'd prefer to see a 1.4.1 release with the old behaviour. It seems against the spirit of minor
version bump (like 1.3 to 1.4) to change the behaviour of the interface.
It definitely feels like a regression to me -- I'm tempted to apply this patch to the commons-codec
distributed by Fedora Linux (I am the maintainer there).
> new Base64().encode() appends a CRLF, and chunks results into 76 character lines
> --------------------------------------------------------------------------------
>
> Key: CODEC-89
> URL: https://issues.apache.org/jira/browse/CODEC-89
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.4
> Reporter: Julius Davies
> Attachments: codec-89.patch
>
>
> The instance encode() method (e.g. new Base64().encode()) appends a CRLF. Actually it's
fully chunking the output into 76 character lines. Commons-Codec-1.3 did not do this. The
static Base64.encodeBase64() method behaves the same in both 1.3 and 1.4, so this problem
only affects the instance encode() method.
> {code}
> import org.apache.commons.codec.binary.*;
> public class B64 {
> public static void main(String[] args) throws Exception {
> Base64 b64 = new Base64();
> String s1 = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
> String s2 = "aaaaaaaaaa";
> String s3 = "a";
>
> byte[] b1 = s1.getBytes("UTF-8");
> byte[] b2 = s2.getBytes("UTF-8");
> byte[] b3 = s3.getBytes("UTF-8");
> byte[] result;
> result = Base64.encodeBase64(b1);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b1);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = Base64.encodeBase64(b2);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b2);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = Base64.encodeBase64(b3);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> result = b64.encode(b3);
> System.out.println("[" + new String(result, "UTF-8") + "]");
> }
> }
> {code}
> Here's my output:
> {noformat}
> $ java -cp commons-codec-1.3.jar:. B64
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==]
> [YQ==]
> [YQ==]
> $ java -cp commons-codec-1.4.jar:. B64
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
> YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==
> ]
> [YWFhYWFhYWFhYQ==]
> [YWFhYWFhYWFhYQ==
> ]
> [YQ==]
> [YQ==
> ]
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
New Validate utility methods
----------------------------
Key: LANG-559
URL: https://issues.apache.org/jira/browse/LANG-559
Project: Commons Lang
Issue Type: New Feature
Reporter: Paul Benedict
Assignee: Paul Benedict
Fix For: 3.0
Methods for consideration:
* isInstanceOf(Class<?> type, Object o);
* isAssignable(Class<?> superType, Class<?> subType);
* state(boolean condition);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DBCP-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783729#action_12783729
]
Phil Steitz commented on DBCP-309:
----------------------------------
Strike last comment. DataSoources do not implement Referenceable, so direct references will
not work. When using the FileSystem provider, datasources are created new for each lookup
(as reported in the issue). Tomcat's in-memory provider, however, returns the same datasource
for repeated lookups. The following test, for example, succeeds with the Tomcat provider,
but fails with the FS provider
{code}
Hashtable environment = new Hashtable();
environment.put(Context.INITIAL_CONTEXT_FACTORY,
org.apache.naming.java.javaURLContextFactory.class.getName());
InitialContext ic = new InitialContext(environment);
ic.createSubcontext("jdbc");
// Construct BasicDataSource reference
Reference ref = new Reference("javax.sql.DataSource",
"org.apache.commons.dbcp.BasicDataSourceFactory", null);
ref.add(new StringRefAddr("driverClassName", "TesterDriver"));
ref.add(new StringRefAddr("url", "jdbc:apache:commons:testdriver"));
ref.add(new StringRefAddr("username", "username"));
ref.add(new StringRefAddr("password", "password"));
ic.rebind("jdbc/basic", ref);
// Use
InitialContext ic2 = new InitialContext(environment);
DataSource ds = (DataSource) ic2.lookup("jdbc/basic");
((BasicDataSource) ds).setAccessToUnderlyingConnectionAllowed(true);
Assert.assertNotNull(ds);
Connection conn = ds.getConnection();
Connection uconn = ((DelegatingConnection) conn).getInnermostDelegate();
Assert.assertNotNull(conn);
conn.close();
DataSource ds2 = (DataSource) ic2.lookup("jdbc/basic");
((BasicDataSource) ds2).setAccessToUnderlyingConnectionAllowed(true);
Assert.assertNotNull(ds2);
Connection conn2 = ds2.getConnection();
Connection uconn2 = ((DelegatingConnection) conn2).getInnermostDelegate();
Assert.assertNotNull(conn2);
conn2.close();
Assert.assertEquals(ds, ds2);
Assert.assertEquals(uconn2, uconn);
{code}
To make the examples less misleading, it seems we have two choices - 1) change to use the
Tomcat provider or 2) comment that the FS provider creates new datasources each time. Would
appreciate comments / patches from JNDI spi experts on this.
> First example for FSContext is invalid
> --------------------------------------
>
> Key: DBCP-309
> URL: https://issues.apache.org/jira/browse/DBCP-309
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.2.2
> Reporter: Ondrej Tisler
> Priority: Trivial
>
> First example on page http://commons.apache.org/dbcp/guide/jndi-howto.html is invalid,
with this code every call of
> InitialContext ic2 = new InitialContext();
> DataSource ds = (DataSource) ic2.lookup("jdbc/basic");
> Connection conn = ds.getConnection();
> conn.close();
> ends with new datasource with unclosed connection in it becase new Reference("javax.sql.DataSource",
"org.apache.commons.dbcp.BasicDataSourceFactory", null); reference creates new DataSource
instead using created one while calling ic2.lookup("jdbc/basic").
> At the end it ends with many opened connections to DB until JVM is ended.
> Second example I didn't test, i use direct aproach with manualy creating SharedPoolDataSource
and registring it in FSContext JNDI itself.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/JEXL-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783722#action_12783722
]
Rahul Akolkar commented on JEXL-92:
-----------------------------------
Please see feedback on dev list, email titled "Re: [JEXL] JexlContext API changes in JEXL-92
(was: svn commit: r884650 [1/2] ...)" sent today, markmail pointer below:
http://markmail.org/message/667oycd7lom2mq26
> JexlContext API should be more flexible
> ---------------------------------------
>
> Key: JEXL-92
> URL: https://issues.apache.org/jira/browse/JEXL-92
> Project: Commons JEXL
> Issue Type: Improvement
> Affects Versions: 1.1
> Reporter: Henri Biestro
> Assignee: Henri Biestro
> Fix For: 2.0
>
>
> JexlContext is a bit heavy since it forces implementors to wrap their environment in
Maps.
> It would be more convenient to have fine-grain methods (setVar, getVar).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DBUTILS-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Atkinson updated DBUTILS-65:
------------------------------------
Attachment: BeanProcessor-patch.diff
Remove duplicated code in BeanProcessor#processColumn
> Duplicate code introduced during Java 1.5 branch merge
> ------------------------------------------------------
>
> Key: DBUTILS-65
> URL: https://issues.apache.org/jira/browse/DBUTILS-65
> Project: Commons DbUtils
> Issue Type: Bug
> Affects Versions: 1.3
> Reporter: Brandon Atkinson
> Attachments: BeanProcessor-patch.diff
>
>
> The merge of Java 1.5 code into the main line introduced duplicate code in at least one
place (BeanProcessor.java).
> My guess is that some patches were applied to both the trunk and 1.5 branch during development.
When the merge occurred, the patches contents were duplicated.
> I haven't analyzed all files for duplicate code, but I will be attaching a patch for
the BeanProcessor class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Duplicate code introduced during Java 1.5 branch merge
------------------------------------------------------
Key: DBUTILS-65
URL: https://issues.apache.org/jira/browse/DBUTILS-65
Project: Commons DbUtils
Issue Type: Bug
Affects Versions: 1.3
Reporter: Brandon Atkinson
The merge of Java 1.5 code into the main line introduced duplicate code in at least one place
(BeanProcessor.java).
My guess is that some patches were applied to both the trunk and 1.5 branch during development.
When the merge occurred, the patches contents were duplicated.
I haven't analyzed all files for duplicate code, but I will be attaching a patch for the BeanProcessor
class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/IO-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783648#action_12783648
]
Vincent Bouscasse edited comment on IO-170 at 11/30/09 1:23 PM:
----------------------------------------------------------------
Hi Matthew.
I'm not sure i got the point but i think Damian was thinking about an iterator that allows
for processing results on the fly as soon as they are available. The code in your patch does
not allow this: we have to wait until the result files are found before the first file object
can be used as a return of iterator.next(). It can be long if we search files in large directory
trees.
I've written a recursive Iterator<File> implementation allowing to get the first matches
as soon as they're discovered. The next match is computed in the hasNext() method and it uses
linked lists to store matches and subdirectories. The complete iteration speed is the same
as the actual one (Commons IO 1.4) but first results are provided more quickly. This iterator
implementation typical usage is in a producer thread whereas the file processing is done in
a consumer thread allowing to speeding up the file processing
I can provide you a code sample if it can match your needs.
Best regards.
was (Author: vbouscasse):
Hi Matthew.
I'm not sure i got the point but i think Damian was thinking about an iterator that allows
for processing results on the fly as soon as they are available. The code in your patch does
not allow this: we have to wait until the result files are found before the first file object
can be used as a return of iterator.next(). It can be long if we search files in large directory
trees.
I've written a recursive Iterator<File> implementation allowing to get the first matches
as soon as they're discovered. The next match is computed in the hasNext() method and it uses
linked lists to store matches and subdirectories. The complete iteration speed is the same
as the actual one but first results are provided more quickly. This iterator implementation
typical usage is in a producer thread whereas the file processing is done in a consumer thread
allowing to speeding up the file processing
I can provide you a code sample if it can match your needs.
Best regards.
> Scalable Iterator for files, better than FileUtils.iterateFiles
> ---------------------------------------------------------------
>
> Key: IO-170
> URL: https://issues.apache.org/jira/browse/IO-170
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
> Affects Versions: 1.4
> Environment: generic file systems
> Reporter: Damian Noseda
> Priority: Minor
> Fix For: 2.x
>
> Attachments: real_iterators.patch
>
> Original Estimate: 5h
> Remaining Estimate: 5h
>
> Improve the way that iterateFiles generate an iterator. The current way it not scale.
It's try to add all files in a list and then return the iterator of that list. A better way
it would be create an customize Iterator<File> with a stack of arrays of File to go
up and down in the directory tree.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/IO-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783648#action_12783648
]
Vincent Bouscasse commented on IO-170:
--------------------------------------
Hi Matthew.
I'm not sure i got the point but i think Damian was thinking about an iterator that allows
for processing results on the fly as soon as they are available. The code in your patch does
not allow this: we have to wait until the result files are found before the first file object
can be used as a return of iterator.next(). It can be long if we search files in large directory
trees.
I've written a recursive Iterator<File> implementation allowing to get the first matches
as soon as they're discovered. The next match is computed in the hasNext() method and it uses
linked lists to store matches and subdirectories. The complete iteration speed is the same
as the actual one but first results are provided more quickly. This iterator implementation
typical usage is in a producer thread whereas the file processing is done in a consumer thread
allowing to speeding up the file processing
I can provide you a code sample if it can match your needs.
Best regards.
> Scalable Iterator for files, better than FileUtils.iterateFiles
> ---------------------------------------------------------------
>
> Key: IO-170
> URL: https://issues.apache.org/jira/browse/IO-170
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
> Affects Versions: 1.4
> Environment: generic file systems
> Reporter: Damian Noseda
> Priority: Minor
> Fix For: 2.x
>
> Attachments: real_iterators.patch
>
> Original Estimate: 5h
> Remaining Estimate: 5h
>
> Improve the way that iterateFiles generate an iterator. The current way it not scale.
It's try to add all files in a list and then return the iterator of that list. A better way
it would be create an customize Iterator<File> with a stack of arrays of File to go
up and down in the directory tree.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MATH-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik van Ingen closed MATH-305.
-------------------------------
I have tested the fix and I can confirm that it is working in my environment. Thanks a lot!
> NPE in KMeansPlusPlusClusterer unittest
> ----------------------------------------
>
> Key: MATH-305
> URL: https://issues.apache.org/jira/browse/MATH-305
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 2.0
> Environment: java 6, eclipse, apache commons math trunk
> Reporter: Erik van Ingen
> Fix For: 2.1
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> When running this unittest, I am facing this NPE:
> java.lang.NullPointerException
> at org.apache.commons.math.stat.clustering.KMeansPlusPlusClusterer.assignPointsToClusters(KMeansPlusPlusClusterer.java:91)
> This is the unittest:
> package org.fao.fisheries.chronicles.calcuation.cluster;
> import static org.junit.Assert.assertEquals;
> import static org.junit.Assert.assertTrue;
> import java.util.Arrays;
> import java.util.List;
> import java.util.Random;
> import org.apache.commons.math.stat.clustering.Cluster;
> import org.apache.commons.math.stat.clustering.EuclideanIntegerPoint;
> import org.apache.commons.math.stat.clustering.KMeansPlusPlusClusterer;
> import org.fao.fisheries.chronicles.input.CsvImportProcess;
> import org.fao.fisheries.chronicles.input.Top200Csv;
> import org.junit.Test;
> public class ClusterAnalysisTest {
> @Test
> public void testPerformClusterAnalysis2() {
> KMeansPlusPlusClusterer<EuclideanIntegerPoint> transformer = new KMeansPlusPlusClusterer<EuclideanIntegerPoint>(
> new Random(1746432956321l));
> EuclideanIntegerPoint[] points = new EuclideanIntegerPoint[] {
> new EuclideanIntegerPoint(new int[] { 1959, 325100 }),
> new EuclideanIntegerPoint(new int[] { 1960, 373200 }), };
> List<Cluster<EuclideanIntegerPoint>> clusters = transformer.cluster(Arrays.asList(points),
1, 1);
> assertEquals(1, clusters.size());
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.